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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: MTS transparency and anonymity, (continued)
- Re: MTS transparency and anonymity, Keith Moore
- Re: [0.0.0.0] (was: MTS transparency and anonymity), Claus Assmann
- Re: [0.0.0.0], Russ Allbery
- Re: [0.0.0.0], Keith Moore
- Re: MTS transparency and anonymity, Bruce Lilly
- Re: MTS transparency and anonymity,
Keith Moore <=
- Re: MTS transparency and anonymity, Bruce Lilly
- Re: MTS transparency and anonymity, Keith Moore
- Re: MTS transparency and anonymity, Bruce Lilly
- Re: MTS transparency and anonymity, Keith Moore
- Re: MTS transparency and anonymity, Charles Lindsey
- Re: MTS transparency and anonymity, Tony Finch
- Re: MTS transparency and anonymity, Keith Moore
- Re: MTS transparency and anonymity, Tony Finch
- Re: MTS transparency and anonymity, Keith Moore
- Re: MTS transparency and anonymity, Tony Finch
|
|
|