On Thursday, May 08, Murray S. Kucherawy wrote: > On Wed, May 7, 2014 at 1:00 PM, J. Gomez <[email protected]> wrote: > > > > 1. The tag value for l=no isn't required. This means "I don't > > > participate in mailing lists and therefore you should enforce my > > > p=reject action." But this is the same as l=dunno (empty) which is > > > the same as today's behavior. So, you would only need l=yes. > > > > Hi, Terry. > > > > The tag "l=" would not be required. Its absence would formally equal > > "l=dunno", which meaning is explicitly undefined. > > > > The absence of "l=" is not equal to "l=no". The presence of "l=no" shows > > to the Receivers at large that the Sender is aware of DMARC's failure case > > with mailing lists, and that he as a Sender is not affected by such a > > problem. > > > > Ideally, PAYPAL, EBAY, BANK OF AMERICA, etc, would publish > > "p=reject;l=no". This makes live easier for Receivers, as email coming from > > them that fails a DMARC check could be directly rejected without applying > > heuristics to it, so no risks of false-negatives at the Receiver's side > > when filtering such an incoming email from PAYPAL, EBAY, BANK OF AMERICA. > > [*] > > > > The absence of the "l=" tag would show to the Receivers at large that the > > Sender is either unaware of DMARC's failure case with mailing lists, or has > > chosen to ignore such a problem, so applying heuristics at the Receiver's > > end on incoming email that fails a DMARC check from a p=reject domain > > without the "l=" tag would probably be appropriate. > > > > So the presence or absence of the "l=" tag always conveys valuable > > information from Sender to Receivers (even if it is "l=dunno"), i.e., the > > Sender is aware/unaware of DMARC's failure case with mailing lists. > > > > > 2. How would a receiver know that the email comes from a mailing > > > list? Would it just look for something like a List-Unsubscribe or > > > List-Subscribe header? Or something similar? > > > > That would be a local heuristic process, or a local whitelist, or a public > > whitelisting service a-la-SpamHaus.Org. That would be exactly what Google > > is doing now when they are not straight-forward rejecting incoming email > > which fails DMARC and is coming from p=reject domains like YAHOO and AOL. > > This problem seems to be already solved for some big ESP like Google and > > others who don't follow p=reject to the letter. It can be a local "secret > > sauce" algorithm, or it can be a public whitelisting service like John > > Levine has suggested. Or it can be both together. Whatever it is, the > > Receivers will choose what and how to use/implement it, just as it is > > happening now. [*, again] > > > > > 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. 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. > There are various > techniques to reduce that cost at scale, to be sure. That means the "DMARC > failed, but the mail is from a list" information is likely already > available to the receivers. (That's certainly the case for Gmail, Yahoo, > etc. today.) Why is the proposed extra signal in the DMARC protocol itself > useful in that case? Wouldn't that already be factored into the acceptance > logic? 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. > For operators that don't run those checks on all messages, why would they > not start? Those checks are cheap, especially if you accept that DNSBL > checks have an acceptable cost and are commonplace now, or local heuristics > are (by definition) local and run quickly anyway. > > 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. > So given how non-deterministic the whole topic is, I believe the text in > Section 6 now is appropriate. It allows for accepting "p=reject" traffic > that fails the DMARC test when the receiver has some kind of knowledge that > an override is the pragmatic decision. How that decision is reached cannot > possibly be standardized given the variance among operators and their > respective environments, and the trivial nature of email fraud. I agree the text in Section 6 is fine. That, however is orthogonal to the merits/demerits of the proposed "l=" tag. In fact, the more the "l=no" tag would be used, the less need there would be to override the results of DMARC checks (specially, when email would fail a DMARC check against domains with a policy of p=reject). 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)
