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.
January 8, 2019 Update: I am reliably informed that the Yahoo China email domains are now up and running and are active again.

From address: Don't use an invalid domain name

Here's a common question that I get asked somewhat regularly: "I don't really want to receive or deal with replies to my email messages. Can't I just use a fake email address?"

You should never, ever use a fake email address (or an email address with a fake domain name) as your from or reply-to address. Why not?

1. There's indirect evidence that some ISPs treat a sender better if they note that subscribers actually respond to your messages. Encourage interactivity. Or at least work with your email platform or email service provider to allow people to unsubscribe by replying. The evidence is soft, but I think it helps at least a little bit to keep you in the inbox.

2. Using a fake domain name or non-existing domain name will definitely cause deliverability issues. Big ISPs are likely to bulk or block your mail if you send from a domain name that doesn't exist. Lots of smaller ISPs are definitely going to block your mail. Brian Krebs recently reported on how a well-known company was recently identified as using a fictional, unregistered domain name to respond to HR queries. If you applied for work there and they never responded to your job application, maybe it is because your ISP probably blocked their response, assuming it was as spam.

Side note to email nerds: Your domain name has to resolve. Trying to use a domain name that doesn't resolve is going to cause unexpected deliverability issues. It'll do more than just keep you from getting replies. Don't work this way! The most common mail server platforms in the world, Postfix and Sendmail, both have switches to turn on that will reject mail from unresolvable domain names. Many, many, many system administrators turn those flags on. Your mail will never get delivered to a site with that check enabled.

3. If you really don't want to deal with replies, I suppose you could use an email address that bounces. I don't recommend this. But if you do it, make sure it's an email address truly under your control, at a domain you control. Don't use a webmail address. Don't use an email address at some internet service provider. You'll get tripped up in authentication and DMARC-related issues.

DMARC lets domain owners specify a policy, published to the world, that can tell other ISPs to filter or reject messages that purport to be from a user at their domain, if the message fails authentication checks. AOL and Yahoo are two big ISPs that have implemented this type of policy. Gmail is going to implement it in 2016. Other ISPs are sure to follow. What should you take away from this? You need to use your own domain name in your from address today. You can't use your AOL, Yahoo, Gmail, or other webmail or ISP email address in your from address any more. Even if DMARC weren't the big issue (and it is), your mail would still be more likely to get bulk foldered.