ietf-822
[Top] [All Lists]

Re: MTS transparency and anonymity

2005-02-28 06:19:07

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(_at_)[ipv6:::0]

or perhaps even anonymous(_at_)[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(_at_)[0(_dot_)0(_dot_)0(_dot_)0], maybe something short like anon(_at_)[0(_dot_)0(_dot_)0(_dot_)0] or something like 0(_at_)[0(_dot_)0(_dot_)0(_dot_)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(_at_)[127(_dot_)0(_dot_)0(_dot_)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