Recent Posts

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

Read More

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.

Read More

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.

Read More

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:

Read More

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.

Read More

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.

Read More

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.

Read More

Non marketing uses of email

Box of Meat tweeted earlier today:

tired of marketers calling their conferences and cliques “email whatever” as if marketing is the only thing email is for

Read More

I need IP addresses to handle the volume

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

Read More

Senders need to take responsibility

Having just returned home from another conference, my head is full of new ideas, new thoughts and new projects. I enjoy seeing old friends, making new contacts and sharing ideas. One thing I don’t enjoy, though, is listening to senders and marketers complaining about how hard it is to be a sender because the ISPs will not tell them what standards they need to meet.
If the ISPs would just tell us what they want us to do, we’ll do it.

The ISPs have told senders what they want them to do. They want senders to stop sending mail that their users don’t want. It is a very simple statement.
Stop sending spam.

For many senders, however, it’s not enough. “Tell us exactly what we need to do to stop sending spam. What complaint rates must we be under? What bounce rates do we have to be under? How do you want us to do this?” By this point in the conversation the ISP person is mentally rolling their eyes and looking for a way to escape the conversation.
The ISPs don’t want to tell senders how to behave, they want senders to start behaving. Stop sending spam should be all they need to tell senders.
Senders who ask for ISPs to tell them how to stop sending mail recipients think is spam are looking for specific thresholds they can stay under. They’re not really interested in actually sending wanted mail, they’re interested in sending good-enough mail, where good-enough mail is simply mail that gets to the inbox.
Want to know why ISPs don’t think much of many senders? Because the senders are not visibly taking any stand against abuse. I know there are a lot of senders out there who stop a lot of spam from ever leaving their systems, but there’s also a lot of unwanted mail that goes out, too. Some of that mail is even spam by any definition of the word. All the ISPs can see is the spam that gets through, and then they hear just tell us what to do and we’ll do it. From an ISP perspective, this means the senders only care about the thresholds and getting in under the ISPs’ radars.
Senders need to take more responsibility for the mail that goes out over their networks.
What do I mean by this? I mean senders need to stop waiting for the ISPs to define good practices. Senders need to implement standards and good practices just because they’re good practices, not because the ISPs are dictating the practices. Senders need to stop customers from doing bad things, and dump them if they won’t stop. Senders need to stop relying on ISPs for specific answers to why mail is being blocked. Senders need to take responsibility for the mail going across their networks.
It’s time for senders to grow up and stop relying on others for guidance. They shouldn’t implement good practices just because the ISPs tell them to, but instead should implement good practices because they are good practices.

Read More
Categories
Tags