[This email is part of the series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html] Background: Mail.Ru is an early adopter of DMARC -- implementing the technical specification as part of the pre-public pilot group. As the largest provider of email in Russia, Mail.Ru sees a lot of spoofed email and maintains a strong desire to improve the state of email. From Mail.Ru’s perspective, .COM email is almost all spam… outside of RU, email from .RU is typically spam. DMARC has been very useful in identifying real email to help with this problem. While DMARC is mostly positioned as a protection against phishing, in case of Mail.Ru primary reason to implement DMARC was protection against spam/secondary spam and improve deliverability, because regional domains like .ru are often blacklisted outside of Russia due to high spam/ham values. Fraud is also an issue. To cut down on fraud, Mail.Ru works with business and government organizations to implement DMARC. For example, Russian Federa Tax Service sees a lot of phishing; Mail.Ru worked with them to protect domain from abuse. Vladimir Dubrovin is a Mail.Ru technical advisor and heads up DMARC implementation for last few years. Mail.Ru acts as a resource to push DMARC adoption within Russia. Experience: DMARC used at Mail.Ru for its own domains and also inbound processing/filtering. Filtering: No significant issues aside from typical issues related to dealing with large amounts of traffic. In the beginning, very little impact from adopting DMARC due to little global adoption, now it is widely used. There are exceptions that must be maintained, though. EG, because Mail.Ru has been around for a long time, we see lots of older traffic going through forwarding/lists. Exceptions-lists originally constructed by analyzing log files and based on user’s reports. We inspect message types and apply exceptions where it makes sense. Messages from ESPs with broken DMARC are not accepted for domain with DMARC reject policies due to the nature of the email flows - they do not flow through mailing lists for example. If users report problems regarding mailing lists, we can add exceptions for the problem. This does not happen very often… maybe ½ a year ago something was added. Exceptions added apply to all users. Exceptions are keyed off of DKIM signature and IP. In the future we’ll add support for ARC but it will be treated just like DKIM+IP exceptions… no expected improvements except for very unusual circumstances. It is not unusual to received malformed email that is legitimate. Typically we show users a warning if the email might have been spoofed. Attacks based on malformed email (Misformed of multiple From: headers, eg) are common.. as are emails that are legitimate but sent through a convoluted path. Also homograph attacks from non-existant domains.. we display warnings to users via our web-based interface. We also indicate the failure via Authentication-Results to provide an information for MUA, but we do not know of any email clients that render authentication results outside of web-based interfaces. Exim-based SPF and DKIM implementations: No issues today. Exim has a DKIM bug where multiple signatures from same domain with 1 valid and 1 broken didn’t work. Fixed internally and submitted a patch to exim. A Mail.RU-hosted short DKIM key was discovered and fixed. Even though the DKIM key was unused, criminals could exploit it. In the filtering context, currently not collecting statistics if senders are using weak keys… DKIM adoption happened fairly late in Russia and so existing implementations are almost all 1024 or greater in RU. Haven’t (yet!) seen cases where weak keys are exploited. Balance for us is between possibility of exploit vs working with today’s environment. For SPF, we ignore “+all” policies that abusers like to use, and might add negative weight to such SPF records. Tricky because some records are effectively “+all” but using huge netblocks. For this reason, anti-spam layer improved to process SPF record in addition to SPF results (results are validated by MTA). Filtering for business users is the same for freemail users. Freemail users are protected by mail.ru DMARC policy, but business users’ domains are not automatically given DMARC policy. In business administration panel, a mark is given in the UI to indicate problems with SPF and DKIM, DMARC record constructor is under development. Today in our web interface, warnings of suspicious email are only displayed if DMARC record is in place. In near future, warnings will be displayed even if DMARC record is not in place, starting if messages fails any authentication (e.g. SPF). We’ll end by displaying warnings if email lacks authentication for domains that are present in an email. Sensitive email such as from a banks are given special treatment/display. Reporting: only aggregate reports are sent. Forensic reports are not generated due to conflict with law, which requires recipients to initiate information sharing. In this way our spam-reporting FBL is possible as users hit “this is spam” which is interpreted to mean “share with sender that this email is not wanted”. Exceptions to the law are difficult to obtain and so AFRF reports cannot be sent. Might change in future to send AFRF-style reports to a sub-set of trusted parties if recipients give permission to have AFRF generated. Currently, XML report generation is relatively simple, and despite of the huge number of reports, all reporting is done by a single host. As DMARC popularity increases, we’ll have to grow the infrastructure that produces reports. No immediate need to upgrade this infrastructure. Contact information is in each XML report: email box is monitored and active. Support helps companies with DMARC implementation and handles inquires related to SPF, DKIM, authentication, and DMARC.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
