Discuss November 2005

discuss@lists.surbl.org

16 participants
19 discussions

How can I test SURBL is working?
by List 20 Nov '05

20 Nov '05

Hi, I have 1) [root@beyond ~]# rpm -q caching-nameserver caching-nameserver-7.3-3 2) Net::DNS is up to date. 3) /usr/bin/perl -T -w /usr/bin/spamd -L -x -u vpopmail Running on FC4 with SpamAssassin 3.10, init.pre has loadplugin Mail::SpamAssassin::Plugin::URIDNSBL How do i test SA is running with SURBL. I dont see any hit on any email since the day(6 months now) i had installed SA. Best regards

2 1

yahoo.com and ebaystatic.com in sc.surbl.org yesterday
by Giorgio 18 Nov '05

18 Nov '05

I've seen that yahoo.com and ebaystatic.com where included for a short period of time in sc.surbl.org yesterday (November 17). It seems really strange to me since this two servers are even present in the SURBL global whitelist. Ex: dig yahoo.com.multi.surbl.org ; <<>> DiG 9.2.2-P1 <<>> yahoo.com.multi.surbl.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54931 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 14, ADDITIONAL: 12 ;; QUESTION SECTION: ;yahoo.com.multi.surbl.org. IN A ;; ANSWER SECTION: yahoo.com.multi.surbl.org. 6700 IN A 127.0.0.2 ;; Query time: 23 msec ;; SERVER: xxxxxxxx#53(xxxxxxxx) ;; WHEN: Thu Nov 17 17:36:53 2005 ;; MSG SIZE rcvd: 475 Does anybody know what happened ? Thanks, Giorgio

2 2

FTC Finds Affiliates and Hosts both responsible in spam case
by Jeff Chan 18 Nov '05

18 Nov '05

This case gives CAN-SPAM some teeth to go after both affiliates and the hosts they advertise. It's also a precedent worth mentioning to those who say they have no responsibility for their affiliates. http://www.ftc.gov/opa/2005/11/globalnet.htm For Release: November 17, 2005 Spammers Barred from Violating Federal Law Operators Required to Keep Closer Eye on Affiliated E-mail Programs Spammers who sent millions of illegal e-mail messages including sexually explicit messages have paid $621,000 to settle Federal Trade Commission charges that their practices violated federal laws. The settlement will bar future violations and will require the marketers to monitor their affiliates to assure they are complying with federal laws, as well. According to the FTC complaint filed in January 2005, the defendants sold access to sexually explicit Web sites through spam. Four defendants control a network of corporations that own and operate the Web sites, payment systems, and servers used to distribute and sell sexually explicit content. One defendant was an affiliate hired to market the content from the Web sites. While the affiliate sent many of the e-mails that allegedly violated federal law, under the CAN-SPAM Act all of the defendants are responsible for the e-mails, including the defendants who paid others to send the e-mails on their behalf. [...] Jeff C. -- Don't harm innocent bystanders.

1 0

FTC Finds Affiliates and Hosts both responsible in spam case
by Jeff Chan 18 Nov '05

18 Nov '05

1 0

Re: [SURBL-Discuss] RFC: Add hosts like tripod.com to two-level-tld list?
by List Mail User 17 Nov '05

17 Nov '05

