- Discuss - Mailman 3

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. uribl-discuss(a)lists.maddoc.net Jeff C. -- Don't harm innocent bystanders.

1 0

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

18 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 18 Nov '05

18 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 18 Nov '05

18 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 14 Nov '05

14 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 11 Nov '05

11 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

Re: [SURBL-Discuss] Re: tripod dot com
by List Mail User 10 Nov '05

10 Nov '05

>... >On Tuesday, November 8, 2005, 11:55:36 AM, Dhawal Doshy wrote: >> Catherine Hampton writes: > >>>> Thanks Jeff, i'll continue doing the spamcop reporting. If only there >>>> was some way for mass submission (i have a list of 177 sub-domains if >>>> anyone is interested). >>> >>> <raising hand> >>> >>> Please email the list to updates(a)spambouncer.org and I'll list them >>> in the Spam Haven URLs list. Thanks! > >> http://mx2.netmagicians.com/tripod.txt, just mailed them to the support team >> at lycos.com as well who will remove the offending accounts. > >Please do report them to lycos. Getting the sites shut down is >arguably more important than blacklisting, IMO. > >Jeff C. >-- >Don't harm innocent bystanders. > >_______________________________________________ >Discuss mailing list >Discuss(a)lists.surbl.org >http://lists.surbl.org/mailman/listinfo/discuss > Reporting the tripod sites to Lycos and shutting them is indeed more important than blacklisting the tripod sites - Agreed. But a quick extract of the HTML pages shows that the 179 tripod pages seem to only redirect to a total of 8 sites currently - those should get blacklisted. The current set is (not the same as the ones I saw earlier): Site Registrar Contact email -------------------------------------------------------------------------------- http://www.aneigpie.com-MUNG - NameBay caturedin(a)yahoo.com http://www.arecurel.com-MUNG - NameBay livoutsid(a)yahoo.com http://www.baniclu.com-MUNG - NameBay caturedin(a)yahoo.com http://www.cherdon.info-MUNG - Directi tospecie(a)yahoo.com http://www.cherit.info-MUNG - Directi tospecie(a)yahoo.com http://www.chersky.info-MUNG - Directi tospecie(a)yahoo.com http://www.offmantate.com-MUNG - YesNIC greatestemal(a)yahoo.com http://www.onlialowus.com-MUNG - YesNIC greatestemal(a)yahoo.com All currently have a 5 minute TTL and are at IP 211.233.16.84, which is listed at Spamhaus under SBL31414, a general dirty block at KIDC, though the example domains in the SBL include Kurayev's name servers registered by the ex-Joker (now Nicline) ROKSO domain reseller "Alex Blood"/"Ryan Kelly". All use the same name servers: ns0.areshooti.com-MUNG - YesNIC revisitinger(a)yahoo.com ns0.stomauset.com-MUNG - YesNIC omeceral(a)yahoo.com Of course the YesNIC name servers, have no name servers themselves. Paul Shupak track(a)plectere.com

5 4

Re: [SURBL-Discuss] Re: tripod dot com
by List Mail User 09 Nov '05

09 Nov '05

