In <01LL6IT7FRKQ00005Q(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
We already do know: Alteration of message content between submission and
delivery is done routinely for all sorts of reasons, some good and some not so
good. Pretending otherwise is simply not realistic. I will also add that
blaming sendmail for this or getting wrappped up in terminology (e.g., a
gateway can do blah blah but an MTA cannot) is pointless and silly.
However, it isn't clear to me that the reality that messages are routinely
modified by the transport infrastructure in and of itself poses a unsuperable
obstacle for the draft being discussed here. To the extent that message
modification impinges on missing From fields, I believe they do so by filling
in the field with "something". Common choices for "something" include:
(0) The envelope from address (if present).
(1) An address derived from available authentication information. (The
information can come from SASL AUTH, TLS, or even some entirely
external mechanism like RADIUS.)
(2) A known-bogus address (e.g., missing-address(_at_)missing-domain)
(3) A mail administrator address of some sort.
I think you need to add
(4) A known not-obviously-bogus address. Could be something you are
regularly used to seeing in messages, such as MAILER-DAEMON@, or a mail
administrator using his own address rather than one pertaining to his
function, or the -request or -owner address of a mailing list.
Note that sendmail currently does (0).
The only one of these that poses a significant problem is (1) since it can have
the effect of revealing exactly the information the sender needed to have
hidden. The others mostly have nuisance value and nothing else. (1) is a real
risk and needs to be called out in the draft, but I don't think the practice is
so common that by itself it will preclude deploying this change.
I think it is just up to someone who wants to be truly anonymous to be
careful to use a service that does not reveal his identity, such as one of
the anonymising services such as privacy.net.
These days one of the things spam filters commonly do is to check various
aspects of message syntax, including but not limited to the message having all
the mandatory header fields.
Or that it contains addresses such as <>, etc. Some people would think
that these things are features rather than bugs :-) .
This issue is exacerbated by the fact that the spam landscape changes
constantly and so do the countermeasures undertaken to stop it.
But that actually works in our favour here. If we introduce some new
feature into the standards, such as non-mandatory From, or "<>" as a valid
addr-spec, or whatever, then it will be a long time before the bulk of
agents worldwide catches up. So we have to look at the bahaviour of
existing agents and decide which solution to the alleged problem will have
the least adverse effect (and I don't think that will turn out to be the
non-mandatory From).
But spam traps are continually being updated. They have to be, or they
will no longer work. Anybody using a spam filter untouched from two years
ago will find that current spam is passing straight through it. Therefore,
the timescale on which spam filters are upgraded is almost an order of
magnitude shorter than the timescale on which people upgrade their MTAs
and MUAs.
So if a fashion delelops for "legitimate" anonymity, which seems to be the
intent of this proposal, then spam filters will be upgraded to recognize
it (whether to pass it or to bar it) in pretty short order.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5