If a particular user or set of users wishes to ignore anonymous
messages, they are of course free to do so; it may indeed be the
case that any such messages received by some such users(s) would
be considered spam. On the other hand, recipients who might
reasonably expect to receive anonymous messages would almost
certainly not use anti-spam software that discards such messages.
Unfortunately this is just not the way things are headed. Users are
increasingly not able to control these sorts of actions being done on
their behalf. For example, Sun filters all incoming mail and summarily
discards everything it thinks is spam. (In fact a recent
misconfiguration led to a bunch of mail being discarded incorrectly.)
I have absolutely no control over this - no way to change filter
threshholds, no personal whitelist, no Bayesian training, no option to
file spam in a spam folder, nothing. And while it is perhaps true that
I wouldn't want and have no business receiving anonymous mail sent to
my Sun account, I deal with large ISP setups all the time and I can
tell you that many if not most of them are similarly set up and are
similarly inflexible.
We need to be careful that we don't let our ideas of "the way things are
headed" (especially in the short term) color our notion of "what it
takes for things to work well". IETF's job is to discover, define, and
state the latter, not to legitimize the former.
MTA transparency is important. It's what allows email to behave
predictably and reliably. We've always known this to be a necessary
condition. It's true that a lot of MTAs don't behave transparently
these days, and it's also true that this invariably has an adverse
effect on the reliability, predictability, and usability of email.
Either we'll find a way to fix the problems that cause people to want
to make email less transparent, or email will cease to be useful.
Either way, the lack of transparency in the MTS is a short-term problem.
(note that transparency isn't the same thing as saying that all MTAs
must blindly relay all messages intact.)
Of course it is hard to tell when the ubiquity of such setups reaches
a point where it truly compromises the general ability to send
anonymous email. But my guess is that if we haven't passed that point
yet we're about to.
Truly anonymous email doesn't exist. Even if there's no From address
there's still a source IP address and port number and timestamp which
can often be traced to the originator. This is in some sense a "name".
The existence or absence of a From field doesn't change that. There
are lots of ways to achieve an effect similar to anonymity, such as
using someone else's "name", using a pseudonym, communicating through
an intermediary, etc., but all of these leave some trace to the
originator. And it's already been aptly demonstrated that miscreants
are at least as capable of establishing apparently-valid "names" for
themselves as the general public. So it seems unlikely that either
anonymity or pseudonymity will be very useful as a discriminator for
mail filters.
As to the proposal:
I'm somewhat sympathetic to the view that one shoudn't bother
including a From field when the reply won't get there anyway.
At the same time, the From field has been required for at least
25 years now, and there's a lot of software out there that was
written to that specification. There's no way we can expect to
survey all of that software to determine whether omission of From
will adversely impact it. Email is already fragile enough (for
instance, due to the filters that Ned refers to) that we should
be very reluctant to create additional reasons for things to break -
particularly when we don't gain any additional functionality to
compensate the public for the breakage. So I'd much rather define some
convention for a non-replyable address (e.g. From: <anonymous(_at_)[]> )
which is at least syntactically compatible with RFC [2]822,
than to say it's okay to omit the From field.
Keith