>... >On Tuesday, November 8, 2005, 10:08:46 PM, List User wrote: >> a quick >> extract of the HTML pages shows that the 179 tripod pages seem to only >> redirect to a total of 8 sites currently - those should get blacklisted. >> The current set is (not the same as the ones I saw earlier): > >> Site Registrar Contact email >> -------------------------------------------------------------------------------- >> http://www.aneigpie.com-MUNG - NameBay caturedin(a)yahoo.com >> http://www.arecurel.com-MUNG - NameBay livoutsid(a)yahoo.com >> http://www.baniclu.com-MUNG - NameBay caturedin(a)yahoo.com >> http://www.cherdon.info-MUNG - Directi tospecie(a)yahoo.com >> http://www.cherit.info-MUNG - Directi tospecie(a)yahoo.com >> http://www.chersky.info-MUNG - Directi tospecie(a)yahoo.com >> http://www.offmantate.com-MUNG - YesNIC greatestemal(a)yahoo.com >> http://www.onlialowus.com-MUNG - YesNIC greatestemal(a)yahoo.com > >> All currently have a 5 minute TTL and are at IP 211.233.16.84, which is >> listed at Spamhaus under SBL31414, a general dirty block at KIDC, though >> the example domains in the SBL include Kurayev's name servers registered >> by the ex-Joker (now Nicline) ROKSO domain reseller "Alex Blood"/"Ryan Kelly". > >Hi Paul, >Thanks I've blacklisted those, but TBH it may not help too much >since they don't seem to be appearing in spams themselves. > >Keep on getting those domains shut down. :-) > >Jeff C. >-- >Don't harm innocent bystanders. > >_______________________________________________ >Discuss mailing list >Discuss(a)lists.surbl.org >http://lists.surbl.org/mailman/listinfo/discuss > I didn't even notice, but the tripod subdomains got their own SBL yesterday - SBL34478 for dafhicksha.tripod.com-MUNG redirecting to arecurel.com-MUNG, but at a different IP, 222.122.72.120 (at KORNET instead of KIDC - same country, different spam haven). Chances are that the IPs 211.233.16.107 and 221.143.42.212 were either earlier sites, or soon to be used sites (there are 4 'A' records for the each of the name servers - with 5 minute TTLs its is hard to tell which direction things are moving, to or from, without staying on top on them and checking). Similar SBLs include SBL34456/SBL34454 for 211.233.16.78 and 211.233.16.107 respectively - though those show the domain conumese.com of SBL34454, which was spam'd directly (i.e. not tripod'd) and a batch of other directly spam'd domains at the same IP 211.233.16.107. There, at least the domain doubelev.com-MUNG was using ascii and multi-character HTML table formated spam: -------------------------------------------------------------------------------- [headers - snipped] Content-Transfer-Encoding: quoted-printable Ho overpayi or your Meddi isit our Pharm ress Sho wdy, Quit ng f cations - v aExp p. AmCIXaVALeVI bienALISnaxLIUMvitraAGRA 3.70 1.20 3.30 Want to know more? - http://hardselleex.doubelev.com-MUNG ------=_NextPart_000_004A_01C5E293.A074B480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [HMTL - snipped] -------------------------------------------------------------------------------- So there are many parallel drug spams hosted and advertising the same site(s) at once (my copy of the spam is from Sunday early morning). The one above is using the more common three-registrar system; Spam domain at Namebay, name server rosettarkin.com-MUNG at RGNames and nearly identical name server indivualre.com-MUNG at YesNIC (the name servers use the same contact data, except the email, at both registrars). Paul Shupak track(a)plectere.com

1 0

tripod dot com
by Dhawal Doshy 08 Nov '05

08 Nov '05

Hi, tripod dot com is now the new geo-cities, any plans to list it (yup, i know about the surbl no fps policy but no harm in asking)? i currently don't see it whitelisted (unless i'm wrong). We are getting quite a few spams from there. e.g. labedbreashi dot tripod dot com which redirects to filiaprom dot com thanks, - dhawal

5 11

Re: [SURBL-Discuss] tripod dot com
by List Mail User 08 Nov '05

08 Nov '05

>... >On Tuesday, November 8, 2005, 5:12:52 AM, List User wrote: >> So, Jeff, can the tripod.com domain just be treated as if it >> were a two-level TLD for SURBL? Another pair are ianampolkcho tripod.com >> and armonmafinneywilco tripod.com (Yes, they have been reported). > >For those keeping score, the systems are not currently set up to >work that way, both on the data side and probably also on the >application side. I'm not sure how smart we are to let the >spammers know this. :-( > >> BTW. He's also using the CNET redirector again (clearly CNET's >> policy of blacklisting instead of whitelisting doesn't work). > >Perhaps you mean whitelisting instead of blacklisting? > >Jeff C. >-- >Don't harm innocent bystanders. > >_______________________________________________ >Discuss mailing list >Discuss(a)lists.surbl.org >http://lists.surbl.org/mailman/listinfo/discuss > Unfortunately I meant it the way I wrote it; CNET blacklists sites *after* complaints - They should whitelist sites that have paid or contracted with them instead of blacklisting sites people complain about. You assumed that they were acting rationally, which should be a good assumption, but isn't in this case. However I did mean to use redirectors (plural, not singular - they have many in their various domains). Paul Shupak track(a)plectere.com

