Re: MTS transparency and anonymity

>> you'll get
>> an error, which is what we want to happen.
>
> No, what we want to have is either a clear indication of lack
> of an author mailbox (preferred, if practical), or a lack of
> any indication of an author mailbox.

they're not mutually exclusive.  one is the goal, the other is a 
necessary condition.

>>> Yes, the loopback connection is supposed to be internal to the IP
>>> implementation, and not be translated to any physical network.  That
>>> still doesn't have semantics of "anonymous" or of "nonexistent"; it
>>> has semantics of "here".
>>
>> in practice, it has the semantics of "nowhere", or "you can't get 
>> there
>> from here, no matter where 'here' is."
>
> If I repeat Claus Assmann's experiment using 127.0.0.1 (the loopback),
> what I get has semantics of "here".

and if you do it with 0.0.0.0 or 127.0.0.2, you get the semantics of 
"you can't get there from here"

>> it's a backward compatibility issue.  MUAs and MTAs that know about 
>> the
>> convention are not the problem, since it's easy for them to recognize
>> such addresses and treat them accordingly. the problem is making this
>> work with MUAs and MTAs that don't know about the convention.
>
>> hey, I'd be fine with anonymous@[ipv6:::0]
>>
>> or perhaps even anonymous@[no-such-network:]
>
> And the backwards compatibility of either is ... ?

hard to say.  my gut sense is that an IPv4 domain literal is less 
likely to break things than an IPv6 domain literal.

>> no, but it's the most important technical constraint on the convention
>> for an anonymous address.  see above.
>
> "anonymous address" is an oxymoron.

no more so than "anonymous" is an oxymoron when used to fill in a 
"name" blank.   the meaning is clear, even if technically its a 
contradiction.

> "<>" (i.e. no mailbox) seems
> less problematical (even with HTTP, SIP compatibility issues) than
> some of the recent proposals.  At least "<>" has some sort of
> precedent (in Return-Path).

<> is illegal syntax, and some things do check.  even those things that 
do parse <> might end up extracting a null string, which could break 
scripts.  and we're talking about email here, not HTTP or SIP.

>> Too many things extract data from the From field.
>
> If the field isn't there, they can't extract anything from it.

and thus may exhibit anomalous behavior.

---

overall, my preference is for something@[0.0.0.0], maybe something 
short like anon@[0.0.0.0] or something like 0@[0.0.0.0] that isn't 
dependent on English and doesn't expect people to know how to spell 
anonymous (ah, for the days when everyone used ftp clients).  I think 
it will be correctly parsed by most M*As.  It is easily identified by 
humans as a "special" address that probably doesn't correspond to a 
real user.

something@[127.0.0.2] would also work, but isn't as easily recognized.  
either of those would be better than [127.0.0.1] or an ipv6 literal.

  <> and omitting From entirely are my least favorite alternatives.

most of this is informed by my sense of what M*As are likely to be able 
to tolerate, which may be different than others' sense.

Keith