sendmail && dhcp

[Perry Hutchison]

Matthias Apitz <guru at unixarea.de> wrote:
> El d??a Thursday, February 26, 2015 a las 07:37:59PM -0800, Perry Hutchison escribi??:
> > Lowell Gilbert <freebsd-questions-local at be-well.ilk.org> wrote:
> > > Matthias Apitz <guru at 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.