2 1

Re: [SURBL-Discuss] tripod dot com
by List Mail User 08 Nov '05

08 Nov '05

These are the latest versions of Leo Kuvayev's pill spam which does still come from many XX.geocities domains (recent ones from de and sg). An interesting twist to the newest stuff - the spam domains are at bookmyname and Namebay, but the name servers are at RGNames and YesNIC; Of particular interest is the ones at YesNIC have no name servers, just hosts in the root cache (e.g. filiaprom dot com, uses stomauset dot com and areshooti dot com), and YesNIC's standard procedure for "suspending" a domain is to remove its name servers - so this technique allows the domains to continue to be used long after they have been suspended (look up the various Spamhaus listings for the CP name server set in the domain serverbackup64 dot com - which was "suspended" Sept. 29, but is still getting new SBL listing mentions - e.g. SBL34264). A similar trick is used for the RGNames domains, where he buys a domain package including DNS from them, but never allows the RGNames' servers (i.e. pf[12].rgpack.com) to receive or serve and data for the domains. The most common case seems to be the spamvertised domain at bookmyname or Namebay with two name servers, one each at RGNames and YesNIC, with identical contact data, except for different email addresses (i.e. same name for the registrant and contacts, partial address at YesNIC and full address at RGNames). The actual spam is the identical vertical pill stuff (not currently using HTML tables) and the various ED drug spams. So, Jeff, can the tripod.com domain just be treated as if it were a two-level TLD for SURBL? Another pair are ianampolkcho tripod.com and armonmafinneywilco tripod.com (Yes, they have been reported). BTW. He's also using the CNET redirector again (clearly CNET's policy of blacklisting instead of whitelisting doesn't work). Paul Shupak track(a)plectere.com

2 1

Please remove SC2 rules or references
by Jeff Chan 04 Nov '05

04 Nov '05

Anyone using custom rules for sc2.surbl.org, please take them out now, since sc.surbl.org is using that data. Jeff C. -- Don't harm innocent bystanders.

1 0

okay to talk about sorbs here?
by George Georgalis 02 Nov '05

02 Nov '05

Before I started using spam.dnsbl.sorbs.net I tested a corpus of spam and ham and determined the best way to implement. But in the past 48 hours, mail relays from road runner, and cablevision have been added. http://www.us.sorbs.net/using.shtml spam.dnsbl.sorbs.net - List of hosts that have been noted as sending spam/UCE/UBE to the admins of SORBS. This zone also contains netblocks of spam supporting service providers, including those who provide websites, DNS or drop boxes for a spammer. Spam supporters are added on a 'third strike and you are out' basis, where the third spam will cause the supporter to be added to the list. While I appreciate sending the message to lame ISPs about controlling their users, adding these relays to the blacklist causes a lot of false positives. Has sorbs been reasonable in their judgment to add them, how often does it take 30 million (or whatever) random subscribers to produce 3 spams, and what is reasonable for an ISP to do about it? I have filled out their (sorbs) complex web support forms before, on behalf of a 3rd party, and never got a response. Now, since I'm complaining about relays being added that aren't mine, I cannot even get through the questions to a dialog I can enter my observation (when I properly answer the questions). Unfortunately for me this is 2 strikes and you're out, sorbs. Is there a good alternative for spam.dnsbl.sorbs.net? // George -- George Georgalis, systems architect, administrator <IXOYE>< http://galis.org/ cell:646-331-2027 mailto:george@galis.org

