Thoughts on policy

laura
Industry
September 26, 2018

A particular blocklist, once again, listed a major ESP this week. Their justification is “this is our policy.” Which is true, it is their policy to list under these circumstances. That doesn’t make it a good policy, or even an effective policy. It’s simply a policy.

Crafting policies

Crafting good policy starts with the question “what is the desired outcome in this situation?” Once we know the desired outcome, then we can craft a policy that reaches that outcome. Along the way, every piece of the policy is evaluated against the desired outcome: does this get us further down the path to achieving our goal?

In many ways, identifying the final goal is the most important part of crafting policy. Those who choose the wrong goal, end up with policy that doesn’t reach that goal. There are some really clear examples of that in the email space. Picking the wrong goal results in policy that meets the goal, but doesn’t necessarily do what the creators intended.

Blocklist policy

The blocklist currently listing most, if not all, of the IPs belonging to at least 2 major ESPs has a policy to increase listings based on a numerical formula. If a certain percentage of IPs in a range are hitting spamtraps, then the listing is escalated, until they list all the IPs under a ASN. This is quite aggressive listing policy. The blocklist documentation even clearly states this will block wanted mail.

This type of policy is designed to bring heavy amounts of pressure on network owners to aggressively remove spammers from their network. The problem is that because the escalations are so aggressive and because the aggressiveness blocks so much wanted mail, larger networks don’t use the list. Since the list isn’t used, there is very little pressure on any IP owner to clean up their customer base.

Compare that with a different blocklist. This blocklist doesn’t have an aggressive escalation policy. They will escalate in some cases, but in general their listings are quite conservative. They even list some IPs that don’t send mail, as a warning to the IP owner that there is some problem. Despite being less aggressive, this blocklist is much more effective at changing behaviour. Why? Because this list is widely used.

Unexpected consequences

In order for a blocklist to be effective, it needs to actually affect mail delivery. The reason the less aggressive list is more effective is due to its wider use. There isn’t a lot of persuasion in a list that blocks mail to one or two subscribers at an obscure ISP. Those two subscribers may be annoyed at their inability to receive a particular mail, but they can simply move a particular subscription to a different email address. On the other hand a list that’s used by major webmail providers and incorporated into numerous filters will have a significant impact on sender behaviour, even if that’s not their policy goals.

Policy should not be fixed

Simply having a policy isn’t enough. There have to be processes for when the policy is broken. Processes include when and how to undertake an investigation and then how to address the problem once the investigation is finished. Policies are not worth the paper they’re written on without effective enforcement.

Good policy enforcement is, in most cases, pretty simple. But inevitably policy violations arise that challenge current processes to handle in a way that further the policy goals. There are two primary ways organisations handle this. The first is to fall back on “it’s policy” and “this is what happens.” Even when the outcome is unfair or doesn’t further the underlying policy goals there is no room for discussion or modification to the policy. The second case is more fluid. Policy is not fixed and immovable. Instead, the underlying goal is fixed and immovable, and processes are changed to meet the policy goals. Of course, you don’t want to be modifying policies all the time, but when a process is inadequate to address a situation, modification should be on the table.

In the case of the aggressive blocklist, their current policies and processes are not, from an outside perspective, meeting their stated goals. Because their listing process is so aggressive and because they block mail people want to receive, the list is not widely used. Since it’s not widely used, being listed is meaningless. Companies aren’t making changes in order to get delisted because there’s no need. I’m sure they know this, but have chosen not to modify their policies.

There are a lot of challenges to crafting effective policies and processes around those policies. Over the next few months I’ll be writing more about how to think about policies and processes that surround them.

Questions about Spamhaus

I have gotten a lot of questions about Spamhaus since I’ve been talking about them on the blog and on various mailing lists. Those questions can be condensed and summed up into a single thought.

How many blocklists do we need?

There’s been a discussion on the mailop list about the number of different blocklists out there. There are discussions about whether we need so many lists, and how difficult the different lists make it to run a small mail system (80K or so users). This discussion wandered around a little bit, but started me thinking about how we got to a place where there are hundreds of different blocklists, and why we need them.

There is a lot of history of blocklists, and it’s long, complicated and involves many strong and passionate personalities. Some of that history is quite personal to me. Not only do I remember email before spam, I was one of MAPS’ first few employees, albeit not handling listings. I’ve talked with folks creating lists, I’ve argued with folks running lists. For a while I was the voice behind a blocklist’s phone number.
The need, desire and demand for different lists has come up over the years. The answer is pretty simple: there are many different types of abuse. One list cannot effectively address all abusive traffic nor have policies that minimize false positives.
Lists need different policies and different delisting criteria. The SBL lists based on volume of email to addresses that are known to have not opted in to receive mail. The PBL lists IPs where the IP owner (usually an ISP) says that the IPs are not supposed to be sending mail by their policy. URIBL and SURBL list domains, not IPs. Some lists have delisting requirements, some let listees remove themselves.
The policies of listing and delisting are not one size fits all, nor should they be.
There are two widely used lists that have significantly different delisting policies: the SBL and the CBL.
The SBL focuses on IP addresses they believe are under the control of or supporting the services of spammers. They measure this by primarily relying on spamtraps, but they also accept forwarded mail from some trusted individuals. Getting delisted from the SBL means explaining to Spamhaus what steps were taken to stop the spam from coming. It’s a manual process with humans in the loop and can require significant business process changes for listees. (We’ve helped dozens of companies resolve SBL listings over the years, contact us if you need help.)
On the other hand, the CBL is a mostly automated list. It lists ources of mail that aren’t real mail servers sending real mail, but are sending a lot of stuff. As they describe it:

Arguing against the anti-spam policy

Not long ago I was talking with a colleague who works for an ESP. She was telling me about this new client who is in the process of negotiating a contract. Normally she doesn’t get involved in negotiations, but the sales group brought her. It seems this new client is attempting to remove all mention of the anti-spam policy from the contract. As she is the deliverability and compliance person, the sales people won’t agree unless compliance does.
Her sales team needs props for bringing her in to negotiate a contract where the anti-spam clause is removed.
This isn’t that unusual situation. Many well managed ESPs will include deliverability and compliance personnel in negotiations if the customer indicates they want changes to the language of the anti spam clause.
On the face of thing it seems reasonable for customers to want to negotiate compliance terms. They want to protect themselves from unexpected outages. It seems irresponsible to allow a service provider to have the ability to made such a business affecting decision.
Many folks try to negotiate their way out of anti-spam clauses. Just asking for changes isn’t a big deal. However, some companies push the issue with sales and contract folks to an extreme. They threaten to not sign if the anti-spam clauses are removed completely.
Threatening a contract over compliance issues can poison an entire working relationship. The fact is that most people who argue about anti-spam clauses and compliance issues are people who have had problems with other ESPs in the past. For better or worse, prospects that try and remove anti-spam clauses from contracts are often problem customers.
On the compliance side, if someone is pushing hard to get the spam clause removed, they think a few different things: