On Wednesday, May 07, 2014 2:30 AM [GMT+1=CET], Terry Zink wrote: > > What do you think about this proposal to extend DMARC to > > account for the failure case of DMARC with mailing lists: > > http://www.ietf.org/mail-archive/web/dmarc/current/ > > msg00167.html > > I remember this thread from a year ago and that it didn't get a lot > of support. I suppose an example record is the following: > > _dmarc.example.com "v=DMARC1; p=reject; pct=100; rua=...; ruf=...; > l=yes" > > The idea is for mailing lists to avoid getting filtered by DMARC > (since it does spoof the From but legitimately) but it needs to be > thought out end-to-end. I have a couple of questions: > > 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] > 3. Would the expected behavior be that if the email comes from a > mailing list yet fails DMARC, do not enforce DMARC's p=reject action > nor the p=quarantine action? The expected behavior would be that incoming email which fails DMARC coming from p=reject domains with the "l=yes" tag, should be subjected to further processing on the Receiver's side and not be rejected straight away. Ideally, the "l=yes" tag would not be needed. YAHOO and AOL show that, in the real world, it could be a handy tool for when DMARC is used beyond how it was designed to be used (as YAHOO and AOL are currently doing, and probably more ESP's will be coming along with them in such a practice). The "l=yes" tag together with "p=reject" would show from Senders to Receivers at large that such a Sender is aware of DMARC failure cases with mailing lists, and that such a Sender has users who do use mailing lists, and that he also has such a VERY BIG PROBLEM with spoofing that he has had to reach for the "atomic bomb" of p=reject just to be able to keep afloat. Therefore, Receivers then are recommended to act sensibly and to not reject straight away but apply mailing list detecting heuristics. > 4. What about a large domain prone to spoofing? Yahoo publishes a > p=reject, and plenty of its users use mailing lists. What is stopping > a spammer from putting the same mailing list tags into the message > and spoofing From: Yahoo? That seems like a very easy workaround for > the spammer. A counter argument is to not blindly trust what appears > to be a mailing list but also apply some other heuristic to it (e.g., > domain or IP reputation). But if you're going to apply IP or domain > reputation to suppress the DMARC action, then you don't need to pay > attention to the l=yes tag at all. Well, the presence of "l=no" would save all Receivers the need to apply any mailing list detection heuristics at all on email coming from a domain with p=reject that fails DMARC. Receiver's win, methinks: no risk of false-negative results in the heuristics processing of such incoming emails, and less system overhead for the Receivers. [*, once more] YAHOO and AOL could choose to either publish "l=yes", or not to publish "l=" at all. I don't think they would have the guts to publish "l=no" together with their current "p=reject", because they KNOW about the failure case of DMARC with mailing list (but they currently have no way to express their particular situation with the current semantics of DMARC). > That is, if condition X can let you know whether or not to do > p=reject, then there's no reason to do condition X and condition Y, > making condition Y redundant. Right? I fail to read clever code unless it's well commented. I'm not sure what are condition X and condition Y in your generalization, and I fear I would guess wrong if I tried. So I don't try, just to not add noise here. [*] The case of YAHOO and AOL publishing p=reject shows plainly that even when the Sender publishes p=reject, the Receivers who choose to do DMARC **will have to** apply heuristics to incoming email from p=reject domains that happens to fail a DMARC check. 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)