Alan, >Hi > >2005/11/16, List Mail User track-at-plectere.com |surbl list| ><...>: >> >... >> JeffC of SURBL asked: >> >> >It has been suggested that we could deal with the tripod.com >> >[snip Jeff's original message/question] >> > >> >> The hard-coding into applications is just plain wrong for a few >> reasons; Any list *should* be updatable. Some RHS BLs already support >> arbitrary subdomains (example: biz.mail.mud.yahoo.com has many more problems >> than yahoo.com or most yahoo.com subdomains). For DSN, RCVD and other >> header rules, the "top" domain, (e.g. "ca.us") may not have, or even be >> required to have an abuse and/or postmaster account (just one possible type >> of example), but the subdomains either do have them or would trigger tests >> or rules for them (a domain with no 'A' or 'MX' records may not need to >> provide any mail services, though its subdomains should and do - your >> losangeles.ca.us vs. "ca.us" example). Also note that some MTAs (eg. >> Postfix) already check *all* of the subdomains in a hostname against RHS RBLs. >> >> One problem with this is the syntax for DNS "wildcards" transcends >> subdomain levels, so I believe the files/domains should be kept separate from >> the "true" two-level TLDs, because unfortunately a check for '*.domain.tld' >> should really be performed also (e.g. '*.domain.tld' in a DNS zone file will >> match 'l5.l4.l3.domain.tld' as well as the simple 'l3.domain.tld') and this >> leads to increased overhead for DNS based net tests (without the check, the >> containing domain cannot be determined by heuristics alone). >> > >I don't fully "get" you're text, but are wildcards not an easy solution? Below, but the important point is you can not expect wildcards to be in the RHS DNSBLs themselves. > >If a domain is blacklisted it seems normal to blacklists all subdomains. >So blacklist *.domain.tld Yes, agreed; But only implicitly, not by adding (possibly unknown) subdomains into the BL itself. I mean/intend for the onus to be on the application to check. More below. > >If only a subdomain is blacklisted add *.subdomain.domain.tld but not >*.domain.tld Again, yes, agreed. The same as the previous point - i.e. they are "added" only logically from the application's point of view, not actually into the RHS DNSBL. > >*.domain.tld can be whitelisted, or it can be a central "surbl" choice >only to work with more levels for some domains. A different issue, but a good point. Probably even more valuable for ESPs with known "hammy" *.l3a.SLD.TLD cases, but where you don't want to whitelist the *.SLD.TLD case (it might be "grey" and/or other l3b.SLD.TLB cases might be spammy). > >Applications will benefit if they are rewritten to check the full >domain instead of a stripped domain. As far as I understand it those >written for the current standard will keep working like they are doing >now. One point is that there already exist applications that check the unstripped domain and all parent domains (except for possibly treating the TLD specially). This means that an application would have to check more than a single DNS entry if the FQDN has more than a single dot; What those checks should be is part of the "wildcard" issue addressed below. > >The nice part is that the applications don't need to store extra data. > >It seems so easy to me that I'm certain that I'm missing something >(stupid). I do understand that it's possible there will be less >caching from dns lookups. I don't know if wildcards are cached on the >wildcard level or with the exact supplied dns name. > At least with BIND, they are kept as the query, so if you query a wildcard (i.e. *.something), that is what is cached. It is conceivable that other DNS implementations cache keyed on the response, which may not always be the same thing. I don't know what all possible name servers do. >I hope this is clear and not to stupid. Yes, it is clear, and not stupid; I should have gone into more detail. At issue is when an application is presented with a FQDN, what is the first containing domain - for l5.l4.l3.SLD.TLD, it may not be any of l5.l4.l3.SLD.TLD, l4.l3.SLD.TLD or l3.SLD.TLD in the presence of wildcards. On the assumption (previously unstated) that you do not want to and can not cause operators to make wildcard entries in the RHS DNSBLs; So you would want to first determine in reverse order (from the SLD to the subdomains) if any wildcard entry exists in DNS to find the largest containing domain. A failure to do this could lead to a DoS by a spammer wildcarding SLD.TLD, but always using URIs of a format ln.ln_minus1.ln_minus2...SLD.TLD - in effect cause a very large number of worthless lookups which would both place load in the name servers at both ends and add/poison the cache with a large number of negative result entries; The only way I see to avoid this is to determine the first containing domain - If this behavior is adopted, there is no gain or incentive for arbitrarily large subdomain chains and the typical case will remain one lookup, but when two or more would be needed, an additional lookup for every subdomain from the SLD up would be need to check for the existence of a wildcard first (terminating if one is found), this lead to one extra lookup for the currently common case of l3.SLD.TLD, since before the lookup, we don't know if it is a simple host within the SLD or a subdomain, which may be wildcarded (and thus would never be in the blacklist). This is of course the corner case which must be checked - what we are really trying to discover is things like l4.l3.SLD.TLD where there exists an entry for *.SLD.TLD and no entry for l3.SLD.TLD, or l5.l4.l3.SLD.TLD where a *.l3.SLD.TLD exists and l3.SLD.TLD is "spammy", but SLD.TLD is not or is merely "grey", and *no* entry for l4.l3.SLD.TLD exists because it is wildcarded (e.g. the tripod-com case and many ESPs). This also implies two more lookups for the common case of l3.SLD.TLD, where the first "new" lookup is a check for the existance of *.SLD.TLD, and if that fails (though it will often succeed) a check if the string l2.SLD.TLD is a domain or a host, we we know which whether to present one or query queries to the DNSBL (i.e. two if it is a domain - seen by any SOA returned in a query - since we then want to check both the subdomain and the parent, resulting in a total of three more lookups that are done today in SA when l3.SLD.TLD is a subdomain, not merely a host, quite literally four times as many for that relatively common case, but only twice as many if a wildcard is found - common, but not universal for most spam domains). Of course, this isn't quite as bad as it sounds, since the DNS lookup for the actual FQDN are shared prior to and between all the DNSBL lookups (i.e. they only need be done once, no matter how many RHS DNSBLs are in use). Also there is no need to abandon parallelism, sine the subdomain checks can be performed while the DNSBL lookups on the SLD.TLD are done (which will always be done regardless of the outcome of the wildcard and subdomain checking); Still, there will be an increase in latency since some tests will be dependant on the results of previos DNS queries. I have continued to ignore the complications of processing any CNAMES which occur and make this yet more complex than the mess above already reads. I hope this long-winded explanation is clearer for the points which I glossed over the first time. > >Alain > >>[snip - the rest, which was apparently clear enough] Paul Shupak track(a)plectere.com

1 0

OB: whitelist required for frappr.com
by jm＠jmason.org 17 Nov '05

17 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also listed on URIBL-black, too. (I don't have an email contact addr for those guys, so I'm hoping they read SURBL discuss ;) 0.0 T_URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: frappr.com] 2.6 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: frappr.com] They're entirely hammy, so would be good candidates for general whitelisting. I don't want to attach a sample mail if poss though, for privacy reasons.... - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDfOUCMJF5cimLx9ARAsx0AKCs/rZUHjHz7pXVBDLZOk0svrsB6QCePT3F Yl/TXxG/oCw1rSzQ9ebAl9k= =sjrT -----END PGP SIGNATURE-----

