Related Posts

Email predictions for 2015

Welcome to a whole new year. It seems the changing of the year brings out people predicting what they think will happen in the coming year. It’s something I’ve indulged in a couple times over my years of blogging, but email is a generally stable technology and it’s kind of boring to predict a new interface or a minor tweak to filters. Of course, many bloggers will go way out on a limb and predict the death of email, but I think that’s been way over done.
ChangeConstant
Even major technical advancements, like authentication protocols and the rise of IPv6, are not usually sudden. They’re discussed and refined through the IETF process. While some of these changes may seem “all of a sudden” to some end users, they’re usually the result of years of work from dedicated volunteers. The internet really doesn’t do flag days.
One major change in 2014, that had significant implications for email as a whole, was a free mail provider abruptly publishing a DMARC p=reject policy. This caused a lot of issues for some small business senders and for many individual users. Mailing list maintainers are still dealing with some of the fallout, and there are ongoing discussions about how best to mitigate the problems DMARC causes non-commercial email.
Still, DMARC as a protocol has been in development for a few years. A number of large brands and commercial organizations were publishing p=reject policies. The big mail providers were implementing DMARC checking, and rejection, on their inbound mail. In fact, this rollout is one of the reasons that the publishing of p=reject was a problem. With the flip of a switch, mail that was once deliverable became undeliverable.
Looking back through any of the 2014 predictions, I don’t think anyone predicted that two major mailbox providers would implement p=reject policies, causing widespread delivery failures across the Internet. I certainly wouldn’t have predicted it, all of my discussions with people about DMARC centered around business using DMARC to protect their brand. No one mentioned ISPs using it to force their customers away from 3rd party services and discussion lists.
I think the only constant in the world of email is change, and most of the time that change isn’t that massive or sudden, 2014 and the DMARC upheaval notwithstanding.
But, still, I have some thoughts on what might happen in the coming year. Mostly more of the same as we’ve seen over the last few years. But there are a couple areas I think we’ll see some progress made.

Read More

How useful are feedback loops