4 6

Re: RFC: multi.surbl.org testpoint A record value
by Frank Ellermann 02 Nov '05

02 Nov '05

Jeff Chan wrote: > Does anyone have any comments or preferences for either > style? Why set bit 7 if there is no 7th set at the moment ? It would be nice in my test output. OTOH I added support for bits 8..15 a year ago because that's what you wanted, and for that you could also use 127.0.255.126. === test output today (truncated) === 127.0.0.2 (------1-): .ix.dnsbl.manitu.net 127.0.0.2 (------10): .combined.njabl.org 127.0.0.2 (---43210): .opm.blitzed.org 127.0.0.2 (------1-): .multi.surbl.org 127.0.0.2 (-----21-): .sbl-xbl.spamhaus.org === demo output for 127.0.0.126 === 127.0.0.2 (------1-): .ix.dnsbl.manitu.net 127.0.0.2 (------10): .combined.njabl.org 127.0.0.2 (---43210): .opm.blitzed.org 127.0.0.2 (7654321-): .multi.surbl.org 127.0.0.2 (-----21-): .sbl-xbl.spamhaus.org === demo output for 127.0.255.126 === 127.0.0.2 (------1-): .ix.dnsbl.manitu.net 127.0.0.2 (------10): .combined.njabl.org 127.0.0.2 (---43210): .opm.blitzed.org 127.0.0.2 (FEDBCA987654321-): .multi.surbl.org 127.0.0.2 (-----21-): .sbl-xbl.spamhaus.org These "aesthetical considerations" are just for fun, if there are no more serious arguments at all. Bye

2 2

RFC: multi.surbl.org testpoint A record value
by Jeff Chan 02 Nov '05

02 Nov '05

Previously, each SURBL zone file, including the bitmask combined list multi.surbl.org, had testpoitns with A records resolving to 127.0.0.2. That was a design decision, and it was also convenient to the way the zone files were generated before. But Justin Mason or one of the other SpamAssassin developers argued that multi should have testpoints corresponding to all ones in each bitmask position. So one of the changes with the new SURBL engine now running is that the multi testpionts do have all the bits set for an A record value of 127.0.0.126 instead of 127.0.0.2 . This may work better with applications that decode the bits properly into individual list results, but it is a change from before and it may break other applications' use of the testpoints. Does anyone have any comments or preferences for either style? Jeff C. -- Don't harm innocent bystanders.

1 0

New engine, sc2 ready
by Jeff Chan 29 Oct '05

29 Oct '05

After everyone's help testing the revised SC2 data and my writing some code, the new SURBL engine and SC2 data are ready to roll out. SC2 will become the production SC SpamCop-based list. It will catch significantly more spam than the older version. New new engine also features a faster cycle time, more uniform handling of all the data, etc. Unless there are objections, I think I'll probably just start rolling it out and announcing the change when it's done. The process should be seamless and invisible to end users and DNS admins, aside from a higher SC detection rate and some minor improvements elsewhere. Questions? Comments? Jeff C. -- Don't harm innocent bystanders.

1 0

domain "domain" blacklisted
by Jose Marcio Martins da Cruz 28 Oct '05

28 Oct '05

Hi, The domain "domain" 8-) is listed at jp and generated a false positive (at one of our users). Can you whitelist it please ? domain :127.0.0.64:Blocked, domain on lists [jp], See: http://www.surbl.org/lists.html Regards, Jose-Marcio -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr

2 2

uk DOT geocities DOT com
by Frank Ellermann 13 Oct '05

13 Oct '05

Hi, please remove uk. geocities .com from all white lists and/or add it manually to local URIBLs, it's a black hat. Bye, Frank <news://news.spamcop.net/43456728.12D5@xyzzy.claranet.de>

10 32

use of surbl to check non-body content?
by Steven Champeon 12 Oct '05

12 Oct '05

