Ask Laura: Can you help me understand no auth / no entry?

AskLaura_Heading3
Dear Laura,
I’m a little confused by the term “no auth / no entry”. Gmail and other major receivers seem to be moving towards requiring authentication before they’ll even consider delivery.
Does this just mean SPF and DKIM, or does this mean the much more stringent DMARC, as well?
Thanks,
No Shirt, No Shoes, No What Now?


Shirtless & Shoeless,
“No auth / no entry” is one of those adorable little catchphrases that people are starting to use because it makes them sound smart. And when you ask them what it means, they look at you like you’re stupid. Of course we all know what it means. Except when we don’t.
Many people have, wrongly to my mind, interpreted no auth / no entry to mean that ISPs are requiring mail to have a DMARC p=reject record. They’re using this to push people to move to strict DMARC policies. The reality is that no ISP of any size is currently requiring DMARC p=reject for delivery.
Now, ISPs do want to see mail authenticated, either with SPF or DKIM. But even then, unauthenticated mail does get through if it comes from a trusted source and is sent over IPv4.
Mail coming from IPv6 is a different story.  Many ISPs require either SPF or DKIM authentication to receive email over IPv6. Hotmail, Office365 for instance, is outright rejecting unauthenticated email over IPv6. Other ISPs have stated that they expect any email over IPv6 to be authenticated with either SPF or DKIM. This is, to my mind, the true “no auth / no entry.” ISPs are refusing unauthenticated email sent over IPv6. 
At the same time, many of those same ISPs are asking for — but not requiring — SPF or DKIM authentication, for mail sent over IPv4. There are practical reasons for this: many legacy mail servers are still sending legitimate, wanted mail, but that mail is not authenticated. It’s generally accepted by most folks that the upgrade process will be prohibitively resource intensive, and therefore the ISPs aren’t necessarily going to force authentication on IPv4, yet.
I think we are rapidly approaching the point where folks running old, legacy servers are going to have to upgrade and start authenticating email with SPF and DKIM. There’s just too much bad traffic and authentication is too useful a tool. I don’t think that will happen soon, but I do think it will happen within the next year or so.
I think the time when DMARC p=reject is required for delivery is much further down the pike. First off, not every sender, particularly a small sender, can publish DMARC right now. In some cases, it has nothing to do with mail, but more to do with their DNS provider. If a major registrar won’t allow _ (underscore) in DNS records, that means no one using that provider can publish either DKIM or DMARC records. In other cases, the sender might be using a provider that doesn’t allow for alignment. Until these issues are fixed — and they’re mostly outside the control of anyone in the email community — I don’t expect providers to be requiring any DMARC authentication for delivery.
laura


When we work with brands and senders to improve email delivery, there are many questions that come up again and again. For 2016, we thought it might be interesting to answer some of those questions here on the blog so others can benefit from the information.
Confused about delivery in general? Trying to keep up on changing policies and terminology? Need some Email 101 basics? This is the place to ask. We can’t answer specific questions about your server configuration or look at your message structure for the column (please get in touch if you’d like our help with more technical or forensic investigations!), but we’d love to answer your questions about how email works, trends in the industry, or the joys and challenges of cohabiting with felines.
 
Your pal,
Laura

Related Posts

Should you publish DMARC?

secure_email_blogI’ve been hearing a lot lately about DMARC. Being at M3AAWG has increased that. Last night we were at dinner and heard from the next table “And they’re not even publishing DMARC!!!!”
I know DMARC is the future. I know folks are going to have to start publishing DMARC records. I also know that the protocol is the future. I am also not sure that most companies are ready for DMARC.
So lets take a step back and talk about DMARC, what it is and why I’m still a little hesitant to jump on the PUBLISH DMARC NOW!! bandwagon.

Read More

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.
PizzaHutMail
My first thought was “oh, no, Pizza Hut is spamming, wonder who sold them my address.”
Then I remembered that iOS is horrible and won’t show you anything other than the Friendly From and maybe it was some weird phishing scheme.
When I got to my real mail client I checked headers, and sure enough, it wasn’t really from Pizza Hut. I’m guessing actually malware, but I don’t have a forensics machine to click the link and I’m not doing it on anything I can’t wipe (and have isolated from the rest of my network).
The frustrating thing for me is that this is an authenticated email. It not from Pizza Hut, the address belongs to some company in France. Apparently, that company has had their systems cracked and malware sent through them. Fully authenticated malware, pretending to be Pizza Hut, and passing authentication on various devices.
Pizza Hut isn’t currently publishing a DMARC record, but in this case, a DMARC record for Pizza Hut wouldn’t matter. None of the email addresses in the headers point to Pizza Hut.
I spent last week listening to a lot of people discussing DMARC and authentication and protecting people from scams and headers. But those all the protocols in the world won’t protect against this kind of thing. Phishing and malware can’t be fixed by technology alone. Even if every domain on the planet published a p=reject policy, mail like this would still get through.
 
 
 

Read More

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More