Recent Posts

Troubleshooting the simple stuff

I was talking with one of my Barry pals recently and was treated to a rant regarding deliverability experts that can’t manage simple things. We’ve been having an ongoing conversation recently about the utterly stupid and annoying questions some senders ask. Last week, I was ranting about a delivery person asking what “5.7.1. Too many receipts this session” meant. This morning I got an IM.

More on best practices

Mark Brownlow took my post about best practices and expanded on the theme. He is absolutely right and I encourage everyone to go read his article.

I don't have a "this is spam" button

Here at Word to the Wise we have some unique requirements for mail. For instance, I need to be able to receive examples of emails that are being blocked elsewhere in order to do my job. This means not only do we not outsource mail to someone else, we also run limited spam filtering on the server side. It does mean I have to wade through a bit more spam than others do, but that’s generally not a problem. My client side filters do a decent job at keeping most of the crud out of my mailboxes.
My work account gets very little spam in the folder I use as my inbox. I’m not even sure exactly why this is, but it’s true. One of the exceptions is a psychic (no, really) who has a copy of one of my work email addresses and she regularly spams me offering her spiritual guidance and the opportunity to buy her stuff in order to make peace within my world. I’ve received these before, usually I just delete them and move on.
Occasionally, though, I long for the ease of a “this is spam” button. Just to be able to hit a single button, no work, no effort and know that I have registered my frustration with a spammer. Today was one of those days. I really don’t want this psychic spam in my mailbox. It seems reasonably professionally done, though, so I check the headers to see if it’s being send from any ESP I know and if it’s worth my time to send in a “hey, didn’t sign up for this, and no, I didn’t forget, either” email.
I visited the website belonging to the domain sending the mail.

Controlling delivery

How much control over delivery do senders have? I have repeatedly said that senders control their delivery. This is mostly true. Senders control their side of the delivery chain, but there is a point where the recipient takes over and controls things.
As a recipient I can

Internationalisation (part 2)

In part 1 I talked about internationalised domain names, and how they were mapped onto ASCII strings.
For sending email there are four bits of the message where internationalisation might need to be considered.

Is it ever OK to violate best practices?

Last week @justinpremick tweeted the question “Is it ever OK to break best practices.” My reaction, and reply, was of course it is OK to break best practices, if you know what you’re doing and why.
Best practices are all about things that are safe. If you do these things, in all likelihood you will not encounter any major problems. The things we tell people are best practices are not written in stone and inviolable. Rather, they’re a way to succeed without understanding all the ins and outs of email.
The key to violating best practices is to know why the recommendation is a best practice. Take, for example, practices relating to email design. Best practices say that emails should not be image only and they should be designed in such a way that users don’t have to scroll sideways. However, StyleCampaign recently reported on a campaign from the Canadian Tourist Board that violated both of these best practices.
The email was laid out as a maze, requiring the user to scroll around the message to find the call to action. The designers have reported they are quite pleased with how successful the campaign was received.
So, yes, Justin, you can violate best practices and it is OK. Best practices are not laws, they are guides. If you know what pitfalls the best practices are helping you avoid, then you can violate those guides without problems.

TWSD: Privacy protection for commercial domains

One of my major pet peeves is supposedly legitimate companies hiding behind privacy protection in their whois records. There is absolutely no reason for a legitimate company to do this. There are lots of reasons a non-legitimate company might want to hide behind privacy services, but I have never heard a good reason for legitimate companies to hide.
Look, a company sending any commercial email is required by law to provide a physical postal address in every email they send. What point is there, then, to hiding addresses in whois records? The only thing it does is make a sender look like a spammer. If a sender is a business, then they need to have a real business address anyway, and that address should be available in their domain registration.
It may seem like a trivial point, it may seem minor, but spammers use domain privacy services to hide the various tendrils of their businesses. They don’t want anyone to be able to tell that domain A is related to domain B is related to domain C. Proxy services let them trivially hide their identities. This is the major business use of privacy protection. Real companies don’t need to hide behind privacy services.
Using domain privacy services make senders look like spammers. One trivial thing that ISPs can do is stop providing FBLs or whitelistings to domains behind privacy services. This will weed out spammers without doing harm to real senders. Certification services can refuse to certify companies that hide their identity. My small contribution to the cause is to refuse to represent any company to an ISP if their domain is behind a privacy service.
Just to be clear, I have no problem with personal, non-business domains using privacy services. There are valid reasons individuals may want to hide their physical location. But businesses? Step up and quit hiding.
On the subject of privacy services, Mickey recently reviewed a court ruling that commented on the legality of using privacy services. The court says:

Internationalisation (part 1)

There’s been a gentle bit of uproar recently about ICANN finally beginning the process of rolling out support for internationalized domain names (IDN) at the DNS root and the effect that may have on email senders. Even if you haven’t noticed the uproar, it’s still a subject you probably want to be familiar with if you’re sending email.
What are internationalised domain names?
An internationalised domain name is simply a domain name that uses non-ascii characters – most anything other than a-z, 0-9 and ‘-‘ – such as those used in these URLs: http://пример.испытание/ or http://例子.測試/ (If those links are unreadable or don’t work, it means that your browser isn’t handling IDN well or doesn’t have the appropriate fonts installed yet).
They’re an obvious thing to want, especially if you’re from anywhere other than an anglophone country, but the Internet was originally built as an ascii-only network, and under the covers it still is entirely ascii-only, so layering non-ascii characters on top has taken a lot of work and time to roll out. IDN development dates back to at least 1996 and it has been supported by some top level domains since 2003. So the recent announcement to support non-ascii top level domains is just the latest step in a long and careful process.
Almost all of the underlying internet protocols are still ASCII based though, including DNS and SMTP, so a lot of the internationalisation work involves mapping non-ASCII words onto ASCII strings before they’re passed to the network, and mapping them back again before they’re displayed to the user. This is done in a fairly ad-hoc way, different in different protocols.
If you were to visit the cyrillic URL I mentioned above then the first thing your web browser would do would be to take the cyrillic string “пример.испытание” and translate it to the ASCII hostname “xn--e1afmkfd.xn--80akhbyknj4f” then look that up in the DNS to find the server handling that URL.
If you were to display that on a webpage or in an HTML email it might be converted to ASCII as”http://приме р.и с п ы тание/”.
If you were to send it as part of a plain text email, encoded as UTF8/quoted-printable, it would look like “http://%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80.%D0%B8%D1%81%D0%BF%D1%8B%D1%82%D0%B0%D0%BD%D0%B8%D0%B5/”. If there’s a lot of non-ASCII characters in the message then it’s more likely to be encoded as UTF8/base64: “aHR0cDovL9C/0YDQuNC80LXRgC7QuNGB0L/Ri9GC0LDQvdC40LUvCg==”.
And all of those will (or at least should) be displayed to the end user identically.
Confused yet? That’s fine. Internationalisation on the Internet is a very complex and inconsistent subject. In my next post I’ll try and narrow down which bits of it you need to worry about when it comes to sending email and to not upsetting phishing or spam filters at the recipients ISP.

I need IP addresses to avoid throttling

Number three of seven in our occasional series on why ESPs need, or don’t need, lots of IP addresses to send mail properly.

Privacy policies in the real world

This weekend we took the car in for service. Instead of dropping it off at the dealership, we found a small, local garage. Prominently positioned on the counter was their Email Privacy Policy.