It has been suggested that we could deal with the tripod.com subdomains by adding tripod.com to our two-level-tld list or some equivalent file. Currently the two-level-tld list is hard coded into applications to indicate that domains like co.uk should be checked at the third level, like checkmehere.co.uk. This is somewhat of a kludge, but it works.
How does anyone feel about extending that to tripod.com and potentially other hosts that provide subdomain hosting?
If so, should it be done in the same two-level-tld file or maybe a different, separate file? (Currently the two-level-tld file is mostly geographic domains, i.e. cctlds plus the local country registrar top level domains.) Or should it be done with another, separate DNSBL, etc. Both approaches have advantages and disadvantages. The file is much simpler to maintain for us, but a bit kludgey.
Conceivably the file or RBL could be used for any arbitrary number of levels, for example if subdomains like spammerz.losangeles.ca.us (unlikely example, but you get the idea) or something similar started appearing in spams.
If we make the change, we'd need to let the SURBL application authors know to update their tld file, etc., and we'd also need to update our data-side processing to allow subdomains to be listed.
Comments?
Jeff C. -- Don't harm innocent bystanders.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Chan writes:
It has been suggested that we could deal with the tripod.com subdomains by adding tripod.com to our two-level-tld list or some equivalent file. Currently the two-level-tld list is hard coded into applications to indicate that domains like co.uk should be checked at the third level, like checkmehere.co.uk. This is somewhat of a kludge, but it works.
How does anyone feel about extending that to tripod.com and potentially other hosts that provide subdomain hosting?
If so, should it be done in the same two-level-tld file or maybe a different, separate file? (Currently the two-level-tld file is mostly geographic domains, i.e. cctlds plus the local country registrar top level domains.) Or should it be done with another, separate DNSBL, etc. Both approaches have advantages and disadvantages. The file is much simpler to maintain for us, but a bit kludgey.
Conceivably the file or RBL could be used for any arbitrary number of levels, for example if subdomains like spammerz.losangeles.ca.us (unlikely example, but you get the idea) or something similar started appearing in spams.
If we make the change, we'd need to let the SURBL application authors know to update their tld file, etc., and we'd also need to update our data-side processing to allow subdomains to be listed.
I initially implemented it this way in SpamAssassin initially. ;) Also as you can see from the discussion last year in http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549 , I'm pro ;)
I think we generally agreed in that bug that we'd be open to this with various caveats.
The biggest caveat is that we're in an adversarial situation here. Isn't it likely that as soon as those are listed, the spammer will move on to using path components instead -- www.bighost.com/9fd8gdfgdflgdfig/ -- or other hosting firms?
(We can deal with the latter btw if we come up with a way to indicate to a querying app that the given domain should be looked up one level deeper, e.g. a new response code on "multi" that indicates "look one deeper for this domain".)
- --j.
-
Frank Ellermann -
Jeff Chan -
jm＠jmason.org