On 4/14/15 2:43 PM, Scott Kitterman wrote: > On April 14, 2015 3:13:36 PM EDT, Hector Santos <[email protected]> wrote: >> On 4/14/2015 2:09 PM, Douglas Otis wrote: >> >>> On 4/14/15 10:12 AM, Terry Zink wrote: >>>> That's what we mean when we say it doesn't scale. >>> Dear Terry, >>> >>> TPA-Label operates within its own sub-domain. This >>> sub-domain can be delegated or use DNAME. This means this >>> information can be handled by an organization dedicated to >>> detecting and preventing third-party abuse. In essence, a >>> role likely to entail sending notices to domains and >>> ensuring problems are corrected or having their third-party >>> provisions retracted. A function that Yahoo and AOL dumped >>> on everyone else by (ab)using DMARC. >>> >>> How is the scaling issue really worse than the changes >>> currently required for SPF? In fact, SPF often entails more >>> DNS transactions per use. >> It sure does have a much higher overhead. Just take a look at >> hotmail.com: >> >> "v=spf1 >> 1 include:spf-a.outlook.com >> 2 include:spf-b.outlook.com >> ip4:157.55.9.128/25 >> 3 include:spf.protection.outlook.com >> 4 include:spf-a.hotmail.com >> 5 include:_spf-ssg-b.microsoft.com >> 6 include:_spf-ssg-c.microsoft.com >> ~all" >> >> Six DNS calls at the top level and its final result is a relaxed ~all >> result. That is a super high scale/volume waste of processing. But >> here again is a large company not getting its list of senders >> completed. Doesn't stop SPF. >> >> And with DMARC, hotmail.com has no record, so all receivers will be >> doing high volume wasting calls. >> >> We should not expect anything different for a domain finding its >> network of signers. If it doesn't know its list of signers, then it >> just registered what it can and create a relaxed DMARC policy. > Which is completely orthogonal to the question. Scale for this is about > scaling the data collection and DNS record publishing. > > My essentially one person domain would have a more complex forwarder/mailing > list list than the SPF records of even the largest providers. Dear Scott and Terry,
We had a similar effort focused on world wide abuse that had more than 100 collection points. Processing was automatic and would generate needed zone files in a sequence repeating every 15 minutes administrated by two people. DMARC can be setup to offer similar inputs which need to be compared against a collection of outbound logs. By avoiding the use of SQL, the process should complete with plenty of time to spare using a typical server. Spam traps in addition to DMARC feedback would detect abuse. No guesswork should be involved when done right. There was a larger staff handling logged communications aimed at abuse mitigation. A thankless job that must be done. I was shocked to hear a bulk sender at a recent conference say no one reads their abuse@ mail. I don't recall the provider. There are a few ways to reduce the complexity for each entity performing this process. Domains sharing a similar relationship to your domain could-- a) copy a list of mediators requiring DMARC exceptions. b) find a provider that maintains a _tpa list and delegate your _smtp._tpa. zone. c) find a provider that maintains a _tpa list and then synthesize CNAME responses. See RFC2672. d) find a provider that both maintains a _tpa list and that supports Non-Terminal DNS Name Redirection (DNAME). Even use of draft-levine-dkim-conditional will require a similar list be created to reduce both risk and overhead. Publishing this list in DNS ensures it can safely be distributed and handle the needs of SMTP. SQL methods may not be sufficient. When things go wrong because DKIM-Conditional becomes exploited, you could save the show by having a _tpa zone as a fall back. Murphy's Law, "Whatever can happen will happen." Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
