[SURBL-Discuss] second and third level domains - again!
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
(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 127.0.0.255
ads.msn.com IN A 127.0.0.2
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 127.0.0.255 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 127.0.0.255
co.nz IN A 127.0.0.255
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