(Why) Mail.Ru Mail Includes Strict DMARC / Mail.ru Group Blog

The other day we announced the inclusion of a strict DMARC policy on all domains belonging to Mail.Ru Mail. On some domains, including bk.ru and mail.ua, the p = reject policy is already enabled. In this article, we want to clarify some of the technical details of this inclusion and make recommendations to service owners, mail servers, and mailing lists.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a protocol that allows a domain zone administrator to publish a policy for receiving and sending reports for emails without authorization. As authorization protocols, the protocols SPF (RFC 7208) and DKIM (RFC 6376) are used.

How does DMARC work?

Upon receipt of a letter that uses the example.org domain in the sender field (From :), the recipient server requests the DMARC policy of the example domain, which is published in DNS as a TXT record, for example

_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;"


For letters, SPF and DKIM are checked; in addition, the alignment of the domain passed the SPF or DKIM check and the domain used in From: is checked. For a domain to pass DMARC authorization, at least one of the SPF or DKIM mechanisms must be authorized for a domain that matches the organization’s domain from From :. If the letter does not pass authorization or the domain does not match (for example, the DKIM signature of a third-party domain is used or the address in envelope-from does not match the From :) address, the policy is applied (in this case, none, i.e., no special actions are required; reject policies are also possible - do not accept emails and quarantine - add emails to the Spam folder). Statistical reports on policy triggering and past emails will be sent to [email protected]. Also a domain,

What has changed now?

Mail.Ru was the first in Runet to support the DMARC server part more than two years ago. And now DMARC will protect mail.ru domains from forgery. Earlier, a strict DMARC policy was included only for Mail.Ru Group service domains (for example, corp.mail.ru), since they are most often falsified by phishers. Currently, it is also used for the domains mail.ua and bk.ru, and on May 18 it will be distributed to all domains of free mailboxes (list.ru, inbox.ru and mail.ru).

Why is Mail.Ru?

DMARC addresses the most serious email issue - the lack of verification of the sender address. The most common reason for entering DMARC is the fight against phishing emails. This is partly true - the introduction of strict DMARC policy by just a few large US banks in 2014 led to a 6% reduction in phishing via email for the entire industry in a year. In PayPal, the phishing volume for two years after the introduction of the policy decreased by 70%.

In the case of public mail domains, the main reason is not phishing. First of all, we want to reduce the amount of spam on the Web: most of it comes from fake addresses, on some days the number of such messages with fake mail.ru addresses is more than 15 times the number of letters sent by Mail.Ru users . Secondly, DMARC allows you to protect users from secondary spam. Very often, spam emails from fake addresses generate Undeliverable (NDR) messages and auto-replies that go to the mailboxes of legitimate users who did not send the letter. Recognizing this situation can be quite difficult, as there is no “spam” content in NDR and auto answer. In our experience, the implementation of a strict DMARC policy reduces the amount of secondary spam by several dozen times.

Wasn’t all this in SPF (DKIM, Sender-ID, ADSP)?

SPF (RFC 7208) does not protect the sender address at all, since it only works with the envelope-from address, which is invisible to the user. DKIM (RFC 6376) also does not protect the sender address at all, since it is a signature algorithm and does not indicate what to do if there is no signature or it is incorrect. Sender ID (RFC 4406) is covered by Microsoft patents and "did not take off." The closest in functionality to DMARC was the ADSP protocol (RFC 5617), but, unlike DMARC, it also did not “take off” and was transferred to Historic status in 2013, since almost all major market players abandoned it in favor of DMARC. Unlike ADSP, which worked only on top of DKIM, DMARC can use different authentication protocols. The basic standard applies both DKIM and SPF. In fact, DMARC combines the mechanisms involved in Sender ID and ADSP, and makes it possible to expand them in the future, which significantly improves the "indirect" flow of mail (indirect flows). Already now there is no doubt that the DMARC protocol works - the server part of the DMARC is supported by all major mail services, all major players have either already enabled DMARC on their domains, or have announced such an intention. Among the public mail services that have included DMARC on their domains (and have taken the brunt of criticism from the owners of the mailing lists, which will be discussed below) are Yahoo and AOL. On their part, this was a risky, but very necessary decision - otherwise the protocol could comprehend the fate of Sender ID and ADSP. all major players have either enabled DMARC on their domains, or have announced their intention. Among the public mail services that have included DMARC on their domains (and have taken the brunt of criticism from the owners of the mailing lists, which will be discussed below) are Yahoo and AOL. On their part, this was a risky, but very necessary decision - otherwise the protocol could comprehend the fate of Sender ID and ADSP. all major players have either enabled DMARC on their domains, or have announced their intention. Among the public mail services that have included DMARC on their domains (and have taken the brunt of criticism from the owners of the mailing lists, which will be discussed below) are Yahoo and AOL. On their part, this was a risky, but very necessary decision - otherwise the protocol could comprehend the fate of Sender ID and ADSP.