I've noticed that SURBL (and URIBL, who I will contact later) lists several domains that have appeared in spam header contents as well as in body contents. I'd like to use SURBL (probably multi) as an optional domains BL check against headers known to contain domains, such as the Message-ID, From, and Reply-To headers, a la Message-Id: <200510020442.j924gBkv021479(a)expoactive.net> From: ExpoActive <advertising(a)expoactive.net> Reply-To: advertising(a)expoactive.net From: "Steven McGuire" <stevenmcguire(a)aaaaa2.com> List-Unsubscribe: <mailto:leave-2005_1-6m_optin-10289508G@aaaaa2.com> Message-Id: <LYRIS-10289508-169-2005.10.03-20.50.13--{vic#tim}(a)aaaaa2.com> From: "iMarketing Sales Leads" <julieandrews(a)imailzone.info> Reply-To: "OAG" <club(a)reachmail.net> From: TuneUp Software Newsletter <newsletter(a)tune-up.com> Reply-To: newsletter4v2-reply(a)newsletter.tune-up.com From: "Solutions" <info(a)disklesspc.com> Reply-To: info(a)disklesspc.com From: "Millionaires Concierge" <info(a)millionaires-concierges1.com> Reply-To: info(a)millionaires-concierges1.com Message-Id: <200510020442.j924gBkv021479(a)expoactive.net> From: ExpoActive <advertising(a)expoactive.net> Reply-To: advertising(a)expoactive.net As I've only received 23 spams not otherwise classifiable as worth blocking using other means (e.g., 419 scams which can be blocked by injection IP) this /month/, having successfully blocked all the rest, I'd really like to take advantage of the realtime nature of SURBLs. I could see immediate results in the form of blocking literally 1/3 of the remaining spam I allow in here. Comments? This would be an optional configuration for my enemieslist package, which I intend to have more widespread distribution eventually but which would not represent a crushing query load at present. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/

4 10

Re: [SURBL-Discuss] use of surbl to check non-body content?
by Jeff Chan 12 Oct '05

12 Oct '05

[Rob confirmed he meant to send his reply below to the list. Here's my reply to his (unintentionally) private reply.] On Wednesday, October 12, 2005, 7:14:51 AM, Rob McEwen wrote: >>Were you resolving SURBL domains >>then checking resolved IPs against header IPs? > No, I wasn't. Even though IPs on SURBL are rare, when they do occur, they > are prime candidates for FPs if/when checking headers. > Of course, SURBL FPs on the body of the message are already extremely > rare... But, even so, because we've been constantly making improvements in > that area as well, it is entirely possible that SURBL FPs when checking > against headers might be MORE rare now than in previous months... again, > this being due to our steady and constant across-the-board improvements. While it's true that many of the IPs that appear on SURBLs are probably zombies and those zombies could be used as senders, this is straying pretty far from the original purpose of the lists. Probably something like CBL or XBL would be much better general compromised sender lists to check against message headers. Even something like a Dynamic IP list like dynablock.njabl.org may be a better indicator of zombie-ness. I have not done any research, but far more of the zombies are probably on those lists than as IPs on SURBLs. BTW you sent your reply privately. May I post this? Jeff C. -- Don't harm innocent bystanders.

1 0

Geocities ( and other free/anon hosts...) treated as virtual TLDs
by Eric Montréal 10 Oct '05

10 Oct '05

Hi, I'm new here, so sorry if this have been previously debated. I have seen your discussion about blacklisting geocities. This would create so many FP it's clearly impossible, but I wonder if treating these domains as 3rd / 4th level TLD could be the way to go ... Example: This (-munged) real spammy address http://uk.geocities-munged.com/Gonzalo_Freehling/ could be translated into gonzalo_freehling.uk.geocities-munged.com and then queried ... The translation would require some specific code for these 'virtual TLD' domains in URIDNSBL.pm (for SA3) but would allow catching otherwise undetected URI, while having no FP for non spammy geocities sites. For it to work, the 'virtual TLD' domains should be flagged, either by setting a specific bit in the returned data (during normal queries to the domain) or maintaining a downloadable list. Does it make sense ?

3 2

uk.geocities-munged-.com
by Kevin A. McGrail 10 Oct '05

10 Oct '05

As a follow-up to the UK geocities issue, I fear that this may be related to spyware or a virus. Over the past few weeks, I've identified a few patterns. For example the email below contains 5 email addresses, 4 of which are quite unique. You will also note they are not indicative of a dictionary attack yet they were all email in one single SPAM. Further, at least one of the people on this list passed away over a year ago. Additionally, what I have been seeing is VERY VERY unique emails getting hammered with SPAM and I believe it must be a virus/spyware that is getting the address books off of machines because the emails are too unique to guess. I don't know what to do with this information other than put out my $0.02 that I think people are targeting address books and I can't prove it :-( Regards, KAM > ----- Original Message ----- > From: "parker hair" <lyric(a)bowiewonderworld.com> > To: "Carson Magruder" <payne(a)summerconsultants.com> > Cc: <nance(a)summerconsultants.com>; <hoffman(a)summerconsultants.com>; > <ward(a)summerconsultants.com>; <mail(a)summerconsultants.com> > Sent: Thursday, October 06, 2005 10:06 AM > Subject: bon In a relaxing ishopping mall, nail down quick alleviators. bus > > > > > > Cutback costs for real remedies. > > > > Fast effects antibiotics to allay your fever. > > It's our value that fulfils efficient shipping. > > Ours affordable because of lessen operating cost. > > > > Let our expert review your meddical profiles at zero charge. > > Thanks for facilitating gratis online consultation. Ben J --CA. > > > > http://uk.geocities-munged-.com/windsnarlgreatb/?owgroclo > >

2 1

New redirector: www.nate.com
by Richard Grabowski 07 Oct '05

07 Oct '05

Dear David, I am an attorney in California. Our firm represent ISPs and have begun to actively pursue SPAMMERS under the California fraud laws and the Federal Can SPAM act. I have been following yours and your colleague's messages on [SURBL-Discuss]. Our primary problem is identifying SPAMMERS in a way that we can start a federal action against them. "Redirect" problems add to our other problems of identifying SPAMMERS. Currently we are trying to Identify defendant's by tracking them to the retail site they represent. We then include the owner of the retail site, the registrar of the domain (in almost every case this is YES NICK LTD), and any technicians we identify along the way. Ignore the arguments you have heard about what can and cannot be brought under the current law - I really think this has been produced by attorneys who are defending SPAMMERS to get ISP's and federal/State prosecutors not to bring actions, or to set up some kind of future defense. I am looking for any help you or your associates might be able to provide. I realize you must be skeptical. Therefore you can check my credentials at the CA State Bar site (look it up on google) by doing an attorney search on my name - Richard Grabowski. I am located in Eureka, CA. In addition to being an attorney I have over 30 years experience as a technician in the IT and Telecommunications industry. I worked for GTE, DMR and BusinessEdge as a senior enterprise architect. I am looking for tools, freeware or paid, that help track domains, email servers, senders, etc. Anything that will help identify the actual source of the SPAM in a quick and efficient manner. I am working with high end technicians that have extensive experience in this area, but I am always looking for more help. We will bring actions against SPAMMERS in foreign countries. We do not actually expect them to respond to a federal complaint, so we will end up with default judgments. These are relatively cheap to pursue. We will then try to make a deal with the legal agencies in the foreign country, a percentage, to try and recover on the judgment. This may eventually make it too expensive for the SPAMMERS to continue, or it may incent the local legal agencies to actually pursue the SPAMMERS, rather than protect them. As I have said we are actively pursuing this tactic now. I am hoping that you and your colleagues will want to help. The enforcement of SPAM laws is currently being left to the FTC and State prosecutors. These agencies have little or no budget to pursue these activities. I unfortunately believe that the laws were set up limiting enforcement primarily to the FTC in order to prevent any real prosecutions. This is a tactic of some politicians to support their contributors without actually having to oppose legislation. In this case it has made enforcement of the SPAM laws very unlikely. The only case I know of is a joint action by the FTC and CA State Atty Gnl.: FTC and People of CA v. Optin Global, Inc. and Vision Media Limited, Corp. You can find the federal filing at: http://www.ftc.gov/os/caselist/0423172/050413comp0423172.pdf We are using this filing as the template for our filings. If you can help I would really like to hear from you. Thanks, Richard Grabowski rgrabows(a)pacbell.net W - 707 441-1487 C - 707 771-9585

2 1

[PLEASE NOTE] Change in location for sa-blacklist downloads
by William Stearns 29 Sep '05

29 Sep '05

Good day, all, (Summary - the sa-blacklist content is moving to new machines. If you're downloading any of the 15 versions of this list, you'll need to change the hostname you use in your download; see "What you need to do" below for instructions.) I had a chat with my ISP last week. They've known for a long time that the bandwidth spike at the top of very hour was my web server, but since they knew the sa-blacklist was hosted there and it was a public service project, they told me not to worry. Fast forward to last week. *smile* When I asked this new contact what amount of bandwidth my hosting contract would normally allow and how much bandwidth I'd actually been using over the last few months, he told me that I should be around 10G/month, but I've been using 1000G/month. Woah. Luckily, he wasn't asking me to pay 100X my current contract. *smile* They really have been great about it (I mean that sincerely), but both they and I know that's an unreasonable drain on their bandwidth and unfair to the other customers. To fix that, I'm transitioning the content to new machines with more available bandwidth. I owe a heartfelt thanks to Raymond, David, Panagiotis, Rob, Wim, Jeff, and Chris for offering to host the content at no cost on much faster lines than mine and offering suggestions on how to make the process more efficient. Their generousity makes it possible for me to continue providing this content. ==== What you need to do ==== I've already set up new hostnames (*) from which the sa-blacklist files can be pulled. If you're getting any sa-blacklist files over http, please change the hostname you use to "www.sa-blacklist.stearns.org". If you are using rsync to pull content, please use "rsync.sa-blacklist.stearns.org". If you're using ftp, please use "ftp.sa-blacklist.stearns.org". In other words, the exact same content should be viewable at http://www.sa-blacklist.stearns.org/sa-blacklist/ ftp://ftp.sa-blacklist.stearns.org/pub/wstearns/sa-blacklist/ rsync://rsync.sa-blacklist.stearns.org/wstearns/sa-blacklist/ (although this last one is commonly used by the rsync application and won't work in a web browser.) There's a real benefit to you in taking the time to make this switchover. My server was getting pegged for multiple minutes at the top of the hour, so you'll find your downloads are much faster. Because of the way the files are distributed, the content on the mirrors should always be as current as the ones on the main server. At some point in the near future, I'll be limiting access to or completely shutting down the old URLs, so it's to your advantage to switch over sooner rather than later. *smile* I'd sincerely appreciate it if you could check any automated download scripts or cron jobs and point them to these new hostnames. Sorry for the inconvenience, but because these URL's are only used for this content, you won't need to make this change again. As one last suggestion, you might want to consider using the ws.surbl.org dns lookup service which performs the same checks as sa-blacklist.current.uri.cf , but _much_ faster and with a _lot_ less memory. More information about this dns-based service is available at http://www.surbl.org/ . Cheers, - Bill * These aliases will transparently pick a random server out of the available machines, spreading out the load. As more mirrors come online you'll be sent to them automatically. --------------------------------------------------------------------------- (Referring to the 32 bit system that feeds out files for kernel.org) "We learned that the Linux load average rolls over at 1024. And we actually found this out empirically." -- Peter Anvin -------------------------------------------------------------------------- William Stearns (wstearns(a)pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org --------------------------------------------------------------------------

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss