I think it's inevitable that some receivers will treat DMARC failures only as spam score, and some will honor the p=reject. There's even reporting conventions for this behavior. As someone pointed out earlier, there's precedent for this in SPF -all.
I think well before AOL and Yahoo published p=reject policies, they foresaw that some mailing lists would simply drop aol.com and yahoo.com addresses from their subscribers, and others would change their forwarding behavior, and considered it acceptable collateral damage. I've watched some Google Groups I subscribe to go through behavior iterations in the last few weeks to accommodate this. I think mailing lists have far more visibility and weight in this forum than in the world at large. I can't see the ISP I work for trusting an external DNSWL of "mailing lists allowed to forward any other domain's mail, overriding their published policies" more than our own secret reputation sauce, so I find it unlikely others will either. So while I think John Levine's "you broke it, you fix it" argument holds water, I don't think that particular solution is likely to happen. J On Fri, May 9, 2014 at 2:02 PM, J. Gomez via dmarc-discuss < [email protected]> wrote: > On Friday, May 09, 2014 2:03 AM, Murray S. Kucherawy wrote: > > > > On Thu, May 8, 2014 at 12:28 PM, J. Gomez <[email protected]> wrote: > > > > > > It seems to me that a particularly defensive receiver would run the > > > > heuristic/whitelist checks on all messages anyway. > > > > > > Why? It seems to me that a particularly defensive receiver would > instantly > > > drop dead incoming email which fails a DMARC check and comes from a > domain > > > with "p=reject;l=no", without subjecting it to any further processing > > > whatsoever. > > > > > > > Because they're local and/or cheap (they don't exactly require an AI or > ML > > engine), and it's best for the final accept/reject/spam-folder decision > to > > be made with as much data as possible. > > But it would be best to have a subset of email abide to "p=reject;l=no" > and therefore allow Receivers to just drop it right away as soon as it > fails a DMARC check. It is not that it would be expensive in **technical > terms** to further process email that fails a DMARC check (when "p=reject" > exists without the proposed "l=no" tag), but that to do it is expensive in > **support costs** for the Receiver ESP -- either if his heuristics fail > when he rejects it (legitimate mailing list email is lost), and also if his > heuristics fail when he accepts it (spam/phising email lands in users' > Inbox). > > > > Perhaps you're assuming that those checks are expensive? I would bet > that > > even for medium-sized operators, they are not; the heuristics amount to a > > relatively small number of header field retrieve and analyze operations > > (string comparisons, hash table lookups, etc.), and the whitelist check > > would be a local database query with a Boolean result. The high cost > would > > occur for operators with very low compute power or network latency such > > that those checks are costly, but that would also disqualify them from > > things like DNSBL queries that are typically done on every message. > > It is expensive in support cost terms, not in technical terms. > > > > For small operators without such resources, they would import or query an > > external whitelist, or the heuristic would amount to something akin to a > > Spamassassin rule that, again, is just some string comparison operations, > > updates to which are periodically updated, possibly automatically. > > > > Do you have some other vision of how this would work? > > Yes, I have the vision, after the stance adopted by YAHOO and AOL on > DMARC's real-world usage (and no doubt many others will follow their lead > soon), that small operators will treat **all** DMARC failures (including > those for p=reject domains) as just scoring input into their > Spamassassin/milter of choice. Either that, or they will stop checking > DMARC altogether for incoming email after their support costs start to > skyrocket because of the eminent and unsolved failure cases of DMARC. > > The problem here is that the real-world usage of DMARC is at odds with how > it was envisioned to be used (cue in YAHOO and AOL). This is a problem > which undermines DMARC's usefulness, and this problem will not go away. The > proposed optional "l=" tag tries to give Senders using DMARC a more > descriptive tool to express to Receivers at large their real situation and > usage of email. > > > > I fact, in my opinion that would be the only way 100% failure-proof to > > > reject incoming email which fails a DMARC check and comes from a domain > > > with a policy of "p=reject". I.e., only the "l=no" tag would allow > > > Receivers to reject incoming email which fails DMARC and comes from > > > "p=reject" domains without potentially incurring in HIGH support costs > (in > > > terms of money, upset users, support personnel man hours, lost > reputation > > > as a reliable email service provider, and a general hellish life, > etc.). > > > YAHOO and AOL starkly show you cannot just reject based on DMARC's > > > "p=reject" alone, as it currently exists. > > > > > > > So what you're really proposing is to split DMARC into two categories of > > domain owners: Those with users, and those that only send transactional > > stuff. Any with users will need to set something other than "l=no", > > basically always. A receiver would treat "l=no" as absolute, and > anything > > else as "check your whitelist/heuristics". Correct? > > Exactly. In my opinion, lacking a "l=no" tag or similar device, **all** > DMARC failures will have to be piped to a "check your whitelist/heuristics" > further processing engine at the Receivers' side, even for domains with a > p=reject policy. YAHOO and AOL show it would be too risky for Receivers to > do otherwise. > > > > Assuming I have that right, and if you accept that the additional checks > > are almost always inexpensive, then the cost savings of "l=no" over > > anything else is negligible > > I don't agree. To be able to have a subset of email which can be rejected > in a surgically clean and straight forward way when it fails a DMARC check > (because it would come from domains with a policy of "p=reject;l=no") would > be great. YAHOO and AOL publishing p=reject has watered down the protection > which previously p=reject was providing to PAYPAL.COM, ING.NL, > LINKEDIN.COM, etc. The proposed optional "l=no" tag would work to up > again the level of protection which p=reject was providing to them. > > > A lot of people want SPF, DKIM, DMARC, etc. to be universal anti-abuse > > silver bullets. They are not, and probably can never be. DMARC has > shown > > itself to be very effective and painless for specific use cases, but not > > universally. > > It's not about searching for a silver bullet. It is about searching for a > way/tool to avoid having DMARC watered down by being used in the real world > at odds with how it was originally envisioned it would be used. > > > > > > > In terms of support costs, any filtering system is expensive when it's > > wrong. > > Therefore, lets give Senders a more descriptive tool to express their > needs and situation and email flows; therefore, the proposed optional "l=" > tag, so that the possibility of "filtering wrong" can be diminished further. > > > > > Regards, > J.Gomez > > > _______________________________________________ > dmarc-discuss mailing list > [email protected] > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > -- "We've learned some important lessons about Democracy. After 100 years, you have to let your slaves go. And after 150, you have to let your women vote." (Kurt Vonnegut)
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
