[SURBL-Discuss] second and third level domains - again!

John Fawcett johnml at michaweb.net
Sun Apr 25 18:57:56 CEST 2004

One of the things I noticed after upgrading to 
SpamCopURI 0.14 was that previously I had
been identifying all mail containing ads.msn.com
as spam and after the upgrade this was no
longer happening.

(BTW ads.msn.com was still listed in sc.surbl.org
when I observed this behaviour. It has since been

Version 0.14 includes the changes which were 
being discussed last week, so that if ads.msn.com
is found in an email only msn.com is being
checked against sc.surbl.org.

So the choices available to the list maintainer are either:
- list all of msn.com
- list none of msn.com

Since listing all of msn.com is likely to be too wide, 
this means msn.com will not get listed even if
there are subdomains which are candidates for 

I've used msn as an example, but the same logic
applies to any of the big names like yahoo etc where 
the list maintainer may want to have more granularity
in what is listed rather than list the whole registered 

The solution could be to use a special return code
which indicates "query again with more detail".
(I remember someone bringing up something similar
in the context of ccTLDs as well).

So if ads.msn.com were to be listed in sc.surbl.org
it would need two records:

msn.com IN A
ads.msn.com IN A

The client (in this case SpamCopURI) would
find a url ads.msn.com in the email but would
query for msn.com as per the current logic.

The return value of then indicates
to the client to query for one level 
lower, ie ads.msn.com.

This same mechanism could be used for ccTLDs.
sc.surbl.org could contain:

co.uk IN A
co.nz IN A

So that if I get xxxxxxxx.co.uk in an email, 
the client queries for co.uk and it will be told 
to query with the lower level. The client
queries for xxxxxxxx.co.uk

The disadvantage of this solution is that it needs
a changed logic on the client side, however the
client does not need to know anything about
which ccTLDs have two or three level domains.
The extra query overhead is minimal, since
on a busy server these additional records would
almost always be in the DNS resolver cache.

Even clients which don't implement this extra 
logic would however have to be careful to check
the value of the A record rather than deduce the 
listing from the presence of an A record.

Maybe we're still in time to make changes
like this before there is too much software 
to change (currently I think there are 3).


More information about the Discuss mailing list