Julian Hansmann wrote: > * ' ADSP has garnered almost no deployment and use in the 4 years since its > advancement to IETF Proposed Standard.' > * ' 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.' > > Since DMARC is basically ADSP on steroids and more complicated I have the > following -serious- questions: > > * Is there any information available why ADSP has seen so little adoption? > How is this issue addressed with DMARC?
Your "and more complicated" is part of the answer to this: - ADSP required either that domain registrants/owners have a direct relationship with major receivers to arrange private feedback, or that they tolerated blindly setting a policy which would cause widespread undetectable message loss. Needless to say, only the registrants/owners of the largest, most heavily abused domains were in a position to do this. - DMARC addresses this by adding a feedback mechanism that can be configured and used by anyone without requiring direct prior agreement between domain registrants/owners and receivers. These have made it possible for much more widespread adoption. > * Since the mailing lists issue also applies to DMARC and actually became > part of the reason ADSP was dumped (see above) how did you make sure the same > thing won't happen to DMARC? Forwarding of various kinds (not just mailing lists) remains the major sticking point, yes. Several major things have changed that mean that ADSP's fate is unlikely for DMARC: - ADSP was largely a "this seems like a good way for it to work" specification which didn't actually work for much the same reasons as SPF -all[1] and DomainKeys o=- before it. By contrast, DMARC is a public formalisation of a *working* private feedback mechanism developed by/with one of the most heavily phished organisations in the world. - The widespread adoption of the no-prior-agreement feedback mechanism. - Receiver-side implementation by organisations who jointly receive more than half of the world's email. Note that some/all of these are selective about whose quarantine/reject policies they implement, but we appear to have reached a point where a majority are implemented. That the feedback mechanism allows domain registrants/owners to discover and therefore sort out technical errors in their [partner's] environments by themselves is probably a major factor here. - For forwarders this shifted the argument from "it's not our problem to implement the latest fashionable idea which will never actually be important" to "OK, >50% of receivers implementing means that it is important, but it's still not our problem because we were here first!". Most forwarders have therefore already implemented one or more workarounds, e.g. those in https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F , generally changing the end-user experience in non-ideal ways. - The very large increase in domain abuse over the last few years, meaning a much wider spread willingness to tolerate some message loss in order to contain impersonation, which led to a tipping point for a number of large mailbox operators who decided to turn on p=reject for webmail domains. - That DMARC has gotten so far has in large part motivated work ARC, which is likely to allow willing forwarders to help receivers make sensible decisions (particularly about when to override p=reject policies) without altering the end-user experience. - Roland 1: To be fair, SPF had a feedback mechanism, but (a) it had delivery-time performance impact for receivers and (b) it was technically difficult to use because it required specialist DNS capabilities for the domain owner/registrant. _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