What's the catch?

Naturally, any protocol has flaws. DMARC requires sender authentication, which causes problems in several situations:

1. The user sends letters “directly” bypassing the authentication mail server. For example, the webmaster sends registration letters with a PHP script using the From: address of a public mail. Unfortunately, the only solution is to not do this. Register mail for your domain. Mail.Ru provides a free service for this . Even if you switch to sending from another public mail address, most likely, this solution will be temporary, because DMARC will implement all major mail services for their domains.
2. Mailing lists. Yes, there are again problems with them, and more significant than in the case of SPF, since SPF turned out to be useless precisely because of attempts to maintain compatibility with mailing lists. In order not to violate the DMARC authorization, you must either “not touch” the headers signed by DKIM (in particular, do not change the subject of the letter), or rewrite the sender from From :. Fortunately, the main mailing list managers already support the correct work with DMARC.
3. Forwards. In some cases, mail servers change content during forwarding, for example, the structure of MIME parts or line breaks, which can lead to a violation of the DKIM signature. In such cases, we recommend using POP3 / IMAP (reverse POP / reverse IMAP) mail collection instead of mail forwarding. Mail.Ru is the first of the mail services to implement IMAP mail collection while maintaining the folder structure. In addition, large mail services, including Mail.Ru, support white lists of known forwarders — for mailing lists and other mail services, from which mail is received even in case of DMARC violation. If letters from a well-known forwarder or mailing list are blocked by us under the DMARC policy, please let us know.
4. There are other DMARC issues, including security issues, especially when providing forensic reports. For example, the ability to disclose redirects (and thus deanonymize the user) or mailing list subscribers. All this is possible without DMARC, but DMARC makes the task noticeably easier. Therefore, we implemented the anonymizer function as an alternative to forwarding or one-time / hidden addresses for subscription lists. For security reasons, we do not plan to provide forensic reports with complete recipient identification to untrusted parties.

What should I do if ...

... I am a regular mail user

Nothing to do. Most likely, you will not notice anything, just avoid the situations “someone received spam / phishing from my address, but I did not send it” and you will not receive incomprehensible “shit”.

... I use Mail for Business for my domain.

Only public Mail.Ru domains will be affected. For your domain to be protected by DMARC, you must publish the policy yourself.

... I send letters through the mail server of my Internet provider.

For the addresses served by Mail.Ru, it is necessary to configure sending via mail.ru SMTP servers with authorization according to the instructions .

... I use redirects to collect mail from several accounts on different services in a common box

Most likely, this functionality will work, but to eliminate the possibility that some letters will be lost, use the function of collecting mail from other mailboxes.

... I use redirects to set up hidden / temporary addresses

Redirects can be detected and disclosed (DMARC support for the recipient server is sufficient for this, that is, almost any server). If this is critical for you, use the anonymizer function .

... I use the "send as" functionality on Gmail (or similar) to send letters from Mail.Ru

You should check the settings of the sending address in Gmail and make sure that the sending goes through the SMTP mail.ru server (smtp.mail.ru, port 465 using SSL), with the correct login and password. Letters will be sent through the Mail.Ru server with sender authorization and will pass SPF / DKIM / DMARC checks.

