From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ian Jackson Newsgroups: gmane.emacs.devel Subject: Re: sendmail.el bug or expected behavior? Date: Fri, 23 Jan 2004 12:29:55 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <16401.5059.249741.523854@chiark.greenend.org.uk> References: <877jzn2lk8.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074861636 32086 80.91.224.253 (23 Jan 2004 12:40:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 12:40:36 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jan 23 13:40:26 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ak0bq-0007Wl-00 for ; Fri, 23 Jan 2004 13:40:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ak0bq-0006UM-00 for ; Fri, 23 Jan 2004 13:40:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ak0XL-0000wU-Iz for emacs-devel@quimby.gnus.org; Fri, 23 Jan 2004 07:35:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ak0Ub-0000jl-AI for emacs-devel@gnu.org; Fri, 23 Jan 2004 07:32:57 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ak0TE-0000Rs-PD for emacs-devel@gnu.org; Fri, 23 Jan 2004 07:32:05 -0500 Original-Received: from [193.201.200.170] (helo=chiark.greenend.org.uk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ak0Rh-00009x-Gq; Fri, 23 Jan 2004 07:29:57 -0500 Original-Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1Ak0Rf-0006UE-00; Fri, 23 Jan 2004 12:29:55 +0000 Original-To: Simon Josefsson Original-Newsgroups: chiark.mail.gnu.emacs.devel In-Reply-To: X-Mailer: VM 7.03 under Emacs 19.34.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19453 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19453 Simon Josefsson writes ("Re: sendmail.el bug or expected behavior?"): > I suspect that if the MTA is trying to deliver the message to its > final destination, then it may hang regardless of what MTA is used. IMO the correct way for a MUA to invoke sendmail (on Debian) is /usr/sbin/sendmail -odb -oee ... (To be portable to non-FHS systems, use /usr/lib/sendmail) This is supposed to (a) queue the message, exiting non-0 if unsuccessful (b) fork off a detached delivery attempt, which will deliver the message, leave it queued, or bounce it, as appropriate (c) exit 0, leaving the delivery attempting going The problem that RMS mentions happens if you don't give any -odX options: usually that means you'll get `foreground' delivery, which typically means that the MTA will try one delivery attempt now. This is even more unhelpful when combined with -oem (also sometimes the default), which (AIUI[1]) exits 0 on success or if the first delivery attempt fails but the message is queued, but exits nonzero if the delivery failed straight away even if the message was successfully bounced. Emacs needs, from the MTA, the behaviour I specify above for -odb -oee. Ie, exit status 0 from sendmail should mean the same as `250 OK' does after SMTP DATA final dot. If it is difficult to get this behaviour portably (which seems unlikely nowadays although may have been much harder in times past) then I think it's still worth doing. In any case any other behaviour by the MTA will always result in at least one or more of these symptoms: * Excessive delay when sending mail interactive. * Silently vanishing mail. (`Mail sent' but not actually sent.) * Interactive report of a problem sending mail (`Mail could not be sent') followed _also_ by a bounce. * Interactive report of a problem sending mail (`Mail could not be sent') but in fact the mail is also later delivered. Is there some way to configure Emacs to use -odb -oee ? If so we (FSF, or failing that, Debian) should change the default. If not all MTAs support -odb -oee (or use it to mean the same thing) then for Debian we should patch them, and probably FSF Emacs should have a configuration option to work with broken MTAs (in this case passing sendmail other options may be helpful). I know that Exim does support -odb -oee (and last time I looked the Exim docs are reasonably good about these questions). Exim 3.35 (which I'm running here) has a bug where at least one of stdin/stdout/stderr isn't properly closed by the asynchronous child, which can cause things to hang if you run sendmail via ssh or userv, but hopefully Emacs can be made to stop waiting when sendmail has exited, even if one of the pipes to it hasn't been closed at the other end. Smail interprets -oee to mean the same as -oem, but with background delivery you probably won't get too many false nonzero exits. The copy of the Sendmail Installation and Operation Guide I have to hand here is unhelpfully vague about the exact behaviour of the various -oeX options. (Search the document for the string `ErrorMode'.) Postfix seems to ignore -oeX and -odX completely. I think it's probably modern enough to do the right thing. Ian. (submitter of the Debian bug #114849, and long-time free software developer and user)