On Saturday, June 7, 2014 7:17 PM, Stephen J. Turnbull <[email protected]> wrote:
>> so, what i am proposing is changing adkim and aspf DMARC tags so >> they become: >> a comma-separated list of "alignment-strength:domain" pairs, in which > This probably doesn't solve the mailing list problem, sure, it doesn't scale well to support more than a dozen domains, which isn't a complete solution for mailing lists, but it can be used in special cases when u have mailing lists that can't/won't adapt to DMARC in any other possible or suggested way, and u can't use any other developed workaround. also, this whitelisting solution does fix quite a few other use cases that DMARC without any 3rd party support simply has to exclude. and most of those, if not all, r small scale use cases, majority of worldwide scenarios. actually, any proposed 3rd party alignment upgrade to DMARC would do, imo. what we need to agree upon is which is best overall. my proposal may be quick, trivial, and simple... but Hector's proposal is much more developed and opens wider support, and Douglas' TPA-Label is rly complex but could fix almost anything and everything. and i may be missing some other proposal too. also, there r DKIM-based upgrades to help workaround DMARC deficiencies, however, imo, i would rather skip those, cause: 1. they don't fix SPF 3rd party alignment, 2. won't provide 3rd party alignment support out of box, in case DMARC gets expanded to include another underlying protocol, beside the SPF and DKIM, 3. r quite messy and seem unnatural. >> receivers should have nothing to do with that, no guesswork, in >> respect to DMARC, but they r forced to do it now, going even as far >> to process "p=reject" as "p=quarantine". > Nobody is *forced* to do any such thing. they r "forced" by circumstances of DMARC having too much false-positives with "p=reject". nobody wants unhappy users over lost important email. however, such practice essentially dismantles any strength DMARC has, cause once services start treating reject as anything-but-not-reject, it will become a common practice, and puff... away goes strong phishing protection. and then, it won't take long for phishers to understand what exactly needs to be done to email to look like it should be treated as non-reject by protocols at any receivers using such false-positives precautions. that's where 3rd party support comes in. allowing domain-owner to say: "trust here there like this and that, and don't trust anything else", would dramatically ease upon any workarounds receivers need to perform to keep DMARC false-positives as low as possible. why? cause it will enable domain-owner to specify services it considers more or less, but, trustworthy enough, to deliver its mail. >> yeah, well i don't define trivial and easy like that. and i doubt >> any ESP will introduce something like that. > Once again, you are not paying attention. Franck Martin testifies > that he knows of many ESPs willing to make necessary adjustments, and > who are already doing so. Franck isn't a representative of an ESP. i have full respect for Franck ofc, but until i actually see an ESP publicly committing to such a thing, it's all rumors. and even if an ESP does such a thing, it doesn't mean it will become a new common standard for all of them. and even if it does become a new standard, it still doesn't preclude actual 3rd party alignment support upgrade to DMARC, merely cause 3rd party support covers much more ground. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
