From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28084 Path: main.gmane.org!not-for-mail From: patl@cag.lcs.mit.edu (Patrick J. LoPresti) Newsgroups: gmane.emacs.gnus.general Subject: Re: Fully-qualifying Email addresses in outgoing mail Date: 10 Dec 1999 15:20:50 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035164993 27979 80.91.224.250 (21 Oct 2002 01:49:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:49:53 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id PAA27618 for ; Fri, 10 Dec 1999 15:21:56 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id OAB28191; Fri, 10 Dec 1999 14:21:51 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 10 Dec 1999 14:21:58 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id OAA16391 for ; Fri, 10 Dec 1999 14:21:46 -0600 (CST) Original-Received: from egghead.curl.com ([216.230.79.4]) by sclp3.sclp.com (8.8.5/8.8.5) with SMTP id PAA27604 for ; Fri, 10 Dec 1999 15:21:23 -0500 (EST) Original-Received: (qmail 6860 invoked by uid 10171); 10 Dec 1999 15:20:50 -0500 Original-To: ding@gnus.org In-Reply-To: Stainless Steel Rat's message of "10 Dec 1999 14:09:24 -0500" Original-Lines: 104 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:28084 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:28084 Stainless Steel Rat writes: > Yes. An Internet mailbox has a fully qualified domain part. If the > mailbox has no fully qualified domain part, it cannot be an Internet mail > message. It must be a local message because there is nothing else it could > be (I'm leaving things like X.400 out of it). Right, and approximately zero people ever send an Email message which they do not intend as an Internet mail message. > | So a user composing mail on a Windows laptop, which has no message > | queue, must type in a fully-qualified name every time? Of course not. > > That's what address books are for. Great. So a new entry must be added to every address book for every new account? Absurd. Almost all people compose Email as members of an organization, not as users of a particular machine. They expect Email to "bob" to mean "bob in my organization", not "bob on this computer". A laptop MUA which interprets it in the former way is *not* broken; quite the contrary. > How do you intend to make this work reliably? I have a machine that > can [snip] The same way "From" lines work reliably. An unadorned name means "in my default domain". > | (The reason for this is obvious: Recipients in foreign domains need to > | see fully-qualified addresses or they can't follow-up.) > > You have just switched gears. To and Cc should never be rewritten for > canonicity, but because the user is sending to a foreign domain a fully > qualified domain part must exist in the To or Cc headers, so rewriting is > not necessary. No!!! This is the crux of the entire problem; you are forgetting about multiple recipients. Suppose I work at FooCorp. If I address a message to both "myboss" and "bigshot@bar.com", Mr. Bigshot cannot follow-up properly unless somebody somewhere canonicalizes "myboss" into "myboss@foo.com". The obvious place for this to happen is in the MUA; how the hell are the SMTP daemons supposed to know whether and how to do this job? > | Which would be superior behavior for almost all users. And I am > | suggesting this as an option, not a requirement. > > But it would still be wrong because I specified that the message be > delivered locally. No, you did not specify anything at all, and you are insisting (erroneously) that this must mean "deliver locally". Approximately nobody means that when they use unqualified addresses. > And by the way, the BBDB has mailbox completion. Only useful if I can have it complete on ALL names, not just the ones in bbdb. > | Do you agree that bare addresses must not appear in a SMTP message, as > | the RFC specifies? > > Just to keep the terminology straight, it is an RFC 822 message. SMTP is > RFC 821 (et al) and defines *how* a message gets from one machine to > another, not the format of the message. RFC 822 defines the format of an > Internet mail message. It says nothing about other mail message formats. > > And yes, unqualified mailboxes are invalid in an RFC 822 message. But a > message to be delivered to `patl' is *not* an RFC 822 (Internet mail) > message, as I pointed out before. So it must *not* be delivered with SMTP. Again, message-mode/smtpmail are buggy if they ever try to deliver such a message. > [...] > | Note that sendmail rewrites the addresses whether you invoke it from > | the command line or talk to it via smtp. The latter is the only > | reason smtpmail.el works at all. > > sendmail does not rewrite To or Cc. Wrong. Of course sendmail rewrites recipient addresses, because otherwise everyone would have the same problems with multiple recipients that we are having (see above). > | Qmail (correctly) only rewrites addresses when you invoke it on the > | command-line. This behavior is configurable, of course. > > Then qmail does the wrong thing by turning a local message into an > Internet message. Adding qmail's brokenness to message will break > message-mode. Providing the most useful functionality to users is never "broken". Can you quote any standards document at all which says unqualified addresses are the same as specifying the local machine? A different interpretation is vastly more useful to everyone except for you. And I am merely suggesting that the other interpretation should be offered as an option. - Pat