Re: MTS transparency and anonymity

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

No, see RFC 3330; it's only intended for use as a _source_ address.  
Trying to connect to the address fails on every platform I know of.

note that there are a lot fewer TCP/IP stacks in wide use than there 
are mail-handling programs.  it's much easier to be confident about the 
behavior of an IP stack.

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

so use an invalid address, rather than a loopback address.  or just 
pick a very obscure local-part.  anyone who really wants to accept mail 
at
-anonymous-@[127.0.0.1]
deserves to get replies from anonymous mail.  and if he doesn't want to 
get such replies, it's a solvable problem.

also, if it happens that a dns query for example.com yields ip address 
X, it should not be assumed that [email protected] is equivalent to 
user@[X].  the only requirement for domain literals is that the 
postmaster address work.

>> anonymous@[127.255.255.255],
>
> No, also covered by RFC 3330.

and if the host correctly implements RFC 3330 ("no addresses within 
this block should ever appear on any network anywhere") then this will 
work just fine, as the host IP stack will return an error when the MTA 
tries to connect to that address.

>> anonymous@[::0],
>> and anonymous@[::1].
>
> Not valid RFC 2821 syntax.

sounds like a bug in RFC 2821.  but if the MTA strictly implements RFC 
2821 and rejects the message at RCPT time, that's perfectly okay.   it 
doesn't really matter whether the MTA rejects the address because the 
local-part doesn't exist or because the domain has an invalid syntax, 
as long as it fails.

>> 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;

see above.  I think you're trying too hard to find problems with 
alternatives to your proposal while failing to recognize the problems 
with yours.

> 2. peeking at the local-part is a layering violation unless
>    the domain is yours.

for MTAs and UAs, yes.  not for humans.  of course one could also 
differentiate such cases by using

Anonymous <anoymous@[0.0.0.0]>
vs
Unknown Sender <anonymous@[0.0.0.0]>

Keith