2015: The Year of DMARC?

Based on page views, here's what was most popular on Spam Resource throughout 2015. (I'm sensing a theme...)

1. Ask Al: My email address is being used in spam! Email address forgery is still a big deal, as measured by the number of people finding their way to my blog based on searching for this topic.
2. The kerfuffle around Yahoo's DMARC policy.
3. Followed by how to deal with that DMARC-related kerfuffle, if you run a mailing list.
4. Signing outbound list mail with OpenDKIM. I didn't think much about this one at the time, but it makes sense in the context of DMARC's effectively requiring that mailing list mail must be handled differently. I guess I'm not the only one who was wondering how to sign mailing list mail with DKIM authentication.
5. Google Groups rewriting from addresses to handle DMARC policy. Lots of folks were curious to learn how Google Groups handled headers in this "new world order," after ISPs began to implement p=reject DMARC policies.

Of those top five posts, the only one not directly related to DMARC or DKIM still related to something that DMARC and DKIM work together to help address -- email forgery.

Does that mean 2015 was the year of DMARC? Maybe 2016 will end up being the real year of DMARC as more and more mail providers implement a DMARC policy. But it certainly was on peoples' minds in 2015. With multiple big mail services beginning to publish restrictive DMARC policies in 2014, people started to take notice of both DMARC and DKIM in 2015.

Use the SECOND WEIRD TRICK when implementing your DMARC record

SendGrid's Kirill Popov left a most helpful and timely comment on my previous DMARC record-related post.

He writes: "Even if you're *reasonably* sure that you have done all the diligence above and do not expect a lot of rejects, make sure your RUF and RUA addresses are able to handle large amounts of traffic. You never know whether a receiver out there has a screwy implementation, or some phisher will launch an attack. Consider hosting these addresses with a third party - try not to DDOS your own corporate email."

In the DMARC record specification, there are fields called RUF and RUA. The are fields where you specify an address to receive emailed reports relating to DMARC issues. (The fields allow you to specify a "forensic" notification address and "aggregate" reporting address, respectively.)

What Kirill is saying, and rightly so, is don't configure these notification addresses to be mailboxes at your tiny little Exchange server that can't handle any sort of significant email load. If you send any significant volume (maybe even if not), you'll accidentally be telling the world to crush your own mail server with reports. If you've got a unix geek and you're in the right environment for it, set up a separate server just to receive an house these reports. You could probably whip something together with Postfix and Perl or shell. Don't make these addresses mailboxes on your regular, existing mail server, unless you really know what you're doing.

Or better yet, partner with somebody like Agari or Return Path. With Return Path's Email Fraud Protection service, for example, they'll help you configure your DMARC record, and that includes setting things up so that notifications and reports are sent to Return Path for processing and rolling up into a dashboard for you to review. No need to roll your own, no need to learn how to parse this raw data yourself.

What RRVS Doesn't Fix

RRVS (the Require-Recipient-Valid-Since Header Field) as documented in RFC 7293 seems like a neat idea. It was designed by Yahoo and Facebook folks with the best of intentions.

But as an identify theft prevention measure, I am worried that it really falls short. Here's the example that I just can't get past: Let's assume Yahoo has implemented RRVS for yahoo.com users. Great. But what about for addresses at the typo domain variant of yahoo.com I just registered a few weeks ago?

There was a great presentation on malicious domain registration/re-registration at an industry conference I was at recently. It highlighted how bad guys can watch for and purchase recently expired domains and are then practically given the "keys to the kingdom" when it comes to whatever that domain might have hosted or managed previously, whether it be email users or command and control for a botnet army.

At the end of the presentation, I had the opportunity to thank the guy and ask him and the crowd, think about what people can do with emailed password reset credentials in this scenario. I pointed out that I recently registered a specific typo domain (and there are millions more where that came from, both domains and actors) and when I started accepting mail for this typo domain, I immediately started receiving peoples' personal info, links to reset passwords, information on where people tried to set up accounts using email addresses at this domain, etc. Pretty scary stuff, and lots of opportunity for me to do bad things, if I was a bad guy. Very easy for me to identify and login to accounts of almost any type. I don't even have to go hunting; suggestions just keep landing in my inbox.

Thankfully, I'm not a bad guy. I'm not trying to login to any sites with any of these credentials or links. But what about the bad guys? They're not similarly restrained.

How do we stop the bad guys from exploiting this? How do we help senders of all stripes stop sending mail to domains after the domain has been repurposed? Maybe we start tracking age of domain, maybe tracking a centralized hash of ownership info, before sending a password reset notification, maybe something like this might help. If the domain is newer than the account with an email address at that domain, raise a red flag because something must be funny.

This is what RRVS tries to do, but it does it on a per-user level only, and only at a handful of recipient domains that have chosen to implement it. Thus, this secures maybe one or two doors in a way where it would be putting the lock on the wrong side for the others. All the others, the vast majority of domain names and mail providers.  "But we already have RRVS" was basically the response I heard when I brought this up. Well, yeah, but RRVS isn't stopping this at all.

Mail forwarding in a DMARC world

Auto-forwarding mail today is kind of a pain in the butt. If a domain has a p=reject DMARC policy, mail from somebody at that domain likely gets blocked if you try to forward it on to, say, a Gmail account. Even if a domain doesn't have a p=reject DMARC policy, your "forwarding hop" fails SPF authentication. And your forwarding IP address is likely to get deferred or blocked at some point. No fun at all.

Eventually the Authentication Received Chain specification will gel into a real implementation of something that preserves authentication results when forwarding, and that's supposed to help. But it doesn't exist today and you want to be able to forward mail as painlessly as possible. What should you do? Well, you could try doing what I do.

