DMARC and report size limits

I just saw an interesting observation on the dmarc-discuss mailing list. Apparently some of the larger providers who are implementing DMARC for inbound email may not be handling some of the grubbier corners of the spec perfectly. That’s not surprising at all – early adopters tend to deploy code that implements early versions of the draft specification – but I can see this particular issue tripping up people who are beginning to deploy DMARC for their outbound mail.
DMARC includes the feature of requesting feedback reports about authentication failures – you just include the email address you want them sent to as a mailto: URI in the rua= and ruf= fields:

ruf=mailto:dmarc-feedback@example.com

Pretty simple. But DMARC extends the usual URI syntax to add an (optional) size limit, by adding an exclamation mark and a size limit at the end:

ruf=mailto:dmarc-feedback@example.com!10m

I’m not sure exactly what would happen if a standard URI parser were used for that field, instead of a DMARC-specific parser, but it might error out (“!” isn’t a valid unescaped character in a mailto: URI) or it might try and send mail to the domain “example.com!10m”. It’s easy to imagine how it might fail.
So if you’re beginning to deploy DMARC and you’re not seeing feedback reports you’re expecting you might want to avoid the size limit extension.
 

Related Posts

ReturnPath on DMARC+Yahoo

Over at ReturnPath Christine has an excellent non-technical summary of the DMARC+Yahoo situation, along with some solid recommendations for what actions you might take to avoid the operational problems it can cause.

Read More

June 2014: The month in email

Each month, we like to focus on a core email feature or function and present an overview for people looking to learn more. This month, we addressed authentication with SPF.
We also talked about feedback mechanisms, and the importance for senders to participate in FBL processes.
In our ongoing discussions about spam filters, we took a look at the state of our own inboxes and lamented the challenge spam we get from Spamarrest. We also pointed out a post from Cloudmark where they reiterate much of what we’ve been saying about filters: there’s no secret sauce, just a continuing series of efforts to make sure recipients get only the mail they want and expect to receive. We also looked at a grey area in the realm of wanted and expected mail: role accounts (such as “marketing@companyname.com”) and how ESPs handle them.
As always, getting into the Gmail inbox is a big priority for our clients and other senders. We talked a bit about this here, and a bit more about the ever-changing world of filters here.
On the subject of list management, we wrote about the state of affiliate mailers and the heightened delivery challenges they face getting in the inbox. We got our usual quota of spam, and a call from a marketer who had purchased our names on a list. You can imagine how effective that was for them.
And in a not-at-all-surprising development, spammers have started to employ DMARC workarounds. We highlighted some of the Yahoo-specific issues in a post that raises more questions.
We also saw some things we quite liked in June. In the Best Practices Hall of Fame, we gave props to this privacy policy change notification and to our bank’s ATM receipts.
We also reviewed some interesting new and updated technology in the commercial MTA space, and were happy to share those findings.

Read More

AOL publishes a p=reject DMARC record

Yesterday I mentioned that there were reports of a compromise at AOL. While the details are hazy, what has been reported is that people’s address books were stolen. The reports suggest lots of people are getting mail from AOL addresses that they have received mail from in the past, but that mail is coming from non AOL servers. In an apparent effort to address this, AOL announced today they have published a p=reject DMARC record.
I expect this also means that AOL is now checking and listening to DMARC records on the inbound. During the discussions of who was checking DMARC during the Yahoo discussion, AOL was not one of the ISPs respecting DMARC policy statements. I’m not surprised. As more information started coming out about this compromise, I figured that the folks attacking Yahoo had moved on to AOL and that AOL’s response would be similar to Yahoo’s.
My prediction is that the attackers will be trying to get into Outlook.com and Gmail, and when they do, those ISPs will follow suit in publishing p=reject messages. For those of you wondering what DMARC is about, you can check out my DMARC primer.

Read More