Keith Moore wrote:
I intended <anonymous(_at_)[]> as an example, not as a
well-thought, concrete proposal.
The general form is any(_at_)[] with any valid local part. It's
less flexible than any(_at_)thing(_dot_)invalid, 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(_at_)[] instead
of numerous me(_at_)privacy, nobody(_at_)spamcop, anon[127.0.0.1], and
similar ad-hoc "inventions". Let alone user(_at_)no(_dot_)spam 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(_at_)[] is better.
Bye, Frank