On Friday, May 09, 2014 2:03 AM, Murray S. Kucherawy wrote:
> On Thu, May 8, 2014 at 12:28 PM, J. Gomez <jgo...@seryrich.com> 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 dmarc-discuss@dmarc.org 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)
