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.

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.

Using AdBlock? Using Yahoo! Mail?

Not for long, you're not. Looks like Yahoo is testing code on Yahoo! Mail that would disallow AdBlock users from accessing their webmail platform. Read more over at the Consumerist.

Verizon Retiring Inactive Email Addresses

Oracle Marketing Cloud's Kevin Senne reports that Verizon is telling subscribers that verizon.net email addresses unaccessed for 180 days will be deleted. This is yet another reminder that you (senders) can't sit on email addresses for years and still expect them to be valid. I have no clue if Verizon ever repurposes dead email addresses into spamtraps, but it's not something I would want to risk.

Gmail to flag unencrypted email connections

In November, Google indicated that they're working on a warning indicator to be shown inside of Gmail, indicating when an email message was transmitted over an unencrypted connection.

What does it mean when an email message was sent without using an encrypted connection? It means that your MTA (mail transfer agent-- aka a server sending email messages) wasn't using TLS (Transport Layer Security) when communicating over SMTP (Simple Mail Transport Protocol).

It doesn't mean your message was intercepted by bad guys. And mail servers had been communicating with each other in an un-encrypted fashion for many years. But in this modern age, where individuals (and even big companies) have begun to raise concerns over who has access to an individual's online information, Gmail is taking a stand to say, we want everybody to encrypt email delivery connections so prevent (or at least reduce the chances of) those messages from being intercepted or copied in transit.

If you work for an email service provider or email platform, you know that any time a major ISP or webmail platform puts up an alert over a certain type of message or scenario, your customers are going to be concerned. Even if this notice doesn't really indicate a failure condition, they're going to be worried that it does suggest that to their end subscribers. In short, they won't want this alert to show up for emails they send.

It's quite a savvy move on Google's part. I am sure that email platforms and email service providers that don't already universally support TLS are figuring out how quickly they can implement it.

Does TLS improve email deliverability? No, not directly. But, consider this: if mail delivered without using TLS is going to throw up a big red flag in the Gmail user interface, that's going to cause an issue with subscriber confidence. Calls to customer services. Incorrect assumptions that a message isn't safe or might be fraudulent. These are not concerns you want associated with your email marketing program.

A Useful Email Validation Tool

Hey, if you're looking to test whether or not an email address is syntactically valid, I think I've stumbled across just the tool for that. Check out the very cool isemail.info by Dominic Sayers.

This doesn't connect to a remote server nor does it try to determine if the email address is actually deliverable. It tells you if there are too many dots in the wrong places or otherwise contains something that isn't allowed in an email address.

If an address fails the validation process, it tells you exactly why that address failed; what is in it that is disallowed, and why is that disallowed. Very, very kind of Dominic to have taken and distilled the RFCs down to something you can actively test against.