Things are extremely busy here and blogging is going to be light for a few weeks. I’ll be reposting some older blog posts that are still relevant for today’s email senders.
Today’s post is a repost from November 2008. I look at the whys and hows of FBLs, address some of the objections people had to them and discuss how senders should deal with FBL mail.
There has been a very long, ongoing discussion on one of my mailing lists about whether or not feedback loops are a net good or a net harm. I believe, overall, they are a net good, but there are people who believe they are not. The biggest objection is that the lawyer mandated redaction of the To: address combined with the fact that some users use the “this is spam” button to delete unwanted email, makes it difficult for some FBL recipients to sort out the real issues from the cruft.
Redaction can be a problem for some senders, particularly for the small mailing list hosted as a hobby or contribution to the community. In order to effectively deal with FBL emails, a sender needs to have tools on the email sending side and on the FBL receiving side. This is often more overhead than the volunteer list maintainer wants to handle. Unfortunately, these senders are a minority and therefore their issues are often not addressed by the ISPs.
Some of the objections and complaints about “broken” or “useless” FBLs come from people who do not really have any history for the FBLs, where they are, what they were designed for and who their target audience is. A bit of history may help explain why things are how they are.
The First FBL
The “this is spam” button evolved from the “notify AOL” button. This button was a way email recipients could notify AOL staff about any number of problems, including threats, viruses and other unwanted emails. As time went on, this was changed to “this is spam” to encourage users to report more spam so the AOL would have the data to make delivery decisions. Eventually, AOL made the decision to share that data with some senders and ISPs. The lawyers made the decision to redact the “To:” address, but not make any other changes to the message because they believe they should not be sharing subscriber email addresses with third parties. As some people correctly point out, the lawyers are not interested in hearing from non lawyers about changing this. It is possible that another lawyer may be able to put together a position paper and convince them this stance is overly cautious. I am pretty sure, though, that no one without a legal degree will be given any audience from them.
Given the success of the AOL FBL and the demand from both ESPs and ISPs for FBLs, other ISPs started offering FBLs as well. Many of them also redacted the To: address, either just following AOL’s lead or under advice of their own counsel.
That means, as senders, we are in a situation where we really cannot make the ISPs change what they’re doing. We can either adapt our own mailing practices to cope with them or we can forego the data provided by the FBL. One of the challenges in choosing to shun the whitelist at AOL that in order to qualify for whitelisting, you have to accept a FBL. For ISPs, who want to whitelist their outgoing MTAs, but have customers sending mail, maybe running small mailing lists, or who are forwarding mail to their ISP account, this can be a problem. However, any ISP needs some sort of abuse desk automation, and this automation should be able to handle FBLs. This can also be a problem for small ESPs or companies doing in-house email marketing. They buy something off the shelf to handle mail (or install mailman) that does not do VERP or otherwise enter the specific address in the email. When faced with a redacted email they cannot do anything with the complaint.
What does the FBL email tell the FBL recipient?
This really depends on what role the FBL recipient plays in the mail transport system. Bandwidth and network service providers use the FBL as an aggregate tool. They really only deal with FBL complaints if there is a change in complaint volume about an IP, they don’t treat each complaint as a valuable source of information. Typically what happens is that an ISP abuse desk notices a spike in complaints. After investigation, they may discover that a customer machine is compromised. They then notify the customer, the customer patches or disconnects the machine and the problem is fixed.
ESPs tend treat the FBL as an unsubscribe mechanism as well as a way to monitor customers. A few FBL complaints are not necessarily a sign that the sender is spamming, but once a threshold is reached the ESP delivery / abuse team addresses the issue. Spammers can get FBLs and often use them as a way to clean lists of complainants. Some really dirty spammers even suppress those complainants from all their lists.
Is a FBL useful?
This is really something that someone else cannot tell you. Some companies find FBLs to be extremely useful, even after they have had to make investments in software (either off the shelf like our Abacus software, or something custom written internally) to send mail that will survive the FBL redaction process and to handle the actual FBL email. Some companies find the FBLs to be more trouble than they are worth. The question, however, is really one only the sender can answer.
Overall, I think FBLs are more helpful than they are harmful. They do require investment on both sides of the transaction, but does encourage senders and receivers to cooperate with one another.

Read More

I do not think that means what you think it means

Yesterday, I looked at the analysis of ESP delivery done by Mr. Geake. Today we’ll look at some of his conclusions.
“Being blacklisted most likely suggests that sender IP either sends out to a great deal of unknown or angry recipients.” That’s not how most blocklists work. Most blocklists are driven by spam traps or by the personal mailboxes of the list maintainers. The only blocklist that took requests from the public was the old MAPS RBL, and I don’t believe that is the case any longer.
Blocking at ISPs is often a sign of sending out a lot of mail to unknown or angry / unengaged recipients. But most ISPs don’t make their lists public. Some allow anyone to look up IP addresses, and if we had the IPs we could check. But we don’t, so we can’t.
“[…] if you share this IP with Phones4U then only 62% of your emails will be accepted by a recipient’s email server. That’s before they hit the junk filter. I wouldn’t want to pay for that.” This conclusion relies on the Sender Score “accepted rate” number. Accepted Rate is a figure I don’t rely on for much. I’ve never been able to reconcile this number with what client logs tell me about accepted rate. For instance, I have one IP address that has a 4.4% acceptance rate. But I know that 19 out of 20 emails from this IP do not bounce. In fact, it’s rare to see any mail from this IP bounce.
The one thing that Mr. Geake gets right, in all of this, is that if you’re on a shared IP address with a poor sender, then you share that sender’s reputation. Their reputation can hurt your delivery.
But a dedicated IP isn’t always your best bet, either.  Smaller senders may not have the volume or frequency required to develop and keep a good reputation on an static IP. In these cases, sharing an IP address with similar senders may actually increase delivery.
For some senders outsourcing the email expertise is a better use of resources than dedicating a person to managing email delivery. For other senders, bringing mail in house and investing in staff to manage email marketing is better.
Tomorrow: how do you really evaluate an ESP?

Read More