I think the DMARC RFC does a good job explaining why DMARC is better than ADSP, even if the same mailing list issue is still there: https://tools.ietf.org/html/rfc7489#appendix-A.5
And if you read the archives on the move to historic for adsp, there were others then who objected to the reason put in the historic move as likely as affecting the replacement . Given the success of the replacement, it stands to reason that the reasoning given in the move to historic was not the full reason for the failure... and perhaps lends credence to the thought that certain folks are more concerned about the effects on mailing lists than the ecosystem as a whole is. Brandon On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton <[email protected]> wrote: > On 8/15/20 3:53 PM, John Levine wrote: > > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief for making the most > strict policy "discardable" even though that's obviously what it was. > > > And even with the kinder-and-gentler term "discardable" for its most harsh > policy option, ADSP was moved from Standards Track to Historic. From > https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ : > > There is, however, evidence of harm caused by incorrect configuration and by > inappropriate use. There have, for example, been real cases where a > high-value > domain published an ADSP record of "discardable", but allowed users on their > domain to subscribe to mailing lists. When posts from those users were sent > to > other domains that checked ADSP, those subscriber domains rejected the > messages, resulting in forced unsubscribes from mailman (due to bounces) for > the unsuspecting subscribers. > > Assurances that are provided by ADSP are generally obtained out of band in the > real Internet, and not through ADSP. Current deployment of ADSP is not > recommended. > > Is that not exactly the same situation with DMARC, except that the policy > in question now is "reject" rather than "discardable"? Yes, it's just a > keyword, but it reflects the semantics of the expected action as well. > > -Jim > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
