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 removed.)
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 listing.
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 domain.
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).
John