On Sun February 27 2005 11:42, Keith Moore wrote:
if anonymous(_at_)[] doesn't quite work, there are similar alternatives
worth considering. among them are:
anonymous(_at_)[0(_dot_)0(_dot_)0(_dot_)0],
No, see RFC 3330; that's a local net.
anonymous(_at_)[127(_dot_)0(_dot_)0(_dot_)1],
Absolutely not; that's (the recipient's) local host, and there
might well be a mailbox named "anonymous" (or any other legal
local-part) there.
anonymous(_at_)[127(_dot_)255(_dot_)255(_dot_)255],
No, also covered by RFC 3330.
anonymous(_at_)[::0],
and anonymous(_at_)[::1].
Not valid RFC 2821 syntax.
the null local-part is
not needed; it is sufficient if the domain is valid syntax but not a
DNS name.
I thought we were discussing literals rather than names. Either
way, a necessary additional constraint is that every site must
interpret that name or literal as something other than a reference
to its domain (and therefore must treat the local-part as opaque);
otherwise there is a potential for name clashes as with
<anonymous(_at_)[127(_dot_)0(_dot_)0(_dot_)1]>.
also there might be some merit in being able to differentiate between
"anonymous" mail (where the sender chose to be anonymous) and mail from
an unknown sender (such as sent from a web form). so we could have
anonymous(_at_)[whatever] vs. unknown(_at_)[whatever](_dot_)
Two problems:
1. the only things suitable for "whatever" have problems as
detailed separately; at best one would need to invent and
register a new RFC 2821 literal tag and wait decades for
UAs, TAs, and gateways to be upgraded to support it
2. peeking at the local-part is a layering violation unless
the domain is yours. If there is a need to differentiate
different classes of literal-based mailboxes unassociated
with any particular site, then multiple registered 2821
literal tags could be registered (with issues as noted above).