ietf-822
[Top] [All Lists]

Re: MTS transparency and anonymity

2005-02-27 10:31:01

On Sun February 27 2005 11:42, Keith Moore wrote:

if anonymous(_at_)[] doesn't quite work, there are similar alternatives 
worth considering.  among them are: 
anonymous(_at_)[0(_dot_)0(_dot_)0(_dot_)0], 

No, see RFC 3330; that's a local net.

anonymous(_at_)[127(_dot_)0(_dot_)0(_dot_)1],

Absolutely not; that's (the recipient's) local host, and there
might well be a mailbox named "anonymous" (or any other legal
local-part) there.

anonymous(_at_)[127(_dot_)255(_dot_)255(_dot_)255],

No, also covered by RFC 3330.

anonymous(_at_)[::0],   
and anonymous(_at_)[::1].

Not valid RFC 2821 syntax.

the null local-part is 
not needed; it is sufficient if the domain is valid syntax but not a 
DNS name.

I thought we were discussing literals rather than names. Either
way, a necessary additional constraint is that every site must
interpret that name or literal as something other than a reference
to its domain (and therefore must treat the local-part as opaque);
otherwise there is a potential for name clashes as with
<anonymous(_at_)[127(_dot_)0(_dot_)0(_dot_)1]>.

also there might be some merit in being able to differentiate between 
"anonymous" mail (where the sender chose to be anonymous) and mail from 
an unknown sender (such as sent from a web form).  so we could have 
anonymous(_at_)[whatever] vs. unknown(_at_)[whatever](_dot_)

Two problems:
1. the only things suitable for "whatever" have problems as
   detailed separately; at best one would need to invent and
   register a new RFC 2821 literal tag and wait decades for
   UAs, TAs, and gateways to be upgraded to support it
2. peeking at the local-part is a layering violation unless
   the domain is yours.  If there is a need to differentiate
   different classes of literal-based mailboxes unassociated
   with any particular site, then multiple registered 2821
   literal tags could be registered (with issues as noted above).