From owner-freebsd-questions@FreeBSD.ORG Fri Feb 27 21:14:13 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4875F21A for ; Fri, 27 Feb 2015 21:14:13 +0000 (UTC) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08E04AB5 for ; Fri, 27 Feb 2015 21:14:12 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id t1RLDgHI042556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Feb 2015 13:13:43 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id t1RLDgFX042555; Fri, 27 Feb 2015 13:13:42 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA18581; Fri, 27 Feb 15 13:06:13 PST Date: Fri, 27 Feb 2015 13:06:09 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: guru@unixarea.de Subject: Re: sendmail && dhcp Message-Id: <54f0dc41.NVD2hFGwt9XGczfB%perryh@pluto.rain.com> 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> In-Reply-To: <20150227130145.GA3591@c720-r276659> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-questions-local@be-well.ilk.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 21:14:13 -0000 Matthias Apitz wrote: > El d??a Thursday, February 26, 2015 a las 07:37:59PM -0800, Perry Hutchison escribi??: > > Lowell Gilbert wrote: > > > Matthias Apitz 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.