Tuesday, 11. November 2003

Primus inter pares? (developing a strategy for whitelisting)
OK. That means "first among equals" for non classicists and is a phrase generally used to describe the Prime Minister in the British system of cabinet government (though the extent to which the concept applies in recent times is moot). However, for my purposes, I wish to apply the concept to (of all things) IP addresses. Bear with me.
The Internet is essentially a network of peers. All IP addresses are created equal (but are some more equal than others?), and the question is how we can determine which of the many IP addresses we encounter during email transmission are primus inter pares.
Stoomaroo poses an interesting question which I will not repeat in full here, but which touches this issue...
If we were to embark on a mission to blacklist
without a great deal of care, then use whitelists to mitigate the damage, then it is clear that the point being made is pertinent. If we simply blacklist IPv4, then whitelist hosts we know we want mail from, the logical end point of such a strategy, then we effectively block one time users who may be potential customers and none of us wants
that. (Aside: you can do this with vanilla functionality in Domino anyway; you don't need a whitelist feature).
In order to make a sensible combination of black and white lists work for us, we must first spend some time understanding the demography of spammers and of our customers, and propose a mechanism to distinguish them. This will permit broader,
strategic use of blacklisting, with whitelists simply used as fine tuning.
- Example 1: Most of our spam comes from dynamically assigned IP addresses belonging to ISPs providing DSL or cable services to home users. The very home users who may be our potential customers. But consider this. Most of these people are not running MTAs on their DSL connections; they are running an MUA - usually Outlook Express or some such. These users do not expect to send email direct-to-MX, but via a smarthost operated by their ISP. We do in fact block all email coming from dynamically assigned addresses for this reason, but...
A very small number of people do run MTAs on their DSL connections and do send direct-to-MX. Mostly their ISPs permit this (though some should probably go and re-read their ISPs' AUPs). So, how can we distinguish these from the virus/proxy infested hordes of DSL connected computers out there and accept their mail?
I have a case here at the moment. A certain very large supplier of broadband/ADSL service in the UK permits the use of MTAs on their lines and perhaps 99+% of their customers do not take up this option. One of our resellers does, using an IP address that is semi permanently allocated (though still technically dynamic), but sits bang in the middle of a block of addresses which we block locally, and which are in any case widely blocked by DNSBLs. I want to accept this reseller's email (and the same for perhaps a handful of others). A whitelisting policy for this ISP would thus be:
- Block all dynamic pools belonging to this ISP. Whitelist the individual IP addresses used by my handful of business users.
We can't do this, because we have no whitelist, so have blocked the entire dynamic pool (because this ISP's spam problem is so massive), and thus cannot accept email directly from our reseller. So we have had to make alternative arrangements for electronic communications with him.
- Example 2: Here, a very large proportion of our un-blocked spam now comes from Korea. We have no customers in Korea. So why not just block Korea? Well because we do have suppliers there. A whitelisting policy for Korea would thus be:
We can't do this so we have to accept all email from Korea and rely on filtering or user reporting to weed out the spam, c. 75-80% of all email from Korea.
And finally. If you look again at what I wrote the other day about whitelisting, you will see that I specifically did not advocate setting a blindly aggressive blacklisting policy and not managing it at all. I do expect to need to manage the blacklists in the future, when we do have a whitelist. But this task is made a great deal easier by the availability of a whitelist. If we spend the time during whitelist set-up to list pre-emptively hosts that we know we always want mail from then email delivery becomes generally more reliable too.
And whitelisting looks like a real possibility now, even if IBM/Lotus fail to deliver one in the Domino MTA, because Raymond Neeves' Intercept now appears to offer virtually all of the features needed. Just testing that now. Will report back here when testing is complete.
Category: Whitelisting
Technorati: Whitelisting