Sean Spicer and WHOIS

ARS Technica reports on Trump minister of propaganda (I think that's his title) Sean Spicer and how he registered a handful of domains a few years ago with his still-current contact information, including his still-current phone number.

I'm a big fan of WHOIS transparency overall, and I'm not a fan of obscuring ownership information, because I know that bad guys abuse "privacy proxy" services to make finding them harder. But to be fair, I'm more than willing to share this story that comes at it from an alternate point of view, showing that Mr. Spicer's phone number is easily obtained and implies that perhaps people are using this information to harass him as a result. I think. The article is unclear on that point.

Nonetheless, the guy is a public figure. Heck, Trump's personal cell phone number is widely known, and has been for years. Google it, if you don't believe me. I don't know if the concern of harassment of a public figure is a reasonable defense as to why we should allow hiding who owns a domain name. I don't think it's enough of a reason from where I sit.

If it was me, I would have gotten a separate phone number just for the registrations. Or just use a Google Voice number that I can generally leave on, but turn off when I need to, or use to block certain numbers. (I actually do this and have done this for years. It's very handy.)

Howto: Maximize Inbox Delivery to Yahoo

What is the path to deliverability success at Yahoo! Mail? Here are five simple considerations that will help point you in the right direction.
  1. DKIM: Sign your mail with DKIM (Domain Keys Identified Mail). It's an email authentication technology, and the original version of it was actually invented by Yahoo folks. You'll need this to be able to participate in the Yahoo ISP Feedback Loop (FBL), and it helps make it easier for Yahoo to identify your mail, giving you a subtle deliverability boost, if you're a good guy.
  2. FBL: Sign up for the Yahoo Complaint Feedback Loop. They call it a CFL, almost everybody else calls it an FBL (Feedback Loop). This allows you to receive complaints back from Yahoo when somebody complains about your mail by making it as spam in the Yahoo! Mail user interface. You'll unsubscribe those folks, preventing further complaints, but if you're smart, you'll also use this data to identify which list segments or signup sources are more problematic than others. The theory being that higher complaints leads to poorer inbox delivery. Use FBL/CFL data to figure out which segments to stop sending to, before they cause a deliverability problem. Yahoo no longer has a dashboard where you can check FBL participation -- now you just submit it to their system, wait a few days for approval, and then complaints should in theory start coming. If you think you submitted it a few years ago but can't remember, go ahead and submit it anew.
  3. Engagement: Focus on your most engaged subscribers. Yahoo is very much engagement driven (as is Gmail, as are other ISPs). Meaning that if you have a lower-than-average percentage of subscribers opening and clicking on your email messages, you're much more likely to find your mail relegated to the spam folder. If you're in the business of shoveling a ton of "barely wanted" mail, like endless attempts to convert free users to paid users, good luck. This type of mail almost always has a low engagement rate when measured by percentages of mail sent and it can be darn near impossible to get solid inbox delivery, unless you take some pretty dramatic strategic steps to modify what you do to convert those potential paying customers.
  4. DMARC: Implement DMARC, if you can. This can get a bit tricky, and I might be a little bit ahead of the curve on this one, but bear with me here. DMARC is "an email-validation system designed to detect and prevent email spoofing," wherein you publish a DNS record that helps instruct ISPs when they can discard mail that purports to be from you, but fails validation checks. My thought here is that the more you do to ensure that your mail is proven legitimate, the better off ISPs can get at blocking illegitimate (phishing, spoofing) mail. There's a potential for an indirect deliverability benefit to you. (And I don't know about Yahoo with certainty, but I've seen some data that suggests other ISPs provide a modest deliverability boost when a DMARC record is found.) DMARC takes some technical knowhow that not everybody possesses. My recommendation? Partner with somebody like Proofpoint or Agari and have them guide you through the process.
  5. Read and Register: Read Yahoo Mail's Deliverability FAQs page. Submit your sending IP addresses to Yahoo by way of this form. Be honest and clear when describing your list hygiene and mailing practices. You'll notice that I list this as number five, not number one. That is because I feel it's important to get your "sending ducks in a row" before reaching out to an ISP. Any ISP is going to want you to make sure you're already putting your best foot forward -- doing everything you can from a technical perspective and best practices perspective (opt-in only) to ensure that your mail is in compliance with the ISP's policies. Reaching out for help with deliverability issues-- when you are NOT in compliance with the ISP's policies-- is a lost cause. You'll either get through the door but then kicked right back out again, or they'll turn down your request, or they'll simply not reply. It'll be very frustrating. ISPs, even big ones run by big companies, don't care about "your big brand" and they already "do know who you are" -- so focus on making sure your marketing program is executing correctly before ever trying to play that relationship card.

What can SNDS tell you?

Microsoft Hotmail / Outlook.com's SNDS (Sender Network Data Services) portal is a useful interface where you register to be able to look up reputation data specific to your sending IP addresses. In my "How to troubleshoot Microsoft Outlook.com / Hotmail Delivery Issues" article, I suggest signing up for it.

People sign up for it, then they invariably ask, OK, what do I do with this thing? What am I looking at? What do each of the fields mean?

It turns out that Microsoft has you covered! Check out the "Data Provided" section here. They break down filter results, explain what they mean with regard to time frames, trap hits, and so forth.

It's not the complete guide with regard to "what do you do next" but it's a step in the right direction. I've found it quite useful and I hope that you do, too.

H/T: Chris Truitt.

The Scunthorpe Problem

Have you heard of the Scunthorpe Problem? It highlights the side effects associated with trying to filter out profanity.

Where it affects me and the clients I work with most often is with personalization. They have to be careful -- creating an email with "Dear Firstname / Lastname" as the opening text can cause a problem if either of those fields contains something obscene or otherwise insulting. I've found that if it is paying customers who provided credit card information at the point of data collection, this isn't very likely to be a problem. Those customers aren't going to enter a swear word instead of their name. But if it's a free registration -- especially if it's in exchange for providing a free service or download -- those fields are sure to be filled with unbelievably profane garbage.

So it seems reasonable to try to filter it the profanity, right? You don't want to send out an email that says "Dear D*ckhead" -- that customer is unlikely to be happy about receiving that. Even if they entered that to begin with. So you add "d*ckhead" to your profanity filter. But what do you do when the next guy enters "D*kkhead"? How many variations can you include in the filter? It can seem never ending.

And then get ready for the false positives -- that's the Scunthorpe Problem.

So what do you do? Is there an easy answer? I don't think so. But if it was my call, I would:

  • Not directly filter names of people who provided credit card info. This segment is very unlikely to contain profanity.
  • Provide basic profanity filtering on free registrations, even if it can occasionally miss something, or cause a false positive rejection.
  • Don't personalize based on first name / last name, for subscriber list segments that are from free registrations.
  • I would possibly enforce a double opt-in on the free registrations. That way you'll know that if somebody types their name in as "D*ckhead," they themselves did it, and there's nobody else to blame.

Just about every one of these options carries risk, though. Doesn't it? If you block somebody unintentionally, then they get mad and complain about it on social media (providing new examples for that Scunthorpe Problem wikipedia page). Or if you send out an email with profanity in it, you're just as likely to get yelled at, and potentially have a PR issue on your hands, even if it's not your fault that the subscriber provided bad data.

What is UCENET?

Formerly known as the London Action Plan, UCENET (Unsolicited Communication Enforcement Network) exists to promote international spam enforcement cooperation and address spam related problems, such as online fraud and deception, phishing, and dissemination of viruses. Its members include government and internet industry representatives and public agencies from 27 countries.

You can learn more about UCENET's recent activities here.

(H/T to the Mainsleaze blog.)

Ask Al: What of Senderbase?

Emanuel writes: "I need assistance with Senderbase. What ISP report to Senderbase? Is there a way to view Senderbase complaints? We add all ours IPs in the feedback loop, but not in the feedback loop of Yahoo. Is it possible that the lack of a Yahoo feedback loop is the problem?'

Emanual, I'm sad to say that it has been a very long time since I have run into client issues that I believe to relate to Cisco's Senderbase. I don't know if Yahoo complaint data is fed to them, to be honest. But I'll throw the question out here and we'll see if someone else out there has some other ideas. Feel free to share your thoughts in comments, and thank you in advance!

List-unsubscribe on Gmail: Frequently Asked Questions (FAQ)

Google has long provided support for the list-unsubscribe header (as defined in RFC 2369) in Gmail. It is listed in their bulk sender guidelines as "strongly recommended." Meaning that if you're a good guy sender, it is expected that you will implement support for this functionality.

Google announced support for the list-unsubscribe header in Gmail back in 2009. Since then, lots of ESP folks have some idea of how it works, but it seems to be a bit lightly documented. So here I will throw together a few frequently asked questions (with answers) that I hope will help folks trying to understand how this functionality works.

Frequently Asked Questions (FAQ)

What method does the Gmail list-unsubscribe functionality utilize?

Gmail supports both the MAILTO and HTTP types of list unsubscribe functionality. When the Gmail unsubscribe link is clicked, here's what happens for each type:
  • The MAILTO method results in an email message being sent back to a special email address found in that list-unsubscribe header.
  • The HTTP method results in Gmail linking you to the sender's unsubscribe page where you can finish submitting your unsubscribe request.
For comparison, Both Apple's iOS10 email client and Microsoft's webmail properties (Hotmail/ Live.com/ Outlook.com) only provide support for the MAILTO method.

Why does the "Unsubscribe" link not show for all messages?

Even if an email messages includes a list-unsubscribe header, Gmail's user interface will not display the "unsubscribe" link if Google believes the sender's reputation is poor. It turns out that this is one of those things that is lightly documented, but widely observed. The best proof of this reputation-related requirement can be found here, where Google said the following when announcing support for this functionality:
"This only works for some senders right now. We're actively encouraging senders to support auto-unsubscribe — we think 100% should. We won't provide the unsubscribe option on messages from spammers: we can't trust that they'll actually unsubscribe you, and they might even send you more spam. So you'll only see the unsubscribe option for senders that we're pretty sure are not spammers and will actually honor your unsubscribe request. We're being pretty conservative about which senders to trust in the beginning; over time, we hope to offer the ability to unsubscribe from more email."
Why do ISPs like Gmail and Hotmail want to utilize this list-unsubscribe functionality?

I think Return Path's Melinda Plemel explains it well here:
"So how do the Mailbox providers benefit from the use of list-unsubscribe? Since their users were using the “report spam” button in a way that wasn’t originally intended, businesses would often see inflated complaint rates. This in turn caused false positives with mailbox providers’ spam filters, and flagged opt-in permission-based email as spam. By creating a trusted way for people to unsubscribe, spam complaint rates have been more accurate, and mailbox providers have gotten better at separating spam from graymail. This also explains why both Outllook.com and Gmail use the list-unsubscribe functionality leverage the list-unsubscribe option when for senders with good sending reputations. Neither Google or Microsoft want the list-unsubscribe to be abused by spammers, too."
In other words, it helps ISPs better tell good senders apart from spammers. This, in turn, benefits good senders, because making it easier to unsubscribe results in fewer spam complaints, and fewer spam complaints equates to a better chance of getting email reliably delivered to the inbox.

Should I be concerned about this List Unsubscribe functionality making it too easy for recipients to unsubscribe?

Litmus's Chad White has put together a fantastic analysis for the impact the recent launch of Apple iOS10's support for list unsubscribe, helping to allay concerns that marketers may have. Its guidance also applies equally well to concerns over the Gmail and Microsoft versions of the list unsubscribe functionality.

Got any other questions? Leave them in comments, and I'll update this post as time allows.

(H/T to Laura Atkins, who helped me hunt down that original Google announcement. Laura has her own thoughts on List Unsubscribe, as well.)

5 Reasons List-Unsubscribe Concerns Are Overblown

Over on the Litmus blog, Chad White shares why marketers shouldn't panic or try to disable the list-unsubscribe header on their email messages. Great insight, and the research aligns with what I've been seeing as well.

Microsoft breaks DKIM signature?

It's kind of rare, but not rare enough. Every now and then I hear of a client who is seeing intermittent DKIM failures at Microsoft Outlook.com/Hotmail properties. A Delivery Team Lead for one of the bigger ESPs posted about this on the Mailop list recently, looking for feedback and thoughts. The discussion that ensued seemed to come to a consensus that there are (rare) times when Microsoft may be modifying message content slightly, and thus causing the DKIM signature to break.

Steve Atkins of Word to the Wise has done a fantastic job of writing up some best practice suggestions on how an ESP can deal with this type of thing.

In addition to Steve's excellent suggestions, I would add, if it's not easy for you to modify your DKIM signing configuration, one thing to try when you run into these issues is, remove all tabs from the body content. It was suggested in one of the examples shared that an intermediate Microsoft server may have converted tabs to spaces, which potentially caused the DKIM signature failure. Of course, Steve Atkins is spot on to take the conversation to a higher level and look at how to modify the DKIM config to address this overall, but if you're looking for something to try right now, this is also something I would try.

What You Need to Know About DMARC and Deliverability

Bronto's Chris Truitt explains how DMARC works, how it impacts deliverability and he outlines things to consider when configuring your DMARC record.

Spam Museum Welcomes 100,000th Visitor

From the not-just-email department: Local TV station KAAL-TV reports that the Hormel Spam Museum in Austin, Minnesota welcomed its 100,000th visitor last week. Her prize? 200 can of Spam. Yum.

Yuck: iCloud Calendar Spam

Are you one of the many millions of unlucky souls receiving spammy calendar invites? Apple is apparently aware of and working to address this type of thing, according to the iMore blog. But if you can't wait for that, the Verge has a few suggestions on what you can do about it.

Virgin Media is so rustic and artisan you get to hand-sort your own spam

Can't beat that headline. UK ISP Virgin Media is having a few problems with its spam filters, reports the Register. Previously hosting user mailboxes on Google-managed systems, the ISP was forced to bring it back in house after Google stopped selling the service to ISPs. Apparently, hilarity has ensued.

Good news for senders: Instead of blocking mail outright, suspected spam will now be routed to the spam folder. Sounds like ISP users will be able to identify spam and non-spam to the ISP, to help improve the filter over time.

A quick search suggests that @ntlworld.com and @blueyonder.co.uk are probably the relevant Virgin Media email domains affected by this issue. I'll update this post if I learn more.

MegaRBL DNSBL FUBAR

Over on the Word to the Wise blog, Laura Atkins explains what happened with that spate of short-term MegaRBL DNSBL listings you may have noticed last week.

AOL FBL Sending Address Changing

The AOL Postmaster Blog reports that on January 16, 2017, the from address for AOL feedback loop complaints will change from
scomp@aol.net to fbl-no-reply@postmaster.aol.com

AOL Postmaster Lili Crowley reports that this change is being implemented at the same time as they implement DKIM signing of all complaints sent.

AOL seems to be timing the change to occur after the busiest part of the Holiday email season has passed.

Putting Spam to the culinary test

Time for a distraction. The Staunton (VA) News Leader reports on the Virginia Military Institute's Spam challenge, wherein chefs are tasked to "create an entree and two sides using only five mystery ingredients and anything from the pantry, which was comprised of items that would have been available to the World War II-era home cook." Spam croquettes, anyone?

Holiday Season Tip: Don't Experiment

Hey, November and December are a big, important time period for online retailers. Lots of people always ask me what they should do to minimize the risk of deliverability problems during this period. Keeping in time that ISP email volumes are up (way up), ISP staff managing unblocking requests are probably getting more requests than usual, and that they all have holidays they're going to go on at some point. There's not always going to be a backup contact able to help. Responses are going to be slower. Maybe even less forgiving, out of frustration.

So what is the one most important thing you can do to make sure you don't have to deal with any of this? Avoid surprises. This isn't the time of the year to experiment. Don't add a new list. Don't buy a list. Don't mail a seven year old list that you just found in the back of a cabinet (that really happened). New lists, new data sources, anything you haven't been mailing to recently already, that adds new risk. Without knowing the reputation history of mailing to these "new to you" subscribers -- and how they're going to react to your mail in particular, you're opening yourself up to deliverability trouble.

Avoid that trouble. Don't start changing things now. Get through the season before adding more variables to what you're doing.

Gmail Updated on iOS

Google announced an updated version of the Gmail email client for iOS devices today. The big new enhancements seem to be "undo," "swipe to archive or delete" and a faster search function. There does not appear to be any support at all for list-unsubscribe functionality, which Gmail's Android client appears to have. Poking around in the new version of the iOS app, I can't get it to trigger any sort of action based on the list-unsubscribe header whatsoever. Strange, given Gmail was long a driver of this functionality.