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.
No, see RFC 3330; it's only intended for use as a _source_ address.
Trying to connect to the address fails on every platform I know of.
Well, we're talking about a mailbox in the From field, which has
semantics of a source if anything.
nice try. but in practice if you try to connect to 0.0.0.0 you'll get
an error, which is what we want to happen.
note that there are a lot fewer TCP/IP stacks in wide use than there
are mail-handling programs. it's much easier to be confident about
the
behavior of an IP stack.
Maybe. I recall early implementations where 0.0.0.0 is a
broadcast address; not all of those implementations have vanished.
I've never seen one. I've seen lots of implementations where the lower
bits of a subnet were the broadcast address, but that's a different
issue.
But that's really a digression from the issue, because no IPv4
address has semantics of either "anonymous" or "not on the
Internet"
nor, for that matter, does any domain. but it's easier to find an IPv4
address that has desirable properties than it is to find a domain that
has them.
I mentioned RFC 3330 because I looked through it in search of
just such an invalid (IP) address, and could find none guaranteed
to remain invalid. And I looked rather closely at 0.0.0.0 and
127.0.0.1.
either 0.0.0.0 or 127.0.0.2 seems to work well as far as I can tell.
also, if it happens that a dns query for example.com yields ip address
X, it should not be assumed that user(_at_)example(_dot_)com is equivalent to
user(_at_)[X](_dot_)
That's not the problem, nor even related to the problem. The problem
is that there may be an SMTP (or other mail protocol) server listening
on the loopback address, and any local-part might be a valid one on
some such system.
yes, it might happen. but you can pick a local-part such that it's
extremely unlikely to happen - less likely to happen than numerous
other kinds of failures. even so, 127.0.0.1 would not be my first
choice.
anonymous(_at_)[127(_dot_)255(_dot_)255(_dot_)255],
No, also covered by RFC 3330.
and if the host correctly implements RFC 3330 ("no addresses within
this block should ever appear on any network anywhere")
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."
then this will
work just fine, as the host IP stack will return an error when the MTA
tries to connect to that address.
You again seem to be focusing on non-replyability, which isn't the
topic of draft-lilly-from-optional.
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.
anonymous(_at_)[::0],
and anonymous(_at_)[::1].
Not valid RFC 2821 syntax.
sounds like a bug in RFC 2821.
You're certainly free to make a case for that. The legal 2821 versions
of IPv6 domain literals would be something like [ipv6:::0]. Yes, it's
ugly.
hey, I'd be fine with anonymous(_at_)[ipv6:::0]
or perhaps even anonymous(_at_)[no-such-network:]
but if the MTA strictly implements RFC
2821 and rejects the message at RCPT time, that's perfectly okay.
OK for what? For preventing a response (assuming that the message
gets to a recipient)? Again, that's not the subject of the draft.
no, but it's the most important technical constraint on the convention
for an anonymous address. see above.
it doesn't really matter whether the MTA rejects the address because
the
local-part doesn't exist or because the domain has an invalid syntax,
as long as it fails.
Are you discussing transport, or the message format?
I'm discussing what it takes to make something like this work in
practice. anything that isn't reasonably compatible with existing
MTAs/MSAs is a non-starter.
So far as I can see, there is no perfectly clean solution to the
issues covered in the draft. However, simply making the From
field optional -- while that may present some issues -- seems to
have the least negative impact of the options considered (including
syntax changes and extension, which present rather more serious
backwards compatibility issues than making the field optional).
I disagree. Too many things extract data from the From field.
2. peeking at the local-part is a layering violation unless
the domain is yours.
for MTAs and UAs, yes. not for humans.
If there's something there indicating either a domain or a local-part
within a domain, it fails to provide the desired semantics, viz.
nothing (i.e. no mailbox). That itself is not a showstopper, but in
conjunction with the requirements for gateways, it presents some
obstacles.
so use the loopback address domain literal. then it's yours, and you
can define anonymous addresses however you want :)
(not a serious proposal - but IMHO you're making way too big a deal of
semantic issues based on strained reading of the specifications and
giving far too little concern to interoperability with the installed
base)