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: Mon, 26 Jan 2004 14:09:26 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <16405.8086.195634.248486@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 1075129443 17572 80.91.224.253 (26 Jan 2004 15:04:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Jan 2004 15:04:03 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jan 26 16:03:56 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 1Al8HM-0007ba-00 for ; Mon, 26 Jan 2004 16:03:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Al8HM-0007p6-00 for ; Mon, 26 Jan 2004 16:03:56 +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 1Al8BI-0000Jp-FY for emacs-devel@quimby.gnus.org; Mon, 26 Jan 2004 09:57:40 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Al7tq-0003Po-VC for emacs-devel@gnu.org; Mon, 26 Jan 2004 09:39:38 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Al7TS-0001MR-0w for emacs-devel@gnu.org; Mon, 26 Jan 2004 09:12:53 -0500 Original-Received: from [193.201.200.170] (helo=chiark.greenend.org.uk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Al7Qd-00008l-3G for emacs-devel@gnu.org; Mon, 26 Jan 2004 09:09:27 -0500 Original-Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1Al7Qc-0008Qz-00; Mon, 26 Jan 2004 14:09:26 +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:19488 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19488 Simon Josefsson writes ("Re: sendmail.el bug or expected behavior?"): > Richard Stallman writes: > > I would expect people to design an MTAs not to wait very long > > in the process that you created to send the mail. If sendmail > > does this badly, does that mean they all do? > > I guess not. But how do MTAs implement this, if they don't wait in > the foreground? Simply storing the e-mail in /var/spool/mqueue and > hope that the system is polling the queue every hour or so might not > be reliable. When a user asks to send a mail, there is not time to do a delivery attempt to remote systems. Remote systems are allowed to be down (TCP connection times), and they're allowed to make the SMTP client wait for around 5 minutes _per SMTP response_, so a whole delivery can (and sometimes does) take quite a while even if it's going to succeed. If you think the system should try to do a delivery to another site on the Internet when the user hits `send', what do you think it should do when the delivery attempt takes longer than the user is reasonably prepared to wait ? (Personally I want mail sending to be nearly instant - pratting about waiting for SMTP is what I have computers for.) MTAs are not typically designed to allow the delivery attempt to be retrospectively made noninteractive, and the whole delivery attempt might last longer than the lifetime of the MUA, so you can't just remember you have it going and try to tell the user later. The fact is that delivery to remote sites, queue management, retry, timeouts, etc. are the _functions_ of an Internet MTA ! Without those functions being implemented somewhere you can't send mail to the Internet (or at least, not reliably). Ie, without a queue, and a queue runner (somewhere), your mail is already broken. Now, traditionally, UN*X used to have the model that every host was its own site. So every host has to take responsibility for maintaining a mail queue. In this model you should install a full-scale Internet MTA on your system, and when the user hits `send' the local full MTA should accept responsibility for it - putting it in the queue, and delivering/retrying as necessary. Nowadays people often prefer to have simpler `client' systems, many of which run some kind of UN*X. In this situation you may indeed not want to try to support and maintain a full MTA on such a client machine; instead, you have your some simpler (or more simply configured) software locally which attempts delivery to a mail hub, and the mail hub performs the necessary queueing etc. In this model when the user hits `send' the local mail software should immediately attempt to pass the message to the mail hub and report success only if and when the mail hub says `OK'. When the mail hub is down no-one can send mail, and attempts to do so can hang unpleasantly. Both of these are sensible models. Moreover, they have _identical_ requirements for the functionality and semantics of /usr/lib/sendmail: in all cases, the calling program _must_ wait for sendmail to exit and check the exit status (since on a modern UN*X, and many older ones, system resource problems can always cause failures). When the local /usr/lib/sendmail exits nonzero it has taken responsibility for the delivery of the message. What this means in the two models is different: with the full MTA it means that the message has been queued; with client-and-hub it means that the message has been transferred to the mail hub (possibly by SMTP) and the mail hub has accepted it. What this shows is that this is a matter of _system configuration_, not a matter of _MUA configuration_. Emacs shouldn't need to know which model is in use. Now let us consider options to /usr/lib/sendmail. The option set was designed for the traditional full MTA model. With queueless client passing mail by SMTP to a hub, most of these options don't make any sense. The SMTP spec says that the hub should say `OK' as soon as it has received the message, without performing a delivery attempt, and there is no way for a client to request specific error behaviour; if delivery fails later the hub is supposed to generate a bounce. So an SMTP client implicitly gets (from the hub) the behaviour equivalent to -odq with a mixture of reporting error codes now or bouncing later depending on when the hub detects the error. >>From the point of view of a MUA on the client, a MUA passing `-odq' couldn't possibly mean putting the mail in the local queue, since there isn't one. If the system is supposed not to have a local queue, but passing -odb or -odq overrides this and puts the message in it, then this is a configuration problem. > This approach also has the disadvantage that any errors > that CAN be detected (and reported to the user) immediately, probably > won't be, since /usr/lib/sendmail will always just push the message on > the queue, without doing any error checking or simple delivery > attempts. Errors which depend on information from the global Internet, or dependent on the outcome of local delivery attempts, can't in general be detected during the time which it's reasonable to wait when sending mail. Simple local addressing errors can easily be detected anyway when the mail is queued. Of course the current Emacs default is that any errors which are detected by the MTA are not reported anywhere. For example, if you make a mistake while editing the headers of your mail, and commit a syntax error, your mail will silently vanish (depending on local MTA and configuration). Ian.