Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

[Douglas Otis <[e-mail]>]

On May 28, 2014, at 12:07 AM, Brandon Long <[e-mail]> wrote:

> So... 
> 
> I think this buries the lede a bit more than the OAR suggestion does.  I could imagine something like this for broadcasting who a service trusts the OAR header from.
> 
> This basically would require someone like Yahoo/Gmail to host some 30k DNS records granting any one of those third party services the ability to send mail for yahoo.com/gmail.com.
> 
> For a service at this scale, you'd need to only do this for places where you "trust" their Authentication-Results header.  There is a potential issue of conflicting AR headers, which is one benefit of the OAR.
> 
> Its not clear to me that gmail.com needs to tell another service to trust the OAR from a given third party, the choice to trust that service could easily be up to the receiving service.
> 
> Finally, doesn't this imply a potentially large number of DNS queries?  Given the various mechanisms for finding the domain, and given that you have to look up the tpa record to know whether that mechanism is supported, it would seem you would need to look up tpa records for up to 7 possible domains, and potentially more with sub-domain checking.

Dear Brandon,

http://tools.ietf.org/html/draft-kucherawy-original-authres-00

You'll see statements in the TPA-Label draft about including authentication-results and indeed this new header should be referenced as well.  Sorry about the omission. When there is a problem, the DMARC domain is still unable to respond to what might cause expensive damage when misplaced trust leads to customer attrition whenever uncontrolled sources are allowed to flood inboxes spoofing their identity.  The TPA-Label draft permits an effective response in minutes.

TPA-Label does not imply a large number of DNS transactions, unlike SPF or even DKIM.  TPA-Label is a single transaction directed toward a DMARC domain. There should only be one DMARC domain recognized per message.  Of course, as with any DNS transaction, this can be redirected to other domains.  It is still a single transaction, unlike SPF which can result in more than 100 transactions with any number of additional redirections involving other domains completely unrelated to domains seen in the exchange.  The TPA-Label can assert which validation methods should be used to help further reduce the number of DNS transactions needed. 

A shared DMARC-bypass whitelists would remove control away from the DMARC domain that has an incentive to ensure protection.  Community white-lists would make responding to any abuse impractical, to say the least.  In today's environment, an ability to respond should not be overlooked.

A TPA-Label authorization would not be granting anyone the ability to send email for a domain.  This authorization simply permits alignment exceptions for specific third-party services that must still permit the validation of their own domain.  The authorization can also stipulate third-party domains must include their domain in a Sender or a List-ID.  If a problem is seen by any of their messages, the DMARC domain can retract authorization in minutes.  Those who apply DMARC alignment checks would be able to make exceptions for these third-party messages based on advice given directly from the DMARC domain.

TPA-Labels as a disruption remedy can be done fairly rapidly since this would involve only those implementing DMARC.  Changing 30K mailing lists where one might be running in the basement of a local church should be expected to take much longer.

Google already provides free recursive DNS for anyone to use.  It seems possible, Google could even get the ball rolling by offering a "_smtp._tpa.gmail.com" zone that others might wish to reference.  This would allow an easy and immediate solution for any DMARC domain willing to allow Google to manage their third-party services.  TPA-Labels will require the support of some large ISP before is likely to gain adoption.  I'll update the draft to include draft-kucherawy-original-authres-00.

Regards,
Douglas Otis 

> On Tue, May 27, 2014 at 7:49 PM, Douglas Otis <[e-mail]> wrote:
> Dear DMARC WG,
> 
> A draft has been submitted for review.  It covers past failures while also providing a path forward.
> 
> I have experience with similar systems operating at much higher scale without difficulty or using much in the way of resources.  Serving several very large ISPs worth of users making queries against every received message that then returned about 2 billion unique resource responses. Originally, the service was free.
> 
> In the wake of a massive compromise of accounts, some fairly large ISPs are doing perhaps the only thing that is not (yet) ignored, DMARC.
> 
> However, this new scheme only needs to sustain queries against already validated third-party domains, but that then fail DMARC alignment assertions. The number of resource records likely needed by large ISPs will be in the 10s of thousands.  For smaller domains, this will likely only be a hand-full.  Domains asserting DMARC alignment practices are receiving cooperative feedback from many receivers who are also acting on behalf of these domains to either reject or quarantine non-aligned messages.  Comparing this feedback against their own outbound logs should permit fairly automatic alignment exception list creation that can then be kindly offered to their cooperative receivers.  These record permit several mitigation strategies in the case of trouble. This scheme should reduce the amount of feedback collected or support required to deal with broken services.  This can be done by creating an informal federation of third-party providers.  Perhaps one of the requirements for being included in the federation would be to provide normal DMARC feedback. ;^)
> 
> http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf
> 
> Regards,
> Douglas Otis