Dear Hector, See comments inline: On Jul 16, 2014, at 9:51 AM, Hector Santos <hsantos@xxxxxxxx> wrote
ATPS is not the "lite version" of TPA-Label. This is explained in 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
|