> If SPF were deprecated, was would be the actual, significant effects on email
> anti-abuse processes?
* DKIM+DMARC do not verify the return address. So backscatter spamming would
get more attractive to spammers, unless every receiver implemented some form
of BATV. Which would be yet another thing to implement. Unless anyone knows
of other solutions to this.
* I agree with others that SPF is much easier to set up than DKIM, as no
changes need to happen to the sending infrastructure itself. This makes DMARC
adoption much easier.
Groetjes,
Louis
Op woensdag 16 oktober 2024 om 18:00, schreef Dave Crocker via mailop
<mailop@mailop.org>:
> 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 [dcrocker@mastodon.social]
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
