On 2/5/14 3:43 PM, "Terry Zink" <[email protected]> wrote:
>Hello, > >We're currently building DMARC support and before we go live, I am >looking for some numbers around known cases of DMARC >quarantining/rejecting legitimate email. Here are cases I can think of: > >1. Case 1 - sender publishes DMARC and only authenticates with SPF, user >auto-forwards their email > >Example: bulk sender -> Hotmail -> Gmail >This would pass DMARC at Hotmail (since bulk sender publishes SPF) but >fail at Gmail (since Gmail will see Hotmail's IP but bulk sender in the >5321.MailFrom) > >According to Google in a blog post - >https://urldefense.proofpoint.com/v1/url?u=http://googleonlinesecurity.blo >gspot.com/2013/12/internet-wide-efforts-to-fight-email.html&k=ZVNjlDMF0FEl >m4dQtryO4A%3D%3D%0A&r=fAk2HhpwqneloqGEFXhAtQ%3D%3D%0A&m=pRSJ4QiEBWv2%2BArW >%2FhQZZWTcTmL7J2ianTBs7FiroIw%3D%0A&s=8cdd07fe693bdd2263ba26b7e1c918fdba1c >ed24fb57fcb7718ce61758fe3f14, around 75% of messages authenticate with >DKIM and SPF. 15% authenticate with SPF only, 2% with DKIM only and about >9% no authentication. > >The only ones that would be a problem in Case 1 is SPF-only, and only >those that publish DMARC records with p=quarantine/none. Does anyone know >how much email this might be? I suspect that this is going to vary a lot from one system to the next, so I don't know that anyone else can give you great advice on it. What I can tell you is that a large scale DMARC system needs a mechanism to automatically detect legitimate forwarding and exempt them from reject and quarantine actions. DMARC has the notion of 'trusted forwarders' defined in the spec and accounted for in the reporting. There are a few different ways to do that, some that border on secret sauce, and are mostly a combination of a reputation or trust system combined with something observable in the header or the traffic patterns. For example, you can look for authentication results headers that were added by the upstream system and choose to use their results if you trust them (aka transitive trust). You can look for other headers that are typically added to forwarded email (X-Original-To, etc) and decide to use them as a signal if you trust the upstream system. If you sign your outbound email, and you have enough volume, you will see some amount of your own signed email forwarded back to your system with the signatures still intact. That's a good signal that the upstream system legitimately forwards stuff. > > >2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC >and there are workarounds, but if no one does anything, the day after we >turn on DMARC how much email would this affect? > >Does anyone have numbers on how much this would affect? Again, this is going to vary from system to system. I would recommend that you have a 'log only' mode for your DMARC implementation so you can roll it out and have it report what action it would have taken to you without actually impacting delivery. This is the other case where you need an automated mechanism to detect legitimate lists based on their behavior and exempt them. From experience, I can tell you that if you exempt email signed by google groups, yahoo groups and it's international flavors, and microsoft live groups, then you will have solved the problem for 90% of users. > > >3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon >threads, DKIM seems to pass anywhere between 10% and 90% of the time. >Seems to be that the higher number is more realistic since if your DKIM >is breaking, you'd want to know about it. This would be especially true >for those who publish DMARC. Those are the two big ones. I haven't really run into other problems. > > >Thanks. > >-- Terry > >_______________________________________________ >dmarc mailing list >[email protected] >https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/li >stinfo/dmarc&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=fAk2HhpwqneloqGEFXhAtQ%3D >%3D%0A&m=pRSJ4QiEBWv2%2BArW%2FhQZZWTcTmL7J2ianTBs7FiroIw%3D%0A&s=7f67d6d41 >adc94b6e45861fa6dbdf4beae357311b2f59043d361ce6e47ca59fb _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
