Date: Fri, 27 Feb 2015 13:06:09 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: guru@unixarea.de Cc: freebsd-questions-local@be-well.ilk.org, freebsd-questions@freebsd.org Subject: Re: sendmail && dhcp Message-ID: <54f0dc41.NVD2hFGwt9XGczfB%perryh@pluto.rain.com> In-Reply-To: <20150227130145.GA3591@c720-r276659> References: <20150226144245.GA1346@c720-r276659> <44bnkgsmcl.fsf@lowell-desk.lan> <20150226194012.GA2695@c720-r276659> <4461aoe96j.fsf@lowell-desk.lan> <20150226203154.GA2853@c720-r276659> <44k2z4ci8y.fsf@lowell-desk.lan> <54efe697.xdtSCVZsiZDqV7lP%perryh@pluto.rain.com> <20150227130145.GA3591@c720-r276659>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthias Apitz <guru@unixarea.de> wrote: > El d??a Thursday, February 26, 2015 a las 07:37:59PM -0800, Perry Hutchison escribi??: > > Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> wrote: > > > Matthias Apitz <guru@unixarea.de> writes: > > > > I fetch my mails from my ISP with fetchmail and pipe them > > > > through sendmail and procmail (for filtering); and I send > > > > upstream with SMPT && SSL to my ISP using sendmail ... it is > > > > so nice to connect a few seconds(!) to fetch all your mails, > > > > shutdown the link, read and answer the mails offline, queue > > > > answers with sendmail, and re-open the link for a few seconds > > > > to send the mails out. > > > > > > You don't need a sendmail daemon for that. > > > > There's no need to involve sendmail at all (on the receive side) > > for that ... > > AFAIK there is no need for one MTA (fetchmail) to invoke another > > MTA (sendmail) just to get to a third mail agent[*] (procmail). > > Have fetchmail invoke procmail directly. > > To read and write I'm using mutt as MUA. mutt can fetch with IMAP(S) and > send with SMTP+SSL; but this (sending directly) is not what I want, I > want to queue up the outbound mails and send them at once (see above for > the reason); so, sendmail is the natural option; Indeed, but that does not necessarily mean that you need a sendmail *daemon*. I haven't used mutt, but I have the impression that it is capable of invoking sendmail directly (via fork/exec, passing the message on stdin) rather than having to keep a daemon running all the time to accept the occasional SMTP connection on 127.0.0.1:25. In fact, depending on how you have it configured, mutt may *currently* be running a sendmail process (via fork/exec) for each message you send, rather than using the local sendmail daemon. On the receive side, the main advantage of having fetchmail run procmail directly is simplification: the sendmail configuration need only be concerned with queueing and transmitting outbound mail. A second advantage is that, with no outbound-capable MTA in the inbound path, there is one less place where someone might find an exploit to use you as a relay.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54f0dc41.NVD2hFGwt9XGczfB%perryh>