Why This?

Filtering incoming e-mails to make the triage between ‘good’ and ‘bad’ messages has a risk – the risk of false positives, ie messages wrongly detected as being spam.

The dnswl.org data will contain information on the IP addresses of entities (companies, organisations and individuals) which are known or believed to have an efficient, effective and prompt reaction to any kind of abuse taking place in their networks and especially their (mail-) servers.

Therefore it does not make sense to subject mails from these ‘good network neighbors’ to the risk of being rejected, filtered or quarantined.

There are many ways to whitelist senders so as to make sure that they always come through:

  • Global whitelisting of addresses secured by the reverse DNS entry matching a certain pattern (example in SpamAssassin: whitelist_from_rcvd *@example.com example.com)
  • Individual mail addresses (in SpamAssassin whitelist_from jane@example.com)
  • All recipients of outgoing mail are whitelisted for incoming mails.
  • Addresses in user’s address books are whitelisted.
  • All addresses found in internal customer/partner databases are added to the whitelist.
  • Whitelist by IP address (range) of sending mailservers.

Of the above mentioned methods, we want to focus on the last one. This is efficient (in terms of network and machine load), easy to implement (similar to DNS blacklists), and easy to manage (since basically we have to store only two tokens: an IP address [-range] and a measure of how much we want to “trust”).

Abuse coming from a listed IP address?

A listing in dnswl.org is no guarantee that no cases of abuse will be detected from the listed IP addresses. However, it is believed that abusive activities will cease upon reasonably short notice to the appropriate abuse contact.

Users of dnswl.org data accept the risk of the occasional virus or spamware infected computer behind the company mailserver or similar forms of abuse because the risk of false positives from senders in dnswl.org leads to higher costs.

Receivers who wish to filter aggressively maybe do not want to use dnswl.org data.

See also the (de-)listing policy.

How is this different from other whitelisting services?

Several whitelisting services exist (eg ReturnPath or ISIPP). Contrary to those services, dnswl.org is set up to avoid conflicts of interest from a business perspective.

So far all economic approaches to “solving” the problem of spam have failed. That is no surprise, since the underlying good (namely, e-mail) has most characteristics of a public good – ie a “thing” where nobody can reasonably be excluded from using it. Think of “fresh air”.

Of course it’s theoretically to fundamentally change the way e-mail works, a world in which the exchange of e-mail is paid for by the byte, the volume or some other measurement. Think of SMS. This is not how e-mail should work.

The business model behind other whitelisting services pushes e-mail into a “paid by the byte” model. Senders pay to be included in some of the lists mentioned above. Of course, commercial providers have an incentive to enforce their policies (otherwise people would stop using them), but only potentially “bad” senders really have an incentive to pay to get on such a list.

For the typical receiver (ie you) these pay-for-whitelisting services do not help to reduce the risk of losing mail for the majority of e-mail senders (eg customers and partners). It would be counter-intuitive to require all senders to pay one (or multiple!) of the third parties mentioned above – just to let mail through.

dnswl.org tries to leverage economies of scales as a collaborative and open effort to whitelist many ‘good senders’. Instead of each and every mail admin compiling his or her own list, dnswl.org tries to be a central repository of such lists. dnswl.org data may still need to be complemented by a local whitelist, but this one can be much shorter and will thus be easier to maintain.