Re: MTS transparency and anonymity

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

> if anonymous@[] doesn't quite work, there are similar alternatives 
> worth considering.  among them are: anonymous@[0.0.0.0], 

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

> anonymous@[127.0.0.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@[127.255.255.255],

No, also covered by RFC 3330.

> anonymous@[::0],   
> and anonymous@[::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@[127.0.0.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@[whatever] vs. unknown@[whatever].

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).