On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote:
> This would be a simple first step consideration -- A new ATPS tag this may fix DKIM 3rd party support, but does little to support 3rd party SPF. i think it's important to have a fix for all underlying mechanisms, not just some of them. considering DMARC may include additional underlying mechanism in the future, a fix for 3rd party needs to be DMARC-based, not based on whatever underlying mechanisms are included in DMARC instead, imo. if we start fixing underlying mechanisms just to have them DMARC-imposed alignment requirement compatible, we are introducing new griefs to be dealt with in the future, and adding bunch of incompatibilities with legacy support for those protocols. so, whoever supports DMARC will have to add support for all those new extensions and additional protocols which may be more than what they are willing to do, opting for just ignoring DMARC completely. also, such path simply creates more resource usage, especially on DNS, cause all those extensions have their DNS checks, and sometimes more than one. also, more protocols, more libraries running on server, fighting for resources... why should we go that line, when it's easier to build a DMARC-based support for 3rd party and fix the problem at the source? > atps=0 default, extension disabled allowed backward compatibility. > atps=1 Valid alignment allows a valid 3rd party signature (no checks). this is similar to specifying adkim=n, the way Tomki Camp already suggested, which i like better instead, since it's DMARC-based. > atps=2 Valid alignment allows a valid 3rd party signature with ATPS > (Authorized 3rd Party Signer) checking, RFC6541. a receiver wishing to support ATPS can account for it during processing DMARC, without any change in DMARC itself. however, i'm quite sure everybody would be much more happy with a single working protocol, instead of bunch of extensions. > atps=3 Valid alignment allows a valid 3rd party signature using > the May-Resign header method. which is what exactly? i guess something similar to adkim=s:yahoo.com, which i proposed already, but if u would like to continue lobbying for this idea, please elaborate and provide examples. in any case, i would like to see what benefits these solutions have over other suggested proposals, like those suggested by Joseph Humphreys, Tomski Camp and me, all of which tend to fix DMARC, and not introduce requirements for additional extensions to underlying protocols. i can see many cons with ATPS-path while comparing the two principally different ideas. DMARC was created as a solution for a problem a bunch of other extensions tried covering before already. all about failing. we could skip that broken-path with DMARC today, since it's still in development, and simply add 3rd party support to its base. i see no issue with the idea of authorised alignment. it's natural to the way email works. with some thinking, i'm sure we can make it work for mailing lists too. this is how i read J. Trent Adams' last post. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
