On Wed, May 7, 2014 at 1:00 PM, J. Gomez <jgo...@seryrich.com> 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. 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? 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? Another issue is that the method of identifying list traffic amounts to secret sauce and can't be standardized. (Or if it can, spammers will just do what the standard says to disguise their mail.) If there's going to be part of DMARC that talks about heuristics, it has to be hand-wavey and punt completely on the idea of figuring out what's list traffic and what is not. It's better not to specify them at all. 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. -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)
