In <431204FB.656@xxxxxxxxxxxxxxxxx> Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf