On May 7, 2014, at 2:58 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Tue, May 6, 2014 at 11:03 PM, Terry Zink <tz...@exchange.microsoft.com> > wrote: > This is more or less John Levine's suggestion from several days ago: it is a > whitelist. The difference here is that policy is queried via DNS (along with > a different alignment than the From: addres) rather than distributed and > applied internally as a domain/IP DMARC exclusion list. > > Ideas like TPA, ATPS and others are essentially whitelists owned by the > domain whose mail might get re-signed, versus John's notion of one or more > master whitelists for all known potential legitimate re-signers (e.g., > mailing list operators). The differences between the two proposals amount to > how one queries the whitelist and how one indicates to the receiver that > there's reason to query the whitelist in the first place. > > ATPS made it to RFC (experimental) status and has open source support, but > hasn't seen much uptake. That tells me that this hasn't, at least up until > now, been an interesting problem operators have needed to solve. Dear Murray, ATPS requires third-party services to use specific non-standard DKIM signatures to signal ATPS use, rather than this being signaled in From ADMD policy requests. ATPS also adds a tag in the third-party DKIM signatures to select different label encoding schemes employed by the From ADMD. Both of these changes make deployment difficult as ATPS impacts systems not involved with additional From ADMD acceptance requirements. ATPS might even require additional signatures to support multiple destinations and needlessly break authorizations traversing multiple third-party services that would have been otherwise authorized. SMTP is not a peer-to-peer protocol. ATPS requires new tags be included in third-party signatures of "atps" and "atpsh" to construct a chain of "d=" and "atps=" adding complexity without any security benefit. ATPS imposes additional requirements for third-parties not otherwise benefiting from stricter From ADMD policy requests. As such, ATPS imposes a flag day scenario that also requires an undefined means for third-parties to determine label encoding used by many From ADMDs. Lack of ATPS deployment should have been expected as necessary change was not aligned with benefits. In contrast, TPA did not require ANY change be made by authorized third-parties. > As I recall, TPA is the same as ATPS except that it establishes stricter > requirements on the message in relation to the subject domain, and requires a > query 100% of the time. TPA would only be queried when a message otherwise fails increased requirements expressed in either the From ADSP or DMARC policy requests. So in general, TPA would not occur at every message. It would only impose a single DNS transaction by systems imposing stricter acceptance to determine whether a From ADMD permits a specific third-party. > The problem as I see it is that the various additional requirements don't > really add much new security; the third-party signature is itself a strong > enough signal without also checking that this header field or that one is > present. Adding additional aligned header field requirements can differentiate between user emails and those of a mailing-list, a news-feed, or a third-party billing service. Such scope reductions lessen possible malefactor access. Narrowing authorizations is a prudent option in TPA, but not permitted with ATPS. > The technical implementation of this is not that difficult, I don't think. > Instead, I think the biggest obstacle is who signs up to maintain and support > such a list, perhaps indefinitely. > > Right. List support represents another difference between ATPS and TPA. TPA can reference a hash-label list maintained by a mailing-list community for example. Of course, it would make more sense for ESPs to populate their own TPA lists based on their own email feedback which thereby tailors it to their specific user base. Regards, Douglas Otis
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org 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)