... I use a public mail return address to send letters through scripts on the server

This should not be done. Use Mail for Business to create mailboxes in your own domain (hint: you don’t need to own a business for this, just have a domain). Use your own domain address in all server, automatic or automated mailing lists.

... I provide my clients with ESP

For the From: header, do not use the sender address from free email domains. Register a separate domain for customers who do not have their own domain, configure SPF, DKIM and DMARC for it. Allocate to the client an address in this domain for use as the sender address and register redirects from the allocated address in your domain to the client's email inbox. Customers with their own domain are advised to take addresses from this domain as the sender address. You can continue to use the client address in the free email domain for the Sender: and Reply-To: headers.

... I administer the mailing lists

Update your mailing list software and configure it according to the DMARC compatibility guidelines. Sympa works correctly from version 6.2.6, Dada Mail from version 7.0.2, Mailman from version 2.1.16 (better 2.1.18), GroupServer from version 14.06. You may need to enable a feature called “Sending on behalf of” / “Munge the From: header”. If recommendations cannot be followed (for example, using outdated or unsupported software), try to minimize DMARC violations by refusing to change the service headers and contents of letters sent to the mailing list, i.e. do not change the subject, do not add a header / footer to the letters, so as not to violate the DKIM signature of the letter. If delivery problems persist, contact the server support service, which does not receive messages.

... I am administering a mail domain and want to publish my DMARC policy

Configure SPF and DKIM for all emails sent, while taking into account the specific requirements of new versions of standards. The latest version of the SPF standard (RFC 7208) requires an SPF record not only for the main mail domain, but also for names from the HELO / EHLO command, which, as a rule, coincide with the canonical names of mail servers. This is necessary to pass SPF in the case of an empty sender used in NDR / MDN. Publish a DMARC record with none policy. Configure the addresses for collecting rua / ruf reports. Please note that the DMARC standard requires that the domain in which the address data is located must correspond to the domain for which reports are requested, or publish a special policy for receiving reports, so receiving reports to public mail addresses will also fail. Analyze incoming reports, troubleshoot SPF related issues, DKIM and the misalign of domains from your network, identify possible sources of legal emails outside it (for example, mailings organized through external mailing services) and fine-tune SPF and DKIM for all legal letters. You can use the services of specialized services -Agari , proofpoint , Dmarcian . The Dmarcian service, in addition to paid services, offers a convenient free tool for the visual presentation of DMARC XML reports. When all problems are resolved, switch the policy to reject or quarantine.

... I administer a mail server and want to filter messages by DMARC

Integrate the appropriate filter. DMARC filtering is supported in almost all anti-spam solutions. OpenDMARC and yenma can be recommended as separate free DMARC filters compatible with major Linux / UNIX MTAs .

... I administer the mail server / domain and I don’t know this SPF / DKIM / DMARC and I don’t want to know

As the strict DMARC policy is implemented by other mail domains, your domain that is not protected by the DMARC policy will be increasingly used by spammers as a source of fake sender addresses, which will lead to a constant increase in secondary spam and, as a result, user complaints. Most likely, as a result, you will still be forced to implement SPF / DKIM / DMARC. But even if you remain persistent, someday domains without a published policy may begin to be perceived as suspicious, including self-learning filters, which will lead to problems with email delivery.

... I administer the mail server / domain and I have questions

You can ask them here in the comments or on the Toaster , I try to track thematic hubs.

Finally

E-mail is often positioned by critics as an unchanging dinosaur from the last millennium - but this is not so: it is developing, and is very active. All current versions of the main e-mail standards have been adopted over the past eight years, DMARC has become the standard just a year ago, and work is underway to standardize, for example, the Authenticated Received Chain and SMTP Strict Transport Security protocols. But the transition to new standards and protocols is impossible without the support of all parties, and we very much hope that this article will help you to get involved in the process of building a more modern, convenient and secure e-mail ecosystem.