Recent Posts

A short note

We had a catastrophic failure of our mail server over the weekend. We lost both drives and the server won’t boot past the BIOS stage. Most of the weekend was spent on recovery and restoration, and we expect to have mail restored today. In the meantime, if you need to get a hold of me I’m available on AIM as wttwlaura and can be reached at my gmail account: wttwlaura.
This does mean I have the opportunity *ahem* to re-organized mail and my mail handling work flow. What better time to move to zero inbox than now when I have to rebuild my sieve scripts from scratch?
UPDATE: mail is back and I can be reached at the normal places, including through our contact link.

Read More

Domain Assurance by Return Path

As often happens during MAAWG, email companies are announcing new products. One of the interesting ones is the new Domain Assurance product from Return Path.

Read More

HTML in email

Steve and I were talking this afternoon about HTML in email. He wanted to know what headers I looked for in the HTML portion of an email. A good question, as I’ve seen everything from a full doctype declaration through to just <body> tags.. All of them seem to render OK in various mail clients so I don’t spend too much time worrying about the specific HTML header elements. I do look for invalid tags and comments, but I check those whether they are in the header or the body.
Those of you that design HTML emails, what are your experiences with headers? Are there specific HTML headers that you always include? Do you skip the header portion of the HTML document and just use body tags? How do you test? What do you think is important?

Read More

Who's sharing data

Al has a post asking what people would do if their information was shared after opting out of any sharing.
It’s a tough call and one I think about as I see mail coming to my mailbox to such addresses as laura-sony and laura-quicken and laura-datran. All of these were addresses given to specific companies and where I attempted to opt-out of them sharing my data with other companies. Somewhere along the line, though, the addresses leaked and got into the hands of spammers.
Those addresses are overwhelmed with spams and scams. The frustrating part is there is no way to fix it. Once the addresses are leaked, they’re leaked. They will be receiving spam throughout eternity, even if the companies involved stop selling data or fix their data handling problem.
I don’t know what to do, honestly. If I think it was a one time thing, such as the addresses that started getting spam after the iContact data leak, then I’ll change my address at the vendor and retire the address the spammers have. But with other vendors, I don’t know what happened and I suspect the vendor doesn’t either, and so I can either deal with the spam or hope that I don’t lose real mail from that vendor.
There’s no easy answer. Any time you hand over an email address, or any other form of personal data, you’re trusting in the company, all of their employees and all of their vendors and partners to be honest and competent. This is often not the case.
What do you do?

Read More

The rules of delivery success

Senders with delivery problems ask about “the rules.” “Just tell us what the rules are!” “If the ISPs would just tell us what to do we’d do it!” There is only one rule anyone needs to pay attention to for good mail delivery: Respect the recipient.
Not good enough for you? Want more specific rules? OK.
The two rules everyone must follow for good mail delivery.

Read More

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More

Delivery Monitor Closing Down

Delivery Monitor by Aweber is one of the inbox monitoring services available for senders. Aweber has been in the process of winding down Delivery Monitor for the last few months and they will be turning the service off completely tomorrow.
A lot of folks have asked me about replacements for Delivery Monitor. There are, of course, Return Path and Pivotal Veracity, but many of the smaller mailers I talk to can’t justify the expenditure for either service.
Enter Green Arrow Monitor, a service provided by Green Arrow. This is a new seed list service aimed at marketers that need some delivery monitoring at commercial US ISPs. They’re reaching for the middle of the market. As a bonus, they’re offering special pricing for former Delivery Monitor customers.
While they don’t offer all the bells and whistles of other seedbox services, for the small to mid-size company that wants to know what their delivery is like at the major commercial ISPs this is a worthwhile service to investigate.
Full disclosure – I worked with GreenArrow to look at what parts of the market were being missed by other monitoring services and provide delivery consulting for some of their customers.

Read More

How to disable a domain

Sometimes you might want to make it clear that a domain isn’t valid for email.
Perhaps it’s a domain or subdomain that’s just used for infrastructure, perhaps it’s a brand-specific domain you’re only using for a website. Or perhaps you’re a target for phishing and you’ve acquired some lookalike domains, either pre-emptively or after enforcement action against a phisher, and you want to make clear that the domain isn’t legitimate for email.
There are several things to check before disabling email.
1. Are you receiving email at the domain? Is anyone else?
Check the MX records for the domain, using “host -t mx example.com” from a unix commandline, or using an online DNS tool such as xnnd.com.
If they’re pointing at a mailserver you control, check to see where that mail goes. Has anything been sent there recently?
If they’re pointing at a mailserver that isn’t yours, try and find out why.
If there are no MX records, but there is an A record for the domain then mail will be delivered there instead. Check whether that machine receives email for the domain and, if so, what it does with it.
Try sending mail to postmaster@ the domain, for instance postmaster@example.com. If you don’t get a bounce within a few minutes then that mail may be being delivered somewhere.
2. Are you sending email from the domain? Is anyone else?
You’re more likely to know whether you’re sending mail using the domain, but there’s a special case that many people forget. If there’s a server that has as it’s hostname the domain you’re trying to shut down then any system software running no that server – monitoring software, security alerts, output from cron and so on – is probably using that hostname to send mail. If so, fix that before you go any further.
3. Will you need mail sent to that domain for retrieving passwords?
If there are any services that might have been set up using an email address at the domain then you might need a working email address there to retrieve lost passwords. Having to set email back up for the domain in the future to recover a password is time consuming and annoying.
The domain registration for the domain itself is a common case, but if there’s any dns or web hosting being used for the domain, check the contact information being used there.
4. How will people contact you about the domain?
Even if you’re not using the domain for email it’s quite possible that someone may need to contact you about the domain, and odds are good they’ll want to use email. Make sure that the domain registration includes valid contact information that identifies you as the owner and allows people to contact you easily.
If you’re hosting web content using the domain, make sure there’s some way to contact you listed there. If you’re not, consider putting a minimal webpage there explaining the ownership, with a link to your main corporate website.
5. Disabling email
The easiest way to disable email for a domain is to add three DNS records for the domain. In bind format, they look like:

Read More

Confirming spam reports

Someone floated the idea of having ISPs confirm that a user really wants to report a mail as spam every time they do so. The original poster was asking for comments and what we thought of such an idea.

Read More
Tags