Folks, Good morning. Take a breath and try this with a cup of coffee or tea...
1. The more features a specification has, the more opportunity for an implementer to make an error, starting with the potential misreading or ambiguities in the specification text. Also, the more expensive to do testing and support. So, a feature needs to have significant benefit, to counter the added complexity and potential errors.
2. The more configuration options there are, the more opportunity for an operations administrator to make an error. So an option needs to have significant benefit, to counter the added complexity and potential errors.
3. Simple for one does not mean simple for many. Works for one does not mean works for all. Works for a sender does not mean works for a receiver and doesn't mean actually useful for any.
4. Having a large sender use a potentially problematic feature on a continuing basis, with mail sent to a wide range of receivers, is probably is a good indicator that the feature is -- or, at least, c an be -- benign. It does not, however, indicate that it will be benign for all senders, nor that it is actually useful.
5. Having a feature be acceptable for a sender does not mean that the receivers understand it or do anything meaningful with it.
6. In the early days of anti-abuse, IP addresses were the only easy and reliable identifier to use, to label sending sites. It is still easy, but use at scale makes it less reliable for email. It is a single-hop identifier and it requires listing all potential sending addresses. This is well-documented as an administrative challenge.
7. The myth that SPF is simple to implement is because it is simple for a sender to create a basic SPF record. It does not mean that it is simple to create a more elaborate record, or to ensure that all authorized sending sites are list. Nor does it mean that it is simple for a receiver to provide fully-conformant processing.
SPF's design encourages validation failure. The combination of using IP Addresses and configuration and use complexity make operational errors likely. So does any form of multi-hop handling.
While SPF is entrenched, and challenges to its use typically gets a casual claim that it provides incremental benefit where DKIM fails, I believe there is no published data demonstrating that the incremental benefit is real and substantial, never-mind enough to warrant adding its complexity to the mix of email operations challenges.
Please consider: If SPF were deprecated, was would be the actual, significant effects on email anti-abuse processes?
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
