On Thu February 24 2005 13:14, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
RFC 2821 does distinguish between SMTP systems that don't modify messages
(relays) and ones that do (gateways).
You are correct that gateways are not only permitted to modify content,
they are required to ensure that address fields contain content which
is "effective and useful for sending replies" (RFC 2821 sect. 3.8.4).
Indeed, that is one of the reasons that use of an invalid or
unresolvable domain name is not a viable option.
In the case of either anonymity or lack of an Internet mailbox,
"sending replies" isn't a possibility (except in the latter case
given a Reply-To field). I can address this issue more fully in
the next revision.
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.
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.
Either (0) or (1) could defeat anonymity, but they are predicated
on transport mechanisms. The draft is intended to address the
message format issues rather than transport of the content (some
transport mechanisms have an envelope or use authentication; others
do not).
[rearranging comments somewhat...]
Another major problem is that the draft as written deals with the technical
issue of making From: optional but doesn't discuss the myriad security issues
that surround the idea of anonymous email. IMO it is borderline irresponsible
(*) to publish a document that discusses this one small aspect of email
anonymity while not providing any guidance about the more general set of
issues
here. If this is to move forward this material needs to be provided - possibly
by a companion document.
[...]
(*) It is precisely because the potential consequences of breach of anonymity
are so grave that this omission is of such great concern.
Yes, as noted above it deals with the message format rather than
transport (including non-email transport of Internet Message Format
messages such as via Usenet).
Point taken; the next revision will mention the possibility of
transport mechanisms leaking information under security
considerations.
At present a message without a From: field is syntactically illegal.[...]
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.
True; also checks for valid syntax, sometimes additional checks on
address field contents. The draft enumerates 4 possible approaches
to the problems it identifies. Of those, "a" (use of an alternate
mailbox) is itself often used by spammers and results in collateral
damage (inappropriate "bounce" messages, etc.). Method "b"
(theoretically unresolvable domain name) has, in conjunction with
the Verisign SiteFinder "service" resulted in anti-spam problems,
and as noted in the draft is unusable where DNS is unavailable or
otherwise unreliable. That leaves changing the From field syntax
or making the field optional as proposed (unless there is another
possible solution that I missed). Syntax changes would require a
different set of changes to 822 and 2822, and would still be an
issue w.r.t. anti-spam software; additionally, there would be UA
issues related to a very large and diverse installed base having
to be updated to accept revised syntax.
Even if you
assume SpamAssassin is the norm and that using the absence of a From: field as
a check for possible spam doesn't happen at all currently, all it would take
would be a major influx of spam without From: fields to change this. And I
somehow doubt that arguments that this breaks the ability to send mail
anonymously will impress the folks that build anti-spam software much if at
all.
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.