From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: sendmail.el bug or expected behavior? Date: Thu, 29 Jan 2004 22:27:12 -0600 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87oesmt61r.fsf@raven.i.defaultvalue.org> References: <877jzn2lk8.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075437008 3167 80.91.224.253 (30 Jan 2004 04:30:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2004 04:30:08 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jan 30 05:30:03 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 1AmQI7-0002vd-00 for ; Fri, 30 Jan 2004 05:30:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AmQI7-0001x2-00 for ; Fri, 30 Jan 2004 05:30:03 +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 1AmQGL-0000FL-9x for emacs-devel@quimby.gnus.org; Thu, 29 Jan 2004 23:28:13 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AmQFv-0000EY-57 for emacs-devel@gnu.org; Thu, 29 Jan 2004 23:27:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AmQFO-00009w-8x for emacs-devel@gnu.org; Thu, 29 Jan 2004 23:27:46 -0500 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AmQFN-00009n-JV for emacs-devel@gnu.org; Thu, 29 Jan 2004 23:27:13 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 05FBF403D for ; Thu, 29 Jan 2004 22:27:13 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 40C3781070; Thu, 29 Jan 2004 22:27:12 -0600 (CST) Original-To: emacs-devel@gnu.org In-Reply-To: <877jzn2lk8.fsf@raven.i.defaultvalue.org> (Rob Browning's message of "Tue, 20 Jan 2004 00:14:47 -0600") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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:19558 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19558 Rob Browning writes: > Emacs doesn't always check for a non-zero exit status from sendmail, > which can lead to silent mail lossage. For example: Presuming I haven't misunderstood, where do we stand here? From what I gather everyone would be happy if we could do something that would make emacs always wait for the MTA to quit (checking the exit code), but only if that doesn't introduce "too much delay" when running on a properly configured system. (What would be "too much delay" in situations where something wasn't actually wrong and was legitimately causing the delay?) Personally, I can't imagine it being OK to leave things with potential for silent mail loss, especially not as the default, even if fixing it might introduce a 5 minute delay. If there is a 5 minute delay then that just tells me that my MTA is broken (probably misconfigured), or perhaps my hardware is bad, etc., and that I need to look in to it. Of course even if I can't fix the delay, *and* I don't mind the extra risk, I can always decide to set mail-interactive to nil. This issue could even be a FAQ. At the very least, I'd submit that perhaps the documentation for mail-interactive should be adjusted to provide more warning. i.e. "Setting mail-interactive to nil may cause you to lose mail under any number of unpredictable conditions[1] without any warning. Emacs will *not* check to see if the mailer process failed." ([1] Where unpredictable conditions include but are not limited to your partition filling up, broken libraries during or left after an upgrade, mailer running out of memory, PATH altered improperly, etc.) IMO if the common mailers (sendmail/postfix/exim/etc.) can be told to queue the mail reasonably quickly these days, then I'd prefer to see us figure out how to have emacs to do that by default while still making it easy for people in special circumstances to arrange for something faster, though perhaps less safe. Also, I'm not sure it's relevant (or even feasible with emacs current code), and I don't use any of these systems myself, but it seems like a lot of other MUAs just queue up the outgoing mail themselves and either send it via SMTP, either on-demand or in the background, and they treat messages that haven't made it out yet in much the same way that emacs treats unsaved buffers -- if you try to quit, they ask you about them. For people who have a properly configured postfix/sendmail/exim/whatever queuing arrangement, this might not be interesting, but for others, perhaps. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4