On Tuesday, April 22, 2014 1:18 AM, Hector Santos <[email protected]> wrote:
> I think the DKIM 3rd party resigner issue is the more important issue > at this point. i hold both are important. SPF's 3rd party support was basically fixed with Sender-ID. but Microsoft never played well that open standards game... if it did, i'm sure we would be having Sender-ID in DMARC now, in place of SPF, and this problem would have been solved instantly. however, since both SPF and DKIM 3rd party alignment support is similar in nature, i'm sure DMARC can be flexibly expanded enough to fix both issues, and any future mechanism it introduces, in the same way. let's face it: all these scenarios are somewhat special in nature, and while quite used and needed, they are not the default setting. so, even if it places scaling problems on DMARC, it's not like everybody will be using them on large scale. "p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=n,s:yahoo.com; aspf=yahoo.com" DMARC entry for example.com domain solution is fool-proof, flexible, trivial and easily maintained. it reads as: 1. request none alignment for example.com domain [DKIM will never align with owner's domain, cause their domain doesn't sign when it uses its own infrastructure, and 3rd party DKIM signatures will never align with it either, cause they are 3rd party] 2. request strict alignment for yahoo.com domain [1st party email fails here, but 3rd party signed email will align] 3. request relaxed alignment for example.com domain [default relaxed setting for owner's domain doesn't need to be specified, and it will align when any email is sent through domain's infrastructure, and fail when it's sent through 3rd party] 4. request relaxed alignment for yahoo.com domain [default relaxed setting doesn't need to be specified, and it will align when any email is sent through 3rd party, fail on 1st] 5. reject anything that doesn't pass these scenarios, and report accordingly 6. 1st party example: sends DKIM-unsigned email - DMARC passes, based on SPF alignment policy 7. 3rd party example: sends DKIM-signed email - DMARC passes, with both DKIM and SPF alignment passing. consideration for abuse: 1. most ESPs verify email address ownership before it can be used in their system, so nobody but ppl owning such addresses would be able to post messages on behalf of a domain publishing some ESPs as 3rd party for their mail subsystem. this is recommended and historical practice already. 2. ESPs need to handle malicious accounts quite well already. so, 3rd party DMARC would not introduce anything that's already not there, or put additional pressure on ESPs. i can't see any exploit holes in this suggestion, at least not one already covered by existing practices. i repeat: all this 3rd party solution usage case is special in its very nature. it would be applied where needed, and not a default DMARC deployment. i really see no reason why DMARC can't be flexible enough to include it. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
