On Sunday, June 8, 2014 4:03 PM, Hector Santos <hsan...@isdg.net> wrote:
> Can we use a different tag for your proposal? Hector, i'll give u one thing for sure: u do like to make ur replies as detailed as possible. i do respect that actually, cause it shows that u give a damn, and that u r a perfectionist, both traits that r actually somewhat of a requirement in development of things such a standards. but u may, especially if u r pressed with time, make it as shirt as much u like, and hope my brain is developed enough to fill all the blanks on its own. and i'll do my best to surprise u. that said, i understand all the technical burden of possible incompatibility, which u were kind enough to cover in ur reply. but i hope DMARC implementers followed DMARCv1 specs and r making version checks before they actually process aspf and adkim tags, the way spec requires them to. i do not want to lower my ambitions cause of fear of bad DMARC implementation out there. bugs r to be addressed by their developers. so, the question, imo, is what is better: 1. to be as much compatible as possible with v1, essentially making as little disruption as possible, but risking to be ignored on long run, and 2. to be blunt and request a version replacement, hoping for overall approval, thus moving v1 to legacy. imo, changing the way alignment works, ESSENTIALLY changes the basic logic, based on a SINGLE domain virtue. by extending it to cover whatever domain-owner wants covering, alignment now becomes a TRUST logic, and, imo, that is a sufficient reason to actually go bluntly forward and make space for DMARCv2, possibly as a 1st step for any future IETF WG to base its work on. yeah, i know this is ambitious. and may as well be ignored as SPF2 was. but i hope we learned from past mistakes, and instead i choose to be positivist about it and hope ppl will find DMARCv2 an upgrade in right direction. beside those clearly political motives, imo, there r technical ones: 1. adding "none" to alignment logic requires changes in aspf/adkim tags, and i think "none" is valued enough to warrant it for domain-owner too, not just 3rd party, 2. there's a need to treat ASL domains separately for SPF and DKIM, cause some domains may need something like "aspf=n:urdomain.com adkim=s:urdomain.com", 3. adding new tags is less optimized than using old tags, essentially cause it uses more characters, in a limited DNS record space. all that being said, we can do both: 1. make a DMARC version 1.1, which would use aspfx and adkimx, and won't introduce "none" for domain-owner; merely to have a test online, and to see if there's something we miss in the concept space, but also as a fallback if v2 is completely dismissed by community, 2. make a DMARC version 2 draft, which would go my original proposal for aspf and adkim, and which we would advertise as a more optimized, stable solution, working towards inclusion of a more complex and scalable 3rd party support [i'm considering TPA-Label], in addition to ASL, thus adding more weight to the proposed version upgrade. be free to reply as detailed as u like. i'm happy we r moving on this, anyhow. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