(Of course there are some email addresses that violate RFC specs but are still deliverable and otherwise "valid." But that's a problem for a different day.)

Use this ONE WEIRD TRICK when implementing a DMARC record

The one thing, the absolute most important thing to keep in mind when setting up a DMARC p=reject policy is: You have to know all of the sources of all legitimate, desired mail that uses your domain name, before you proceed. If you don't, here's what happens: You turn on p=reject, and suddenly offer letters to new employee candidates start bouncing. Why? Because you didn't know that your human resources department uses a third-party service provider to handle applications and offers. It sends its own email, from its own server, and it's either that the mail is not being authenticated with DKIM, or that it's sending IP addresses are not included in your SPF record.

I've seen it happen more than once.

What other things are important considerations when planning to move forward with a p=reject DMARC policy? Share in comments and I'll wrap them into a future post.

Is my DKIM key Insecure?

Various folks have been asking lately if their DKIM key might be "insecure." At least one ISP out there is failing working keys with "verification failed; insecure key" as the error. A number of small, second or third tier ISPs note that the DKIM validation passed, but with a warning: "1024-bit key; insecure key."

After talking to folks and doing a bit of investigation, I think that ISP should not be failing the the DKIM signature in question. The key passes perfectly fine elsewhere, and my suspicion is that the ISP in question is running an out of date version of OpenDKIM. I myself have had issues with "insecure" warnings from OpenDKIM -- when that happens, what it's actually complaining is that the sending entity hasn't implemented DNSSEC. As I mentioned in my prior post, yeah, DNSSEC is a good thing and something to look at, but I would posit that it's really not appropriate to level an error (or a big scary warning) in email header over this, because a great number of perfectly fine entities have yet to implement it.

Indeed, the specification governing DKIM signatures (RFC 6376) mentions DNSSEC in passing but does not list it as a requirement.

TL;DR? "Insecure key" just means a sender is not running DNSSEC; it's not common or appropriate to fail a DKIM signature for this reason.

Update: A friend asks, what if the "verification failed" and "insecure key" messages are unrelated? This quite possibly could be the case. Data's a bit thin, but if so, it would still suggest to me that the ISP in question is potentially using a broken or out of date install of OpenDKIM. I am noting that it is likely OpenDKIM due to the "insecure" message and I am suggesting "broken or out of date" due to failing a DKIM key that is working when tested elsewhere. I'll provide an update if/when I learn more about this issue.

DMARC: Gmail "p=reject" policy is coming

First Yahoo. Then AOL. Recently, additional Yahoo domains. Next up? Gmail. DMARC.org announced today that Gmail will move to publish a more restrictive DMARC policy in 2016. Read more over on Word to the Wise. (H/T WTTW)

Add Other Email Accounts to Yahoo Mail

Want to access your AOL or Outlook.com mail via Yahoo! Mail? Yahoo's got you covered.

The deliverability consultant in me wonders exactly how this is accomplished. It might be that only the inbox folders come across and you probably don't get a chance to see anything in your AOL or Outlook.com spam folder. I find a fair number of false positives in my Gmail spam folder; but that doesn't mean that the same would be true of AOL or Outlook, or even of the Gmail spam folder for other regular joe users, who aren't email nerds like we are.

Additional Yahoo Domains to get DMARC "Reject" Policy

You may recall that Yahoo implemented a "p=reject" DMARC policy in April, 2014 for their primary yahoo.com domain name. (And AOL did the same for aol.com shortly after.) This changed the email landscape significantly. Among other things, email forwarding, discussion groups, and spam were all impacted, for better or for worse.

Today, Yahoo announced on the DMARC-Discuss mailing list that they will be similarly implementing a "p=reject" DMARC policy for their ymail.com and rocketmail.com domains on November 2, 2015.

The domains ymail.com and rocketmail.com are alternate domains that Yahoo! Mail users can use when creating an account, thus, they are pretty much equal to yahoo.com when you consider what people use them for or what kinds of traffic you would typically see them used for.

A Yahoo representative also explained that "[in] the coming quarters you can expect Yahoo to publish similar policies for other Yahoo owned and operated domains, including international Yahoo domains (e.g. yahoo.ca), Yahoo Groups, Flickr and Tumblr."

If you run mailing lists or email forwarding, and you've already updated your software to appropriately handle domains with a DMARC "p=reject" policy, you probably don't have to do anything new here, assuming you didn't just hard code your software to special case aol.com and yahoo.com.

⛄ Put a snowman in your subject line ⛄

I'm not going to lie; I think it's a bit silly. But, I get asked about this pretty darn regularly: How can I put symbols in my subject line? Well, it's kind of easy. First, you have to know what symbol you want to use, then you just need to know what the right bit of code is to represent that symbol, and how to paste it into your favorite ESP's editor as the right bit of code.

Thanks to Steve Atkins of Word to the Wise, it's now very easy to answer the "which bit of code" question. Just click on over to the Encoding tool on wiseTools, and type in the name of the character you want to use. You can even type in a partial name and get a list of matches. (Try typing in "star" for example.) After you select a symbol (glyph), you're taken to a page with details of how to copy and paste, or type, the desired symbol in different ways for different uses cases. Copy and paste your bit of code into your email tool, and away you go!

It's pretty easy, and kind of fun to play with, too!

Need DNS Tools?

I've revised the XNND.com simple DNS tools site a bit; I hope you'll find it useful.

If you're looking for more tools, I'd suggest checking out the wiseTools site from Word to the Wise, the email consultancy service run by Laura and Steve Atkins (also home of the Abacus abuse desk ticketing system). WTTW even has a Labs site with bits of code you can download, if you'd like to get your hands a bit dirty.

Google now allows you to "block" senders in Gmail

Over on the Official Gmail Blog, Google's Sri Harsha Somanchi lets us know that Gmail now offers the ability to "block" unwanted senders. Sri explains that after you block someone, any further mail from them will go to the spam folder. He also explains that the new "block" functionality and the current "unsubscribe" functionality are coming to the Gmail application on Android.

If you're wondering how to later unblock a sender, Google has published a new Gmail Help page explaining this and more.

(For more detail, Chad White from Litmus has blogged about this in more detail here.)

Now Hiring: Deliverability Strategy Consultant Opening

Looking for a new job? Oracle Marketing Cloud (Reponsys/Eloqua) is seeking an experienced deliverability person to join their Deliverability Strategy team. The preferred location is Broomfield, Colorado, but they will consider other Oracle locations or remote.

If you’re interested and would like more information, send an email to Daniel.deneweth@oracle.com. To see the complete posting and how to apply, visit https://www.oracle.com/corporate/careers/index.html and search for requisition number 15001A0Q.

Another day, another dead blacklist....

Spam filtering still happens, but are blacklists where its at? Yet another one dies today, making for 25+ reports of DNSBL death since 2007 logged over on my sister site, DNSBL Resource.

HostWinds: A Turnaround Story

From Brian Krebs comes the story of the fall and rise of internet hosting firm HostWinds. Founder Peter Holden explains how they came to get enticed into hosting spammers, which seemed very profitable in the short term, but turned out to not be so tenable for the long haul.

Interesting to note: A Spamhaus listing is one thing, but when AOL says they're not accepting any mail from anyone on your network any more, that really drives the clients away.

Oops: Gmail Spam Filter Changes Bite Linus Torvalds

As reported on Slashdot: "[After recent spam filter changes at Gmail, Linux inventor Linus] Torvalds said his own experience [is] that around 30 per cent of the mail in his spam box turned out not to be spam."

I see lots of false positives in my own mailboxes as well, but I don't think it's really Google's fault. I'm on various lists talking about email authentication, DMARC, and so forth. Those discussions bring a lot of IT folks who often first implement DMARC in a way that practically begs Google to treat their mail more suspiciously. And a few of the lists are managed with outdated list management tools, that have yet to be updated to play nice with DMARC.

So I know I'm an edge case. I wonder if the same can be said of Linus Torvalds.

1,072,835 Page views!

I registered the domain spamresource.com on December 31, 2000 and in the year 2001 first used it as a platform to publish my thoughts and opinions on spam-related topics (hand coding the HTML all along the way).

Throughout 2004 and 2005, I also used the domain name to house an online software store. My employer at the time had a contest to see who could generate the most online sales from their own external websites, and I ended up winning one of the prizes. It wasn't about to make me rich any time soon, but it was a fun experiment in online sales and I made a nice amount of pocket money for a time. (Without engaging in unethical SEO tricks or spam or anything like that.)

In August 2006, I moved Spam Resource over to Google's Blogger platform (and was able to transition many of the prior posts over, to keep a good sense of history going).

Google's Blogger dashboard for Spam Resource says there have been 1,072,835 page views for all time. Let's assume that means that many page views since it went live on Blogger in 2006. That's probably not a lot compared to so many of the bigger sites out there, but it feels like a lot to me.

I'm sad to have missed the one millionth page view, which probably slipped on by sometime earlier this year. But I'm happy to have made it to and beyond this milestone and I just wanted to say thank you to everyone who has read, linked to, or commented on my blog throughout the years. I appreciate you and I thank you.

Domain Registration Privacy: Another View

Electronic Frontier Foundation's Jeremy Malcolm and Mitch Stoltz published an article yesterday quite reasonably expressing concern over a proposal in front of ICANN that would limit use of "domains by proxy"-style WHOIS privacy for domain registration services.

It's a concern I can understand. My wife, a feminist author who has been "lucky" enough to only occasionally have message board threads calling her horrible names (and so far has avoided some of the more intense harassment leveled at other women online) and I have watched other people, often women, get doxxed and harassed in horrible ways and I totally agree that for a lot of people, it is entirely reasonable to not want to put your home address on a domain registration and have it visible to the whole world.

I'm not against online anonymity. I just also see the other side of it, misuse of these tools by bad actors. Consider the following.

Return Path adds AOL to list of certification-enabled ISPs

Today, Return Path announced that AOL has joined the Return Path Certification Program.

Return Path now names "AOL, Yahoo, Microsoft, Comcast, Cox, Cloudmark, Yandex, Mail.ru, Orange, Spamassassin and SpamCop" as ISPs providing value to certified senders, along with "hundreds of others, including key international domains."

Having trouble delivering mail to AOL? Now you can add "look into Return Path Certification" to the list of things to investigate to help improve your inbox rate there.

(No word on whether or not Verizon's recently completed acquisition of AOL will have any impact with regard to certification. If I were a betting man, though, I'd put my money on AOL's mail platform becoming the dominant one in this merger.)

DMARC and mailing lists: We survived!

It's been a little over a year since Yahoo and AOL implemented restrictive "p=reject" DMARC policies, saying you essentially aren't allowed to use their domains outside of their infrastructure. Death to mailing lists was predicted; but what seems to have actually happened is, popular mailing list software was updated to handle the new way of things. Google Groups and Yahoo Groups were quickly updated to handle mailing list posts from users at DMARC-restrictive domains. Mailman version 2 was updated at about the same time.

On Sweating the Small Stuff

Over on the Return Path blog, Scott Roth reminds us why it's so important to remember the fundamentals. Great case study for Dillard's, one of my favorite department stores.

Return Path: When is it OK to Use a Shared IP Address?

Return Path's Tom Sather explains when it's OK to use a shared IP address. Basically, when your volume is very low. He suggests that the cutoff be 50,000 messages a month -- below that level, you should be on a shared IP address. Above that, a dedicated IP address is recommended. I personally think there's some flexibility there, but overall, you do have to draw a line somewhere, and it's pretty good guidance. (I usually recommend that senders mailing to more than 100,000 recipients per month utilize a dedicated IP address.)

The one obvious question that I think goes along with this is, when is it NOT okay to use a shared IP address or shared IP address pool? Here are three scenarios where I think it is truly NOT okay to use a shared IP address or shared IP address pool.

ESPs and Purchased Lists

Over on her Word to the Wise blog, Laura Atkins shares a wonderful list of links to almost every email service provider's policy prohibiting use of bought lists or purchased email addresses.

It's funny, working in this business.

DeliverNow: New Filters @ Orange, SFR, Laposte

According to France-based Deliverability monitoring company DeliverNow, French ISPs Orange, SFR, and Laposte.net have deployed a new spam filtering mechanism powered by Vade Retro.

Sending mail over IPv6? Authenticate!

Josh over at Word to the Wise explains that as Microsoft brings live IPv6 support for its Office365/Exchange Online Protection email platforms, they're mandating that all mail sent over IPv6 must authenticate with either Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM). Unauthenticated mail will be rejected. Read more about it here.

Domains clear.net and clearwire.net have been retired

If you're trying to send mail to subscribers at clear.net or clearwire.net today, you'll notice that all delivery attempts are being rejected, because wireless data provider Clearwire has retired all email services as of April 15, 2015.

Once upon a time, Sprint was the biggest investor in Clearwire, and Sprint's 4G data service was provided over the Clear WiMAX network. Sprint fully acquired Clearwire in 2013, and announced that it would be shutting down the Clear network sometime in 2015. It stands to reason that this email domain retirement is likely related to that overall acquisition and service shutdown.

I was not able to find any information related to the transition of clear.net or clearwire.net subscribers to other domains.

Outlook.com Deliverability Support Form

Lots of folks seem to have an outdated bookmark (or have found an outdated link) for the Outlook.com (aka Microsoft Hotmail) deliverability assistance request form.

Here's the correct link (as of June 2015):
https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&ccsid=

For information on how to troubleshoot deliverability issues when sending to Outlook.com, visit the Outlook.com Postmaster website. Their Troubleshooting page may be of particular interest.

More Jobs @ the Litmus Job Board

Looking for other, non-deliverability related email jobs? Check out the Litmus Job Board.

Troubleshooting AOL Deliverability Issues

Update: As of May, 2018, this information is now out of date, due to the consolidation of the AOL and Yahoo webmail platforms under their new "Oath" umbrella. Click here for my thoughts on how to troubleshoot AOL deliverability issues at this time. 

A client asked me the other day, how do I go about troubleshooting AOL deliverability issues? Since AOL is an ISP where (for the most part) it's easy to solve deliverability issues, I thought I would share some general guidance here, to make it easy for people to get started.

If you're having trouble delivering mail to AOL, it tends to be one of these three things.

1. Is your IP address whitelisted with AOL? Most ESPs manage this process for you, and most of them have probably submitted all, or big groups of their IP addresses, to AOL for whitelisting already. But, stuff happens. AOL doesn't tell you if your IP address falls off of their whitelist. Ask your ESP to check this for you. Ask them to resubmit your IP address to the AOL whitelist. If it is already whitelisted, the attempt will fail with a simple "this address is already whitelisted" error, and then you'll know. If you send on your own, not using an ESP, here's where you can find more information about the AOL whitelist.
2. Are you set up with AOL's Feedback Loop? A feedback loop (FBL) is what allows you to receive a complaint back from a subscriber, when they click the "this is spam" or "junk" button inside of a webmail's user interface. AOL and many other ISPs over FBLs. They indirectly (but importantly) help with your deliverability by allowing you to cease mailing people who complain; preventing repeat complaints. More importantly, if you have an excess of spam complaints, they help you tie complaint numbers back to specific segments or processes that you may need to refine or retire if you want to stay in AOL's good graces (and in the inbox). Like with whitelisting, ESPs tend to manage this process for you. Ask your ESP to help you confirm that your AOL FBL is set up properly and working. Check your ESP's user interface to scan for unsubscribes or complaints that would have been delivered back to you via that FBL. And if you send on your own, not using an ESP, learn more about and sign up for the AOL FBL here.
   
   (An important note for ESP users: Do not sign up for the AOL FBL yourself unless your ESP has given you permission to do so. Your FBL signup attempt can interfere with the ESP's own attempt to manage this process for you. Bad things can happen, like you could accidentally redirect spam complaints to somebody at your company, who won't know what to do with them. Complaining subscribers will not get unsubscribed, and your deliverability will suffer.)
3. Is your spam complaint rate just too darn high? I don't exactly know what constitutes "too high a complaint rate" in 2015. AOL used to publish a threshold of .1% as an allowed complaint rate. Later it was .3%. A quick Google search isn't finding me any updated numbers. Regardless, the AOL bounce error message would probably give you some insight to whether or not excessive complaints are at issue. A common block is "554 RLY:B1" which does indeed indicate that your mail is generating too high a complaint rate as measure by AOL. How do you fix that? Try to tie complaints back to specific segments or processes. If one generates more complaints than others, that may be the culprit. The devil can be in the details, so it might be wise to engage a deliverability consultant for assistance. (AOL does publish some fairly good-but-high-level sender best practice guidelines as well.)

How do I know if I have a good sending reputation at AOL? Here's a link to AOL's IP reputation lookup form. Plug in your sending IP address and their system will tell you its opinion of the mail being sent from that IP address.

Do other ISPs have reputation lookup tools, feedback loops, and postmaster websites? My friend Laura Atkins over at Word to the Wise has put together an excellent matrix listing all of the different ISP resource details and links that she is aware of. This is well worth bookmarking.

Do you have additional insight to share with regard to troubleshooting AOL deliverability issues? Please share in comments.

Are you hiring for deliverability?

I know a few folks who are looking for deliverability-related positions due to layoffs and downsizing at various companies recently. Are you hiring? Feel free to drop me a line and I'll be happy to post your job opening here on Spam Resource for free.

Great work, MAAWG!

On March 10th, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) published a new version of the Senders BCP (Best Common Practices) document -- a solid overview and set of recommendations on how to not be a spammer.

They're not particularly rough or tough recommendations to follow. If you're not a spammer, you're probably following most or all of them already. They outlay good/better/best recommendations for opt-in permission. They explain that email append is unacceptable. They say that subscribers should never unknowingly end up on a mailing list. It should always be easy and simple to unsubscribe. Be transparent in what you do as a sender. Again, this is not earth shattering stuff, but it is good to see it published in a good industry forum, in an easy to digest format.

Do these recommendations matter? Yeah, because just about every mailbox a sender is going to want to send mail to is hosted by an ISP or company represented in M3AAWG. It's a pretty clear guide to what the rules are.

(H/T: Josh over at Word to the Wise)

DMARC & Mailing Lists: A Roundup

In 2014, Yahoo and AOL both implemented strict "p=reject" DMARC policies on their primary domains. This presented challenges to both AOL/Yahoo users and various service providers. Yahoo implemented this new DMARC policy in February. AOL implemented the sample policy in April.

In particular, this makes delivering mail more challenging for discussion mailing list providers. A number of them have had to implement header changes to "play nice" with DMARC restrictions.

• Google Groups implemented DMARC-compatible header changes in April, 2014.
• Yahoo Groups implemented DMARC-compatible header changes in May, 2014.

Running your own mailing list manager? Here are my suggestions on message checks and header changes that you should consider implementing into your discussion list software. They approximately mirror what Google and Yahoo have implemented. (And some savvy commercial groupware/list management software publishers were quick to implement similar changes.)

Some mailing list managers have decided to reject signups from users at AOL and Yahoo. I recommend against taking this stance; your list of rejection domains is only going to grow as additional ISPs and domain owners implement DMARC policies similar to what AOL and Yahoo have done.

Yahoo is not likely to roll this back any time soon. They find their new DMARC policy choice to have been a success. AOL likely feels the same way.

Additional Frequently Asked Questions:
Ask Al: Is my personal domain affected by DMARC?
Ask Al: Should I add a DMARC record to fix the Yahoo issue?

If you run the mailing list manager software Mailman, here you'll find information on how to configure Mailman to work within the confines of DMARC restrictions.

Keep in mind, if you implement any DMARC-related DNS changes for your domain, be sure to test! If you do DMARC wrong, you're setting yourself up to have your mail rejected.

Spamhaus Sued for Libel in UK

Ken Magill has the story on initial filings regarding the lawsuit brought by Craig Ames and Robert McGee against Spamhaus in the United Kingdom.

Engagement Affects Deliverability

Ever dealt with a scenario where you were struggling to get a client's mail out of the spam folder at Gmail and back into the inbox? Maybe not for you, maybe not always, but in my experience, improving engagement, restricting sends to only engaged subscribers, has been a big part of what fixes that type of issue.

Others might have a different opinion. Good for them!

But that's what has worked for me, numerous times, helping numerous senders. So I, and others, will continue to trumpet it. Intelligently, of course.

House Introduces Email Privacy Bill

Read all about it over at The Hill. My question is, does this thing have a chance of going anywhere, based on the current gridlock in Congress? I'm doubtful, but we will see.

Amazon Starting Email Service

According to multiple sources, Amazon is starting up a cloud-hosted email service. Called WorkMail, it looks as though it'll be price competitive to similar offerings from Microsoft and Google. Looking into my crystal ball, I assume they'll get some adoption in 2015. What does this mean to you, dear sender? Get ready, because eventually you'll have a new platform to send to, with a potentially new set of spam and reputation filters to contend with. Let's stay tuned and see if this takes off, shall we?

Microsoft Updates Use of List Unsubscribe Header

What is a list-unsusbcribe header, you might ask? It's an email header, typically hidden from the end user, that includes information that allows the MUA (mail user agent; meaning your email client, email reader, or webmail platform) to submit an unsubscribe request on your behalf. This is typically linked up to an "unsubscribe" button in a webmail provider's user interface. If you see an "unsubscribe" button or link in the Gmail or Outlook.com user interface for a given email message, that message likely contains a list-unsubscribe header.

The header itself is defined in RFC 2369 from 1998. It's very common for email service providers and list management tools to provide support for this header; and if you're building any sort of new tool or list mail sending service, I would recommend including it. Doing so makes it just as easy for a subscriber to click "unsubscribe" as it does for them to click "report spam." Making it easier to unsubscribe means you're likely to garner fewer spam complaints, and thus your deliverability and sending reputation will be at least slightly higher than they would have been without this functionality.

There are two methods of specifying how to unsubscribe a subscriber using the list-unsubscribe header. There's the HTTP method, and the MAILTO method. The HTTP method implies that when it is time to request unsubscribing of that particular user, a particular web page will be visited. The URL would typically include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed. The MAILTO method implies that when it is time to request unsubscribing of that particular user, an email message will be generated to the email address specified in the list-unsubscribe header. (The destination email address typically would include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed.)

A few days ago, Melinda Plemel of Return Path clarified that Microsoft is now only utilizing the MAILTO method and that they are not supporting the HTTP method at this time. (It is implied that Microsoft properties previously supported both the MAILTO method and the HTTP method, but I don't have a lot of experience with the HTTP method myself and I was not able to confirm this.)

TL;DR? Implement a list-unsubscribe header, or make sure your email platform provides one. If you're building it yourself, only implement the MAILTO-based functionality, as it is the most broadly supported. (I'm aware of multiple ISPs supporting the MAILTO method, but I am not aware of any others that are or were supporting the HTTP method, other than Microsoft.)

Ask Al: Help! AHBL is blocking inbound mail!

Mickey writes, "I'm being blocked by AHBL. I own a tax and accounting firm. We send out two newsletters per year to our existing clients using an ESP. We give our clients every opportunity to be removed from the list if they so choose. We do not and have not spammed ever. How did I get blocked by AHBL? No one is able to send me email. Please help. If I did something wrong let me know what. I have no clue and I need my emails working again."

Mickey, if nobody can send email TO you, that strongly suggests that something is up with YOUR mail server. When I tried to send you email at your domain, the message bounced back to me with this error message: "550 5.7.1 74.125.82.46 has been blocked by AHBL."

What this means: Your mail server, or your ISP's spam filtering system, is configured to use the spam filtering blacklist called AHBL. Unfortunately, that blacklist announced that they were shutting down, way back in April 2014. At the end of 2014, the publisher of AHBL moved the blacklist to a sort of "wildcard mode," meaning that anybody who was previously using the AHBL blacklist as a spam filter is now blocking all mail.

That means you -- your mail server, set up by you, your IT consultant, or your ISP, have to go into your mail server's configuration settings and remove any references to AHBL. Once that is done, you will be able to receive mail again.

All mail server administrators should remember to check their mail server spam filter settings periodically. When's the last time you checked to see which blacklists you are using? Are you sure all of those blacklists are still active and publishing? There's a section over on my DNSBL.com blacklist information website all about dead DNSBLS -- make sure you're not using any blacklist shown there, or you could run into troubles like this.

Yahoo Shuts Down Its Email Service In China

As reported on TechCrunch and elsewhere, Yahoo's Chinese email service is no more. Warned all the way back in April, current users of the Chinese version of Yahoo! Mail were given the opportunity to transition their accounts to Alibaba's email service, Alimail.

As of January 1st, any attempt to mail a user at the yahoo.com.cn or yahoo.cn domains is rejected with a "550 relaying denied" error message.

If you run an email service that maintains a filter of dead ISPs or dead domains, I recommend adding yahoo.com.cn and yahoo.cn to your "dead domains" list or similar. There's no point allowing mail to be sent to those domains, as no mail will be successfully delivered.

There is nothing to indicate that users will automatically have the same username at Alimail that they had in Yahoo! Mail, so it likely is not safe for senders to just try to automatically update addresses in their email lists.

January 8, 2019 Update: I am reliably informed that the Yahoo China email domains are now up and running and are active again.