Re: MTS transparency and anonymity

> > > > 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"
> No, I get what Claus and Russ got, semantics of "here":
so do I, now.  and when I tried earlier I made the mistake of not 
carefully recording what I did and what I got, so now I can't be sure 
what happened.
> > <> 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.
> It's illegal now, but was legal under RFC 733.
nobody cares about 733 anymore.  most things in use today were written 
with 822 in mind.
> HTTP and
> SIP are mentioned because they refer back to the (RFC 822)
> defined syntax of the From field; any change to that syntax
> will affect those protocols as well as the Internet Message
> Format.
no.  they refer to 822, not to some newer specification.  822 hasn't 
changed, and won't change.  HTTP and SIP are separate protocols (with 
their own baggage) and are evolving separately from the email protocols 
(and its baggage).  which is as it should be.
> When you propose such syntax changes, you must consider
> the effects on all protocols affected by the change.
if they are truly affected by the change, yes.  but it's not as if HTTP 
and SIP use email as a substrate.
> > 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]
> But Keith, by definition (RFC 3330) 0.0.0.0 doesn't mean anything
> like "anonymous", it means ""this' host on 'this' network", and
> that has been confirmed in practice by experiment on three separate
> systems.  Your assertion otherwise seems to be rather unconvincing.
Frankly at this point I'm not sure what to recommend.   Everything is 
broken in some way or another.  I still think that it makes more sense 
to use a domain literal than a domain.  I still think it will break 
fewer things to have a From field with an actual address than to have 
no From field or From:<>.  But I share at least some of your dislike of 
connecting to the loopback address (or something that acts like the 
loopback address).  And my gut sense is that a lot of mail parsers will 
fail if an IPv6 domain literal like [ipv6:::0] is used.
Keith