At the risk of boring those here for whom this issue may not be so important, I have decided to post again on the desirability (no, necessity) of a whitelisting feature to balance the DNSBL support in ND6.
My own recent experience, along with some recent posts in this forum (e.g. ) suggest a real need in the ND6 user community for this enhancement to the DNSBL feature of ND6.
Executive Summary
To save you reading to the end unless so inclined the main points are:
A means is required to eliminate “false positives” on DNSBL look-ups.
In most organisations, 80% of wanted email comes from less than 20% of the hosts from which mail is accepted. Therefore a small white list saves a great deal of DNS look-up activity. This is a significant performance enhancement opportunity.
No acceptable workaround to the Domino whitelist issue exists.
This author contends that a simple white list implemented in the native Domino SMTP listener would provide an effective means of:
reducing collateral damage
improving mail delivery performance
protecting the security of the ND6 user organisation
If you agree with me, please post a response to this thread. Post a response anyway - we need this debate.
Chris Linfoot
The Detail
What would this feature look like?
Doesn’t look so difficult to me…
Why do we need it?
- Spam is increasing.
Half of all e-mails are spam
Block listing is the only way to defeat spam at the protocol level, hence avoid bandwidth, storage and related resource theft. The use of block listing is increasingly widespread as is the use of increasingly aggressive lists. E.g:
Spamcop - recommends that mail is tagged but not blocked. Many people who post here do block based on Spamcop with very good results, but inevitably some non-spam email is rejected. The alternative of tagging instead of blocking applies in the current releases of ND6 to all black lists used and defeats one of the main benefits of DNSBL - keeping out the bad guys.
SPEWS - deliberately sets out to cause collateral damage. The philosophy (with which I happen to agree) is that ISPs are either part of the problem or part of the solution. Those that are part of the problem find increasingly large chunks of their network listed so that eventually non-spamming customers feel the pain. These customers then either complain sufficiently to persuade the ISP of the error of his ways, or they move to a less spam friendly ISP. This does mean that innocent bystanders are hurt (so far, only two at the author’s site), and we need to be able to help them during the time their IPs are listed (until they change ISP or their ISP cleans up his act).
Whitelisting provides a means of mitigating collateral damage without dropping the use of Spamcop, SPEWS (or any other particularly strong list) and without having to accept and tag all spam, then clean up the mess later.
- The use of DNSBL look-ups on every connection by any IP to deliver mail is redundant.
Having run a detailed analysis of email received here over the past five months, I have a strong evidence base to support this.
We are a medium sized enterprise in the manufacturing (automotive) sector in the UK. We have c. 350 Notes users and accept c. 600 Internet emails per day (currently blocking another c. 400 per day).
Since Jan 23rd 2003, a total of 541 different hosts have successfully delivered mail here (a far greater number have been refused, mainly by DNSBLs).
80% of accepted messages came from 16% of these hosts and virtually all of these 16% are hosts we would wish to white list. I contend that most companies similarly receive the majority of their email from a small number of sources.
Once trusted, do we really need to check these against block lists every time? I believe that this is unnecessary and that a whitelist would save perhaps 40-50% of all DNSBL look-up activity on an ND6 host, greatly enhancing the speed and reliability of email delivery from “trusted” sources.
- The only workarounds devised so far fail in the areas of
scalability (whitelisting more than a couple of IPs become onerous)
reliability (not all “blacklisted” hosts may be blocked)
security (“whitelisted” hosts can create a multi stage open relay condition ) - anyone here that thinks this vulnerability would not be discovered and abused can read this or spend a few minutes on Google finding anecdotes like this one)
I have had to resort to techniques like these a few times recently and it doesn’t help me to sleep at night, knowing what problems I have potentially given myself.
A while ago, I posted a request for the whitelist feature in the ND6.5 beta forum. This met with a smattering of agreement. Indeed my earlier posts in this forum have generally done the same, but no-one at IBM/Lotus seems interested in making any comment.
Time for that to change.
Chris Linfoot
A lot of the ideas above have been the reason for developing MIMEShield. MIMEShield has been in development for over a year now and works extremely well in the Enterprise Domino environment. If you are looking for a better solution than what is currently built into R6 then I believe MIMEShield is the answer.