Re: Mail sent to midcom (fwd)

Dave Crocker <dhc2@dcrocker.net> Fri, 02 February 2001 23:30 UTC

Received: by ietf.org (8.9.1a/8.9.1a) id SAA04953 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 18:30:02 -0500 (EST)
Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04884 for <ietf@ietf.org>; Fri, 2 Feb 2001 18:28:42 -0500 (EST)
Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA13609; Fri, 2 Feb 2001 15:28:44 -0800
Message-Id: <5.1.0.7.2.20010202150501.030fa008@dcrocker.songbird.com>
X-Sender: dhc2@dcrocker.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta)
Date: Fri, 02 Feb 2001 15:16:36 -0800
To: ietf@ietf.org, poised@lists.tislabs.com
From: Dave Crocker <dhc2@dcrocker.net>
Subject: Re: Mail sent to midcom (fwd)
In-Reply-To: <Pine.BSF.4.21.0102020947310.14749-100000@two.elistx.com>
References: <200102012108.QAA26209@astro.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Loop: ietf@ietf.org

At 10:12 AM 2/2/2001 -0500, James M Galvin wrote:
>I called it illegal because a localpart should be opaque outside its
>local environment.  I tried to find a reference to this effect in some
>standard but couldn't.  It may just be "practiced wisdom" but I can not
>remember a time when it wasn't true.

MUST be opaque, not should be.

Not only has it always been true, but it has usually caused problems when 
violated.

The language in RFC822bis 
<http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-09.txt> is 
definitive, though not as obnoxiously forceful as seems to be needed, to 
make the point for this thread:

>>3.4.1. Addr-spec specification
>>...
>>
>>The local-part portion is a domain dependent string. In addresses, it is
>>simply interpreted on the particular host as a name of a particular
>>mailbox.


Firewalls and proxies are exceptions that I personally explain in terms of 
their being authorized on behalf of the "particular host".  There is some 
operational fantasy to that explanation, given that the agents are 
typically operated by a different group than the ones running the email 
user software, but it is the real theory that such agent services work on.

That it, such agents are part of a common administrative domain which 
authorizes their messing with the data.

Stray relays and services that are out it the great beyond of the general 
Internet are NOT so authorized.  They are MUCH more likely to interpret the 
local-part incorrectly

d/