In <431204FB(_dot_)656(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
John Glube wrote in mxcomp:
I should have written:
|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services, both external
|and internal to facilitate the delivery of ham, while rejecting
|spam [1]
That was not the main purpose of SPF. "SHOULD check HELO" was
added in 2005, because it was always allowed and possible, and
it makes sense for the reasons you have stated.
The "SHOULD check HELO" was added in 2004, not 2005. This was changed
to "RECOMMENDED" in 2005.
But the main idea of SPF is to get rid of backscatter, numerous
bogus bounces / challenges / other auto-responses to forged
Return-Paths. With side effects, some hard, others desirable.
The DKIM proto-WG is currently going through the process of trying to
specify "What is DKIM intended for?" It's a good idea and one that
the SPF folks skipped in 2003.
So, I disagree that main idea of SPF is to get rid of backscatter and
such. That is certainly *one* of the reasons that *some* (maybe even
most) people had for promoting SPF, but certainly not the only reason.
Other reasons include the desire by domain owners to not have their
domain name forged in the MAIL FROM and HELO domains, whether they
caused backscatter or not. Also, by creating identities that could be
verified, you could make more reliable use of whitelists and
blacklists. Another is that it could be used as a basis to help
protect the 2822.From: header, if you can correctly identify the cases
where the 2821.MAILFROM will differ from the 2822.From:. I suspect
that there are going to be several other answers from other SPF
supporters.
If your only goal is to get rid of backscatter, things like SES do a
much better job.
-wayne
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf