> -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Vlatko Salaj > Sent: Thursday, April 17, 2014 10:51 AM > To: [email protected] > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote: > > > For the "and" case, yes, that's possible to add if there's enough > > demand to add it. So far the people that have tried this are satisfied > > with the "or" logic. > > making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that's > already possible, either through DKIM replay attack, or through spoofed SPF > authentication, whichever serves an attacker better. >
There isn't much that someone can do with a DKIM replay attack in a DMARC context because the entire body and key headers are signed. For spoofed SPF authentication, the answer is DNSSEC. If DNSSEC is broken/exploited then the community will have larger issues than DMARC. > and if DMARC gets expanded by any additional mechanism, it will just make it > weaker, with OR-dependency. This may or may not be true. It depends on the specific additional mechanism. > > > > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. > > it's not the same. DMARC is not just authentication, it's also about reporting > and conformance. i would be perfectly happy to get my email checked > against SPF and DKIM and processed in a standard-defined way, and receive > reports on which i can then act. otherwise, DMARC has no benefits for me at > all. > Then just publish p=none. You get your email checked and you get your reports. The discussion is about those domain owners that are seeking a higher level of protection. > > >> and it's a common practice, absolutely. whether it's formal or informal. > > What's an example? > > i've already written about it. someone using yahoo or google email service to > send their own domain email. i actually do that. and i imagine, a great deal > of > ppl. > > it also covers various 3rd party services, such as ones that deliver greeting > cards, process petitions... > Don't drag greeting cards into this fight. We've sent billions of greeting card notifications on behalf of our customers in a DMARC conformant way (and as I've pointed out, even before DMARC was a gleam in anyone's eye) without any problems whatsoever. Other greeting card companies have followed our lead in publishing SPF and DKIM signing but I'm not in a position to comment on their specific implementations and configurations. Third party services such as greeting cards are actually a much different use case than mailing lists. > > >> as i said: combined, alignment OFF and AND processing logic would > >> work great in cases where alignment isn't possible, yet email is fully > legitimate. > > For the "off" case, isn't that just the same as "p=none"? > > it isn't. if we accept the idea about making alignment optional, i would > gladly > expand the idea to more than just turning alignment on/off. > > > actually, such alignment field would, in my proposal, include a three-state: > > 1. alignment ON, in which case from: header gets checked against. > > 2. alignment OFF, in which case domain owner specifies they have no benefit > from DMARC alignment checks, but do want other checks performed, such > as AND-logic mechanism evaluation, for example. > If I were evil I could consistently defeat this every day of the weak without much effort. This was the same problem with PRA and the use of Sender. When I first pointed this out to Microsoft (this is not intended to pick on them) back in the 2006 timeframe, they told me it was my implementation that was the problem. When I sent them crafted emails showing that I could consistently get a neutral under PRA checking for ANY From domain (abusing the sender field) they agreed that this was a problem. > 3. alignment domain-list value to include in alignment check: list of domains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such as 3rd party infrastructure, mailing lists that do not wish to make > changes for DMARC-compatibility, forwarders that process their mail, but > can't be controlled by domain owner, etc. it's somewhat similar to SPF > domain definition, but different, since it affects DMARC-alignment process. > This doesn't scale. How many domains would a large mailbox provider have to include in the list to account for all domains subscribed to by their users? How short would the TTL have to be in order to work for newly subscribed to domains? Where would this list live? The DNS folks would freak even if the list weren't too long to be put in a DNS record. > > > That probably means the benefit of adding SRS support wasn't obvious > > to the people responding. This may be obvious to you, but it's > > apparently not obvious to others. > > SRS has benefits. but not for big ESPs, mainly cause of infrastructure > requirements. so, i'm done with advocating for that, cause it won't get > supported by the most influential actors here, that's obvious. > > > >> include sender-id as another DMARC supported check algorithm. > >> yeah, i better not start this topic... we don't want another MARID. > > I totally agree there, especially since Sender-ID got almost no > > adoption (see RFC 6686), and that seems unlikely to change now. > > it would change quite fast if we would make it part of DMARC. > > actually, Sender-ID isn't all that bad at all. it was way ahead of its time. > > PRA could actually be a better way to determine owner's domain for > alignment purposes than some undefined public-suffix list, especially in the > light of newest moves by ICANN, introducing bunch of new top-lvl domains, > which will probably host a bunch of sub-domains with registration capabilities > by 3rd parties, etc. > As I indicated above, PRA had a serious flaw that allowed it to be gamed. Microsoft dropped support for Sender-ID in favor of SPF. Is it worth spending time on something which is basically deprecated/historic? > DMARC's dependance on a concept of "public-suffix list" is a can of worms i > can't wait to see what will make of DMARC's usability at the end. it will be a > mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors, > given all that experience in the domain. > The public-suffix issue is a known one that impacts things other than DMARC. There are proposals on how to address this issue but I have to admit to personally not following them or their progress - only so many cycles in the day. Could you identify any specific instances where public-suffix has been a significant (or non-significant) problem in the wild? > > On Thursday, April 17, 2014 1:42 PM, "Popowycz, Alex" wrote: > > > Perhaps I'm missing something, but eliminating alignment essentially > > nullifies the authentication value for a given domain. > > which, in some cases, has no value at all. as i mentioned up, alignment-OFF > works well only with other options i'm proposing, and only in special cases. > > > -- > Vlatko Salaj aka goodone > http://goodone.tk > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
