Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[Douglas Otis <[e-mail]>]

Dear Hector,

See comments inline:

On Jul 16, 2014, at 9:51 AM, Hector Santos <[e-mail]> wrote
>>>   References
>>>   ----------
>>> 
>>>   DMARC - http://dmarc.org
>>>   SPF - RFC7208
>>>   DKIM - RFC6376
>>>   Internet Message Format - RFC5322
>>>   OAR / Original Authentication Results -
>>>      draft-kucherawy-original-authres
>>>   Using DMARC -  draft-crocker-dmarc-bcp-03
>> 
>> This is missing two citations that I thought were supposed to be
>> included, since they touch on indirect email flows:
>> 
>>   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
>>   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03
> 
> Why not ATPS RFC6541 production?
> http://tools.ietf.org/html/rfc6541
> 
> Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used in both.  Further, there is real high quality commercial "running code" implementations supporting rfc6541.  All of our installations have DKIM+ADSP+ATPS out of the box with their primary domain used for automated first time setup plug and play readiness.

ATPS is not the "lite version" of TPA-Label.  This is explained in 
http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C

ATPS requires DKIM signatures used by Third-Party Services to somehow determine different label encoding methods permitted by ATPS.  ATPS also lacks any discovery or exchange method for this. In contrast, TPA-Label makes NO demands on third-Party services.  None.  Since there is only one encoding method, there is NO guesswork discovering the listing encoding method. 

The extra processing is only done when DMARC indicates non-complaince where the DMARC domain can then indicate whether they have informally federated the domain in question and what if any additional information must be included in the message.  In comparison, processing a new DKIM-ike signature involves greater overhead than that needed to obtain a TPA-Label resource which happens only after the domain in question has been validated.  It seems TPA-Label represents far easier deployment and far less overhead since the Third-Party makes no change to their process and only a single, small, cacheable TPA-Label resource is provided by the DMARC domain.

While the DMARC domain can delegate the domain offering the TPA-Labels, a single server is more than able to handle what would be needed to satisfy the largest email provider, although two should be deployed for redundancy.  If a domain is being abusive, a TPA-Label can even offer a cacheable negative federation response.  TPA-Label is also able to selectively enable specific uses of Sender header fields or specific use of List-IDs.  When there is a problem with a third-party domain that ignores DMARC, the TPA-Label can also require use of OAR headers.  Unlike ATPS, TPA-Label is far easier and is capable of enabling all valid email without causing disruption.

Regards,
Douglas Otis 

 






> --
> Hector Santos
> http://www.santronics.com