Month: June 2014

For several years, I have made it a practice to have separate email addresses (aliases) for separate purposes. This has made it easy for me to dispose of addresses when I no longer needed them – usually when I no longer wanted to receive emails from parties to whom I’d given the addresses. This also makes it easy to detect, and shut off mail from, companies that add you to their spam lists. Examples include online stores that I’d buy from ([email protected]), annoying realtors ([email protected]), and addresses I’d use in a variety of online forums ([email protected]). If you own your own domain name, or have a good email provider, this process is generally fairly simple.

Recently, I noticed I wasn?t getting any emails from Meetup.com. I?d just unsubscribed from a bunch of groups and changed others to not email me anymore, and since I hadn’t hosted any events in my group for some time, I didn’t think anything of it. As I’ve spent most of the last couple of months traveling, I did not miss the deluge of notifications of activities I wouldn’t be able to participate in anyway.
Separately from this, I had stopped receiving emails from American Express. I did not really notice this until I attempted to reset a password and never received the confirmation email that was to allow me to make the change. I sent myself a test email, and got it immediately, so I figured it was an issue on their end. As an alternative, I had Amex text me the confirmation code I needed, and promptly forgot about the email problem.
I also stopped receiving emails from Amazon.com, telling me my order had been received. But since I was getting text alerts of the package shipping and delivery status, I felt like I was still in touch with Amazon, so I didn’t think anything of it.
Finally, my financial advisor needed me to sign some electronic documents, and they kept emailing me, telling to sign them. I kept waiting for the forms, coming via Adobe’s document signing service, and they never arrived. Then I started to do some simple math and realize that we had a problem.
So I began to pay attention to this problem and troubleshoot it. My personal email was hosted at a budget hosting provider, and then forwarded to a Gmail account. I would send test emails to myself, and they would show up. I checked my junk mail folders, and searched everywhere, but could not find any recent emails from Amazon, Amex, Meetup, and other vendors, yet my tests came through! Why? Now that I was aware of the problem, I had to know, so after I’d exhausted all the troubleshooting I could do myself, I opened a chat session with my hosting provider. The results were astounding.
But first, a little background information. DNS – Domain Name System – is the service that translates somewhat human-friendly Internet site names, e.g., nikolaidis.com, amazon.com, and example.com, into computer-friendly numbers, e.g., 74.207.233.119, 72.21.194.212, and 93.184.216.119. There are several types of DNS records, and one of them is SPF, short for Sender Policy Framework. This began as a proposal several years ago to allow for some sort of authentication of email.
Most people probably do not realize that, in most cases, it is quite trivial for anyone to send email as just about any address they want, and unless the mail servers’ administrators take deliberate action, there’s nothing stopping this. This means that I can quite easily send an email to you as [email protected], telling you to click the link below to reset your password, and if you are gullible enough to do so, steer you to a phishing site where I steal your credentials. SPF is an attempt to combat email forgery, but allowing owners of domains to set up authorized lists of email servers that they can send email from. If the owner of the domain configures this, and the receiving mail server actually checks it, this can be an effective way to authenticate the sending server and allow or reject the email, based on its validity.
Back to my budget host. A couple of months ago, supposedly to comply with an ICANN regulation (which I do not buy for a second), my host made a change that enforces checking of SPF records. To prevent spoofing of emails, they will not forward any email for a domain that has an SPF record unless they are authorized to do so. This means that if I am not Amazon.com, my host will not forward emails claiming to be from Amazon.com. So far, so good.
Some mail systems have the concept of an alias, which is one way of saying “anything addressed to [email protected] goes to [email protected].” Another way to accomplish this is to set up an email forwarder, which is another way of saying “any emails that come here for [email protected] we will forward on to [email protected].” If the difference seems trivial, it can be. Essentially, forwarders are usually used to send email to a different mailbox or server, whereas aliases are both local to the same account on the same server. So if [email protected] and [email protected] are on the same server, you’d normally use an alias, but if Robert wanted his email to forward off to a Gmail account, he’d use a forwarder.
Here’s where things get stupid.
My budget host supports email aliases by using forwarding addresses only, not aliases. I would normally make up a forwarder for each purpose, and have that forwarded to my Gmail account. My host’s recent attempt to comply with a supposed ICANN directive means they will no longer “forward” an email unless the SPF records match. Since Amazon does not have an SPF record, saying that my email host is authorized to send email for them – why would they? – my host will not forward my email, which has landed in my mailbox, to my own external mailbox. “Okay,” I said, “I’ll set up a new, local account on my host, and have my forwarders forward to it, and then check that mailbox separately.” Nope, that won’t work either, as this is still considered a “forward” and my host won’t do that.
What?!?! When I heard that, I was astounded. Essentially, this host, which is a large, tier 1 hosting provider, has just killed the idea of aliases altogether. Their suggestions were for me to have Amazon set up an SPF record for my host mail server (Uh… no, you level 1 idiot, Amazon is not going to grant me the honor of sending email as Amazon to every one of their customers who wants to receive email from them), and for me to simply set up a new mailbox for each address I want. I have over 100 email aliases. So they want me to set up and check over 100 mailboxes now? I think not!
This is a case of good intentions gone horribly awry. I can only hope my host realizes the level of idiocy they’ve fallen to in their attempt to make things better. In the meantime, I’m moving my email to the one that we use and resell at work, which does not have this well-intentioned, yet stupid, restriction. As a result of my not receiving emails from Meetup.com for several weeks, I never got the email telling me that my dues were due again, and as a result, I lost control of my favorite Meetup group, which I’ve run for the past year. Fortunately, one of my fellow members pointed this problem out promptly and I was able to renew my subscription and reclaim my group. This is a relatively minor consequence, but it does not take a long stretch of the imagination to see more serious consequences coming from emails being unanswered for several months.
On the plus side, I realized that I was still receiving emails from Plenty of Fish, so I was able to use this as an opportunity to delete that forwarder. Advice to those of you who use online dating: avoid PoF. Trust me, eHarmony and OKCupid are better.