In <1098081203(_dot_)20040309074720(_at_)brandenburg(_dot_)com> Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> writes:
With respect to the derivation of the string, RFC2821 is wrong.
The original thinking was that MailFrom did state who the message was
from. But the semantic for _use_ of the value overrides the description
of its source. This was a case of unnecessarily constraining the
permitted source of the value, compared with real-world usage.
For better or worse, you are correct that real-world usage overrides
just about everything. While you point out that the MAIL FROM address
has, effectively, evolved from the original description in RFC821, I
think you are overlooking that it has evolved even more.
At this time, thanks to spammers, a very large percentage of the MAIL
FROM addresses are bogus. The best current practices is to *NEVER*
use the MAIL FROM address for anything. Using it will likely lead to
abuse of innocent third parties. Well, OK, you if you trust a mail
source enough to allow relaying for them, you can likely also trust
that mail source's use of the MAIL FROM address, but the days of open
relays is also gone.
One way to look at SPF (and other designated sender systems) is that
they try to restore some of the historic usefulness of the MAIL FROM
address. Since the MAIL FROM value is close to meaningless right now,
restoring it to all of the historic uses is not as important as
restoring it to being useful for anything.
The same can be said for the HELO domain.
Even using the MAIL FROM address and HELO domain solely for tracking
purposes by putting them in Received: headers is no longer helpful.
It simply leads people who aren't email-geeks into believing in
unverified and unverifiable information about the "source" of spam.
While I think there can be a lot of useful discussion about what the
semantics that SPF defines for the MAIL FROM address and the HELO
domain should be, the immediate problem is to enlighten people that
these strings are currently dangerous to use in any way.
-wayne