Re: MTS transparency and anonymity

Keith Moore wrote:
 
> I intended <anonymous@[]> as an example, not as a
> well-thought, concrete proposal.

The general form is any@[] with any valid local part.  It's
less flexible than [email protected], but good enough where
it's supported.  Probably some news servers already support
TLD .invalid, but cannot yet handle an empty domain-literal.

Possible objections:  

1 - TLD .invalid can't be hardwired as an invalid TLD, only
    DNS can decide this.  That's wrong, the specification
    explicitly says that TLD .invalid is always (guess).

2 - If TLD .invalid is identified by some UAs to be (guess),
    then it can't be used for DNS tests.  That's true, but
    the specification explicitly offers TLD (guess) for tests.

3 - TLD .invalid might be a bad idea in examples.  That's why
    there is another TLD (guess) especially for examples.

4 - What if somebody needs a "real" TLD for local purposes ?
    BCP 62 offers TLD .localhost for this case, there's no
    reason to use TLD .invalid for anything but (guess).

5 - The DNS root servers would be flooded by stupid queries.
    That's utter dubious, in fact TLD .invalid is the only
    TLD guaranteed to be invalid without a DNS query, so if
    bogus TLDs in munged addresses are a problem, then using
    TLD .invalid could minimize this problem.

And bogus addresses are a problem, if UAs offer to compose
replies without displaying the address (maybe it's a text
mode UA with a blind user).  Therefore it's good to have 
some clear conventions like TLD .invalid or any@[] instead
of numerous me@privacy, nobody@spamcop, anon[127.0.0.1], and
similar ad-hoc "inventions".  Let alone [email protected] etc. :-(

> I do think it makes more sense to use a domain literal of
> some kind rather than a domain name that could cause DNS
> queries.

Yes, but if it "must" be a domain name then it should be TLD
.invalid for an invalid domain.  Otherwise any@[] is better.

                        Bye, Frank