DMARC p=reject

Mail.ru is switching to p=reject.
This means that you should special-case mail.ru wherever …
Actually, no. Time to change that script.
If you operate an ESP or develop mailing list software you should be checking whether the email address that is being used in the From: address of email you’re sending is in a domain that’s publishing p=reject (is a “rejective” email address) automatically. And you should probably do that in real time, whenever you need that piece of information, relying on DNS caching to reduce the network latency.
If you find you’re about to send an email From a rejective email address, you probably shouldn’t send it. Depending on how the recipients’ ISPs handle it, it might be discarded put in the bulk folder or rejected – potentially leading to recipients being unsubscribed.
If you’re writing mailing list software, ideally you should provide your users with several options for handling submissions from rejective email addresses, perhaps some from this list:

• Reject the submitted mail, passing the problem to the owner of the rejective email address and their ISP’s support staff
• Use a From: address in a domain the list operator controls instead, making sure the author’s rejective email address is clearly included (perhaps in the “friendly from” comment)
• Use a From: address in a domain the list operator controls, including the author’s rejective address in the Reply-To: field
• Use ARC, Authenticated Received Chain. It’s not quite ready for use, yet, but it’s a great time to be developing support for it, and testing it at ARC interoperation days

If you’re an ESP with customers who want to send mail from rejective addresses you have fewer options. Sending from a domain you control, with a Reply-To containing the rejective address is one option. Encouraging your users to use an email provider that isn’t rejective – either by moving mail providers or, for companies and organizations rather than originals, buying their own domain and email service – is another.
Whatever you choose to do as an ESP you should make it as clear as possible in your user interface for user with rejective addresses that their using them may cause issues, and what changes you recommend or will take automatically. Being clear that the issue is due to a policy decision by their ISP rather than any ESP policy or technical limitation might reduce your support overhead.
(If you’re in New Orleans for the EEC conference, say “Hi!” to Laura).