Here's a version of the script that I use to forward mail for my friend Dean. I use Maildir on Postfix, so when mail to dean@his-domain comes into my system, it is stored in Dean's Maildir folder, one file per message. (This is much easier for processing via script that an mbox mailbox.) Then my script checks that folder every few minutes. If a message is waiting, my script picks it up and processes it. It strips out the original sender info and DKIM signature (if found), though it leaves that information in hidden X-headers so you can troubleshoot it as needed. It adds new sender information making the mail now from an address I specify (thus I can control any authentication issues) and it moves the original from address to the reply-to header, so my friend can still reply to the message and have the reply go to the original sender.

It's not perfect; its biggest limitation is that it effectively blows away the original reply-to header, and if my friend reports messages as spam, it still probably negatively impacts my own sending reputation. I attempt to mitigate that by putting my own spam filtering in front of the forwarding, trying not to send on messages my filters believe to be very spammy.

But, it works, and it works pretty well. I've used some version of this type of forwarding for quite a while now, even before p=reject DMARC policies started to descend upon us.

French ISP Orange shutting down voila.fr mail domain

The French ISP Orange is shutting down email service on the domain voila.fr. Service is expected to end on January 15, 2016. At some point after this date, expect any email to voila.fr addresses to be rejected.

The online shutdown FAQ explains (in French) that users have another email address already, and it tells them how to lookup that username and password. It also makes it clear that users will not be able to access their voila.fr mailbox or any previously received messages after the service is shutdown.

Senders might want to take advantage of the window before the service is fully retired to email those users and request that they provide you with an updated subscriber email address.

Update: An anonymous friend offers the following clarification:

The FAQ states that a redirect (forward) can be set up to another address (and provides details on how to do that) and that the forwarding will be active for the next 6 month after the service shutdown (around June 15th 2016). 

Of course, a majority of users won't bother to enable forwarding, but I would still advise against blocking mail to voila.fr altogether immediately from January 15th onward. There will still be active users due to this forwarding functionality, and actually I think that those who bother to do it are the most likely to be engaged or using a voila.fr address as as a primary address (or an important one at least). 

Just make sure to process bounces efficiently, and if a voila.fr address doesn't bounce after the shutdown date, you know that the user is active on this channel and interested in keeping in contact, and you have 6 months to ask him to opt in with his/her new address.

Thanks, anonymous friend!

Congrats to Return Path!

Chairman and CEO Matt Blumberg just announced that Return Path is now sixteen years old! Congrats to everyone over at Return Path. That's a long time in the email game. Lots of other companies have come and gone in the email and reputation space since then and Return Path's longevity is a sign that they're doing something right.

(What else happened sixteen years ago? Back in May, 1999 I announced my anti-spam blacklist RRSS. Ah, those were the days.)

Spam filtering technology, email marketing best practices, and overall email technology sure has changed a lot in the last sixteen years! And there's no sign that things are slowing down, what with broader adoption of DMARC and the newly-announced ARC specification both going to make for an interesting 2016.

Admin: Site Redesign Time

This site, Spam Resource, has been around in one form or another since late 2001.

From 2001 I was hosting it on my own server, publishing in a rudimentary "weblog" format, all with hand-coded HTML files. (Remember when CAN-SPAM was new?)

In late 2004, I converted the site to an online software store. At the time, I was working for an e-commerce service provider, managing email compliance/anti-spam efforts there, but I was curious about how other types of online marketing worked. (That employer ended up having a contest to see who could drive the most software sales; I won an award as having one of the highest ranking stores. And I learned quite a bit about how affiliate marketing and third party revenue sharing worked, without ever having resorted to sending spam.)

I moved the site back to being a blog in 2006, setting things up on Google's Blogger platform in August, 2006, just as I was moving to Chicago. Back then Blogger was still somewhat rudimentary, but it was one of the few options for "in the cloud" blog hosting, versus having to install and manage your own server -- something I had done in the past but was trying to get away from.

Later, I lovingly hand-crafted XML and HTML into a custom Blogger template, something I was overly proud of at the time. Fast forward to 2015, and I am frustrated that I can't easily change fonts or anything else in my layout, without a text editor, a calculator and a reference manual. Thus, it is redesign time.

I hope you don't find the new layout and design too annoying. I'm mostly just happy that it's now one of the standard Blogger templates, so I can use their user interface to modify fonts, colors, graphics and other settings. Who's got time to modify code by hand any more? I surely don't.

I've also renamed DNSBL Resource to Blacklist Resource, which I think makes it a bit less confusing to non-technical folks. (And don't forget that XNND is still out there, ready to help you with your DNS lookup needs.)

Thanks for reading!

Yahoo! Mail China is no more

I've had a few folks ask recently: "Are the domains yahoo.com.cn and yahoo.cn truly retired?" After all, XNND Domain Intelligence shows them as valid for accepting mail, meaning they have proper MX records configured and there seems to be servers configured to accept their mail.

Confirmed: The domains yahoo.com.cn and yahoo.cn no longer accept mail.

Details:

1. It was announced way back in August 2013 that Yahoo! Mail China would be shut down at the end of 2014.
2. Today in 2015, any attempt to email any address at yahoo.com.cn or yahoo.cn results in bounce back (NDN) saying "550 relaying denied for <(yahoo email address)>." This happens whether or not the address was previously known to be valid. The door to this domain is truly closed for all.
3. All you can do at this point is remove those addresses from any lists you might manage. You've missed your chance to ask those users (via email to their Yahoo! Mail China addresses) to provide you with an updated email address. If possible, consider contacting those subscribers through some other means and request that they provide you with an updated email address.