5 4

Re: [SURBL-Discuss] RFC: Add hosts like tripod.com to two-level-tld list?
by List Mail User 17 Nov '05

17 Nov '05

>... JeffC of SURBL asked: >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. > The hard-coding into applications is just plain wrong for a few reasons; Any list *should* be updatable. Some RHS BLs already support arbitrary subdomains (example: biz.mail.mud.yahoo.com has many more problems than yahoo.com or most yahoo.com subdomains). For DSN, RCVD and other header rules, the "top" domain, (e.g. "ca.us") may not have, or even be required to have an abuse and/or postmaster account (just one possible type of example), but the subdomains either do have them or would trigger tests or rules for them (a domain with no 'A' or 'MX' records may not need to provide any mail services, though its subdomains should and do - your losangeles.ca.us vs. "ca.us" example). Also note that some MTAs (eg. Postfix) already check *all* of the subdomains in a hostname against RHS RBLs. One problem with this is the syntax for DNS "wildcards" transcends subdomain levels, so I believe the files/domains should be kept separate from the "true" two-level TLDs, because unfortunately a check for '*.domain.tld' should really be performed also (e.g. '*.domain.tld' in a DNS zone file will match 'l5.l4.l3.domain.tld' as well as the simple 'l3.domain.tld') and this leads to increased overhead for DNS based net tests (without the check, the containing domain cannot be determined by heuristics alone). One set of candidates that would also fall into this group include ESPs like cheetah/chtah (discussed a few months ago), where most all (or at least many) of the subdomains are well behaved, but some are definitely "mainsleaze-like" or just plain spammy (not meant to reflect on cheetah specifically here). Similarly, some poorly behaved companies are kind enough to segregate their marketing "spew" into a subdomain, allowing just that to be listed *and* tested for (think of more than just the SURBL lists - but anything SA or other apps may want to check). >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. > The use of most geographic domains in the body of spam is still rare, but I know that you have seen examples of them used for both dropboxes and domain contacts (and some geographic domains, at least in the ".us" TLD have been suspended for just this cause - directly or indirectly). >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? > The data processing changes needed for applications are the hardest ones to get done. And the concept of keeping the two sets of domains both separate (because they have different though overlapping uses) and *outside* of application code (so that they may be updated without updating the applications themselves) are both appealing . >Jeff C. >-- >Don't harm innocent bystanders. > >_______________________________________________ >Discuss mailing list >Discuss(a)lists.surbl.org >http://lists.surbl.org/mailman/listinfo/discuss > Paul Shupak track(a)plectere.com P.S. There was a citation, I believe on NANOG, a couple of weeks ago of another maintained list of multi-level TLDs for IANA listed registries - I'll try to dig it up and send it to you off-list (maybe you can compare it to the current SURBL list).

2 1

RFC: Add hosts like tripod.com to two-level-tld list?
by Jeff Chan 17 Nov '05

17 Nov '05

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.

3 2

sc2 issue (?)
by Frank Ellermann 13 Nov '05

13 Nov '05

Hi, I've manually "spamcopped" ten of these 60 minutes ago: Submitted: Sun Nov 13 00:26:03 2005 GMT : ***SPAM*** KXndigung - Mahnung 1554220718 ( http://www.wunsch-pen??.com ) To: gatekeeper(a)eastgate.net.my 1554220710 ( http://www.wunsch-pen??.com ) To: m_ghaza(a)tm.net.my (for "??" insert "is"). So far that doesn't show up in multi, is there a problem with SURBL's link to SC, or are 10 reports simply not enough ? Bye, Frank

2 2

SpamAssassin rules for Tripod
by Jeff Chan 10 Nov '05

10 Nov '05

Regarding the tripod spams, Raymond posted some SpamAssassin rules on the Users list there: body PROLO_LEO1 /85\,45|1\,21/ body PROLO_LEO2 /69\,95|3\,33/ body PROLO_LEO3 /99\,95|3\,75/ uri PROLO_LEO4 /http:\/\/.*\.tripod\.com/ meta PROLO_LEO_M1 (PROLO_LEO1 && PROLO_LEO2 && PROLO_LEO3 && PROLO_LEO4) score PROLO_LEO1 0.1 score PROLO_LEO2 0.1 score PROLO_LEO3 0.1 score PROLO_LEO4 0.1 score PROLO_LEO_M1 8 describe PROLO_LEO1 Meta Catches all Leo drug variations so far describe PROLO_LEO2 Meta Catches all Leo drug variations so far describe PROLO_LEO3 Meta Catches all Leo drug variations so far describe PROLO_LEO4 Meta to catch Leo now using Tripod describe PROLO_LEO_M1 Catches all Leo drug variations so far and he mentioned that the SARE rules would be updating to catch these also. Jeff C. -- Don't harm innocent bystanders.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss November 2005