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. 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. For large operators that have tons of data, they can have dedicated processes that look through message histories to find out behavior patterns indicative of lists, and update their own internal whitelists. The query to the whitelist upon message receipt is cheap because it's local; it's the analysis that's expensive, but it's likely not done as part of the message receipt pipeline. 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? 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? 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, except in extreme cases where the cost of the check happens to be high for some reason (extremely low compute power, for example). So, almost always, you may as well do the check. And if that's the case, then what advantage does the additional signal give? Because, as the situations currently is, DMARC's p=reject is no more than a > scoring result to be fed to Spamassassin or whatever milter you use to do > further processing. By YAHOO and AOL publishing p=reject, DMARC failures > even from p=reject domains have become just another data point for the > Receiver's heuristic anti-spam/anti-phising local system. In other words, > DMARC as it now is has become pure heuristics. In my opinion that is bad, > for I feel it is too shaky a ground to tread as a Receiver. > Yes, and that's exactly what Section 6 of the DMARC draft says. You are at liberty to accept DMARC's verdict as absolute, or factor it into a more comprehensive decision system if you think it's too dangerous to do so. 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. > > The remaining case is a receiver for whom such checks aren't cheap. That > > means, to them, "l=yes" is expensive, but the tradeoff is loss of > > list-routed mail from "p=reject" domains and the collateral damage they > > cause. Is that the target audience here? > > Heuristic checks are expensive per se, not technically but because of the > support costs they bring when they fail. Uncertainty in email leads to out > outsourcing email. No doubt that would be good for Google, Office 365 and > other big players; but all the same, very bad for the small ESP all over > the Internet. > In terms of support costs, any filtering system is expensive when it's wrong. The nature of email unfortunately means there are no absolutes. So again, assuming I have the model right, always doing the whitelist/heuristics check reduces your support costs because it detects faulty "fail" results and lets the mail through, reducing user complaints. Isn't that worth the additional compute cycles or network round trips required to do the check? The only remaining question is where you get the whitelist, if you don't generate your own. Cue John Levine. Here's another issue: DMARC, with or without "l=no", could be deployed incorrectly by a Domain Owner such that your users can't receive mail from that operator (say, because they have their DKIM setup wrong), and you'll still get support calls. I don't believe it's possible to harden it against that. We did try mitigating that fact with DKIM by having a "t=y" flag to mean "I'm testing this, I may have botched it, don't treat this any differently if it fails." But that's meaningless, given the fact that we also said "You MUST NOT penalize a message for having a failed signature" because of DKIM's known failure modes. When DKIM was updated, the only reason "t=y" stayed in is because we couldn't prove it wasn't in use (even though it's ultimately pointless). OpenDKIM now actually penalizes "t=y" use; a "pass" with "t=y" is demoted to a "neutral". SPF and DKIM, when they came out, started out as absolute but then became "softer" out of necessity since they have failure modes for legitimate messages. DMARC is not unique in that regard when deployed in certain ways. -MSK
_______________________________________________ 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)
