Recent Posts

I need IP addresses for reputation

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

Canadian Law

A anti-spam bill was passed out of committee Monday in Canada. Other than chatting over drinks with a large contingent of Canadians, I haven’t followed the story too closely. However, Matt V. has a detailed summary of the bill at EmailKarma.
Have a great weekend.

A blast from the past

I’m sitting here watching Iron Chef (the real one, not the American version) and surfing around on SFGate.com. It’s a slow night catching up on all the news I’ve missed this week while off traveling. I see a link on the front page: “Web marketer ordered to pay Facebook $711M.” As I click I wonder if I know the web marketer in question. A former client? A name I recognize?

Problems at Cox: Resolved

People mailing to Cox in the wee hours of this morning may have received a rejection message citing the Invaluement DNSBL.
554 IMP a.b.c.d blocked. IPBL100 – Refer to Error Codes section at http://postmaster.cox.net for more information.
I spoke with one of the folks at Cox and they said there was an error in the implementation causing non-listed IPs to be rejected erroneously between about 4am to 8am (Eastern) this morning. The problem has been resolved as of 8am, and all traffic is flowing normally. The also stated that attempts to resend any blocked messages will succeed. They do apologize for any problems this may have caused.
For those of you with aggressive bounce handling, removing addresses after a single 550 bounce, you will also want to re-enable any cox.net subscribers that bounced off during this configuration problem.

Why do you need so many IP addresses (part 2)?

In my last post I discussed the background as to why an ISP will require their users to use their IP address allocation efficiently. I also mentioned in passing that I’d discussed ESP address allocation with both ESPs and ISPs recently.
The ESP was talking about assigning a couple of dozen IP addresses to each customer, because they might be useful for spreading load and it would provide some flexibility for moving from one IP address to another if one should get blocked. And IP addresses are pretty much free. They were wrong.
The ISP was considering an application for 750 IP addresses from a new ESP customer. They assumed that there was no possible reason other than snowshoe spam for an email related customer to need that many IP addresses. While I suspect they may have been right about the specific potential customer, the general assumption was wrong.
I’ve seen a lot of reasons given by ESPs for why they need so many IP addresses:

Why do you need so many IP addresses?

IP addresses aren’t an unlimited resource, not on the current version of the Internet anyway. There are only a limited number of them and, while some of the doom and gloom proclamations about us running out in the next year or two may be exaggerated, we are running low on them and should be conserving them where we can.
An ISP can’t create new IP addresses from whole cloth. Instead, when they need more IP addresses they must petition one of the regional internet registries (RIRs) for a new set of addresses which they can then parcel out to their customers. There’s a RIR for each part of the world. ARIN distributes IP addresses for use in North America, RIPE handles IP addresses for Europe, APNIC handles them for the Asia-Pacific region and LACNIC for Latin America.
Each RIR enforces a fairly complex set of rules on the ISPs to ensure that the distribution of IP addresses is somewhat fair and reasonably parsimonious. The rules vary slightly from RIR to RIR in the details, but are fairly consistent in the general meaning. Unless you’re petitioning your local RIR for your own chunk of addresses for some reason (which you aren’t, unless you have a genuine need for more than 2000 IP addresses, or a legitimate need for more than 500 addresses and a complex redundant network setup) you only need to care about the rules that each RIR asks the ISP to enforce on their customers.
When an ISP asks, for example, ARIN for a new block of IP addresses they may be asked to demonstrate efficient usage of the IP addresses they’ve received previously. If they can’t do that, they may not be able to get the new IP addresses. This is, obviously, a Big Deal so ISP network engineers do their best to use address space efficiently, and try and stop their sales reps from handing address space out like candy at Halloween. The end result is that an ISP really does need to have you justify your IP usage – they’re not just being mean or trying to gouge you for more money.
There are several rules that an ISP might follow. One is that an initial allocation of more than, perhaps, 16 addresses will need some justification of how a quarter of those will be efficiently used immediately and how half of them will be used within six months. Another is that if you’re asking for additional IP addresses you’ll need to demonstrate that you’re efficiently using perhaps 80% of the addresses you’ve been assigned previously. The details may vary, and you can probably negotiate with the ISP, but eventually the ISP will need to justify themselves to ARIN, so they’re going to enforce something like this on their customers – or make you pay through the nose to cover the risks they take by bending the rules.
So what does efficient usage mean? That’s very simple in some cases, fuzzier in others. If you have 50 physical machines providing services on the internet, that’s a good justification for 50 IP addresses. If you’re providing internet access to end users (cable modems, DSL, dial-up) then one IP address per user is easy to justify. Virtual webhosting doesn’t justify one IP address per user, but virtual webhosting using SSL does. This is one of those rare cases where you really do have to explain your business model, showing that you’re making efficient use of the addresses you have, and that you have some room for expected growth but aren’t wasting address space by leaving too many addresses idle.
How about ESPs and other bulk mail senders – what does efficient address space usage mean for them? That’s something that seems, from recent conversations I’ve had, to be poorly understood by either ISPs or ESPs. And it’s fairly complex, that’s for sure. So I’ll save that for my next post.

Dealing with blacklists

Al has a good post listing the top 5 things senders should remember when dealing with blacklists.
One of the critical things to remember about blocklists is that they are an early warning sign. Sure, some of them are one crank and his cat and will not hurt your overall delivery. A sender may be listed for totally spurious reasons . On the other hand, many of the widely used public lists and the private lists at the big ISPs, list IPs that they see as doing something wrong.
The challenge for anyone listed on any IP based blocklist is to look inside and determine what it is that they’re doing that caused the listing. The first step is to look at the technical issues, does your mail look like something coming out of infected bots? Is there a configuration problem? If the answer is no, then senders have to look at their practices. Are they sending mail to people who don’t expect it? Are they sending mail to people who didn’t ask for it? Most listings that will affect large numbers of recipients fall into the above 2 categories: technical or practices.
Technical problems can be fixed easily, once they’re identified. Permission or practice problems can also be fixed, but may require a sender reassess how they are using email and what value email brings to the business.

How NOT to get your mail unblocked

My friend Barry™ contacted me earlier this week to rant about senders contacting him asking for blocks to be lifted.

They are all Barry. Listen to Barry

Al has a guest post up from an ISP rep (now universally referred to as Barry) about senders contacting ISPs. It lists things senders do that Barry Don’t Like.
Listen to Barry.
There are also comments from various other Barrys in the comments. Those are worth reading, too.

Matt Blumberg joins the DMA Board

Matt Blumberg, CEO of ReturnPath, announced on his blog today that he has joined the board of the DMA. The blog post is both an explanation of why he did it and an agenda for what he wants to accomplish.