Jump to content

get-even

Members
  • Content Count

    75
  • Joined

  • Last visited

Everything posted by get-even

  1. get-even

    Missed URL

    You will probably have better luck with TUCOWS. Especially if you include the spam and evidence of the false whois data. Also, file ca complaint at wdprs.internic.net - It will get to TUCOWS and reinforce the chances that they take action) and the "new" wdprs auto-response invites you to file a complaint against the registrar if no action is taken) -- Just remember, in the absence of fraud, they get 15 days to "fix" things; But forged headers *do* count as fraud.
  2. get-even

    Missed URL

    Same registration data as the first (MORT-LOA-NS.COM) even down to the registration dates. % whois MORT-LOA-NS.COM Registrant: llc 78 squirrel road Winnipeg, Manitoba Sx13s1 CA Domain name: MORT-LOA-NS.COM Administrative Contact: haas, fred complaints[at]mort.com 78 squirrel road Winnipeg, Manitoba Sx13s1 CA +1.2068880462 Technical Contact: haas, fred complaints[at]mort.com 78 squirrel road Winnipeg, Manitoba Sx13s1 CA +1.2068880462 Registrar of Record: TUCOWS, INC. Record last updated on 10-Jan-2005. Record expires on 08-Nov-2005. Record created on 08-Nov-2004. Domain servers in listed order: NS1.MORT-LOA-NS.COM 61.218.70.139 NS2.MORT-LOA-NS.COM 220.175.8.137 Domain status: ACTIVE % whois e-mor-t-gage.com Registrant: llc 78 squirrel road Winnipeg, Manitoba Sx13s1 CA Domain name: E-MOR-T-GAGE.COM Administrative Contact: haas, fred leads[at]leads.mine.nu 78 squirrel road Winnipeg, Manitoba Sx13s1 CA +1.2068880462 Technical Contact: haas, fred leads[at]leads.mine.nu 78 squirrel road Winnipeg, Manitoba Sx13s1 CA +1.2068880462 Registrar of Record: TUCOWS, INC. Record last updated on 10-Jan-2005. Record expires on 08-Nov-2005. Record created on 08-Nov-2004. Domain servers in listed order: NS1.MORT-LOA-NS.COM 61.218.70.139 NS2.MORT-LOA-NS.COM 220.175.8.137 Notice the names serves are the same machines at the same IPs, just different domain names.
  3. get-even

    Missed URL

    There are a group of related domains at work here. First the URL in your email MORT-LOA-NS.COM is registered in Canada, but uses a telephone number (if valid) from Seattle. Also, the site is actually hosted by hinet.net in Taipei, Taiwan. The next related domain is "mort.com" which gets us to Minneapolis, MN, but has invalid email and fax numbers in the registration data. Next we check "mortenson.com"; Same address as "mort.com" but with more invalid telephone/fax numbers. This leads to both "ONVOY.NET" and "mr.net":, also in Minneapolis, but at a different address (the same for these two), 300 North Highway which doesn't seem to exist at all (i.e. false address in registration). The only one of these with a history of prior complaints, seems to be "onvoy.net", but further research might turn up more on the other domains. You can check more from these starting pionts if you think it is worth your time (I just spent my two minute allotment for this).
  4. get-even

    Newbie spam tech questions

    Everyone in this thread has also ignored the cases of swip'd address blocks (i.e. directly assigned by ARIN or another controlling organization), where the spammer directly controls the address space and no ISP is involved. Examples abound - the spammers tend to look like ISPs themselves and usualy have at least a few legitimate customers along with the spam operations running from those netblocks; Look on Spamhaus at the various listings for the ROSKO spammers and see how many are attributed to ARIN - these all fall in that catagory (though there is always still a "bandwidth provider" who supplies the routing/BGP4 services to these cases). Also, everyone has ignored the cases of "hijacked" IP space also - see the pages at www.completewhois.com for avery good explaination of these. Neither of these cases involves *any* ISP (though some bandwidth providers are also ISPs, not all are).
  5. get-even

    Newbie spam tech questions

    Most spam is sent by trojaned home machines connected to either DSL or cable serveice, not through the IPS's mail servers (and jumping ahead, most spam originates in the U.S). Many people do block by country (look at xxx.blackholes.us); But... some of us get valid email from those countries also. Just console yourself with the fact that the problem would be *even worse* if noone did report. Look for a copy of the "Spammer Rules" (many variations abound) - but a common one is "Most Spammers are stupid" (it is the exceptions who are dangerous). It prevents a person receiving bouces from forwarding a large number of messages to the FTC or other goverment agencies (e.g. your state's Attorney General).. Also, the CAN-spam penalties increase as the number of messages sent increases. Reverse DNS blocking - Invalid domains are *too* easy to filter out. Many ISPs will cite "privacy" concerns - check and see and you'll find many accounts do get shut. See above (i.e. valid Chinese traffic) - also money talks, Sprint (and many other bandwidth providers) get a lot of cash for providing high bandwidth services to questionable parties. Not that I've ever seen (though technical content abounds).
  6. get-even

    Spamcop blocking affects the innocent

    Actually in the absence of any explicit 'MX' records, an 'A' record is imputed to be an implied 'MX' record (RFC 1035). The domain "myvzw.com" does have an 'A' record - i.e. 207.68.174.238 which is the same as having an explicit 'MX' record for the purposes of RFC 1035. Edited - Sorry the proper RFC is RFC2182 section 10.3.
  7. get-even

    Remove info that can identify sender

    That and sha1 or md[45] hashs of your email *usually* are covered by the cases ( and (d) I gave. Clearly, this is a growing trend (rot13 is old, and many tools will decode it - a transposed md5 encoding seems to be becoming popular - it is harder to recognize, easy to compute and the more advanced spammers will use a database to match the message to the recipient rather than just directly added something which would be subject to cryptoanalysis).
  8. get-even

    Remove info that can identify sender

    Your are correct, I was overly vague, so I'll try to touch each point individually. a) - almost always - : If the dns for xyz.abc.spammer.tld resolves through a wildcard to *.spammer.tld, there is no point in ever including the host or subdomain names, regardless of whether they contain identifiers or not; Merely noting that the hostname is wildcarded and changing the report so reflect that (with a *.spammer.tld or equivalent should always be acceptable). - They are often - Again, assuming the same page is displayed with or without the "affiliate" code, no information is lost, and in many cases where an affiliate code is needed to access the URL, a random string of the same length usually works (there I go again with usually - I did say this is the toughest part of the problem); However after a single report, sucessive reports where the URL differs only by the affiliate ID string can be changed to all use a common one (preferably from a user who has given permission or from a "floating" spam trap). c) - make an exception..."usually* will tell you - if the domain is registered at a residence (noted in many reistrations) or is a "known" ISP (ex. sbcglobal.com et. al, juno, verizon, etc.) the answer is obvious, also users could specify that the domain they use is personal, which would entirely avoid the problem. d) -"hash buster" has often had - like the first case, no information is lost by munging the seemingly random strings which are otherwise unconnected to the message; A more difficult problem is the recent trend to append "jokes" or short quotes from literature to the text of the message and one might argue that in at least some cases I've seen, the added text *is* germane to the original subject (still, when I get two spams from the same source but to different accounts and this is the only difference, the matter becomes quite clear - nothing will be lost in the effectiveness of investigating the report, which should center around the advertized product not the gibberish added to beat systems like Razor, Pyzor and DCC, even when it doesn't contain any identifiers. I'm fairly certain that none of my proposals would ever change who the reports go to (I never proposed changing any headers *before* those that identify a "personal" domain. And I only proposed changing the URL when it can be demonstrated that the host and/or subdomains are irrelavent. It is VERY important, that no changes occur before parsing, only in the actual reports sent out.
  9. get-even

    Remove info that can identify sender

    What language do you want it in? a) Remove any prefixes from wildcarded DNS, they are almost always identifiers - i.e. change the site to *.spammer.tld. Trivial work in any language, one potenialy recursive DNS query to decide upon. Remove the "afiliate" postfix from sites' IRIs (e.g. ...tld/?randomString); They are often identifiers, and once a single one is known, the page can be tested to see if any is required or if random strings or null strings give the same responce. This is the most complex issue - depending on how "smart" it must be the total time is likely on the order of a week to create code that both works and is efficient. c) Remove the recipients domain name everywhere it appears (including, but not limited to headers, msgids, and URIs) - make an exception for any idenitifiable ISP (vs. a buisiness or individual) - this requires a database list of known ISPs (not as hard as it seems for 95% of the cases - whois and the presence of a whois server or the method of IP allocation (i.e. direct allocation for a TL-Nic, swip, reallocation or assignment) "usually* will tell you the proper action. Again, farily simple, without knowing the code structure of the parser, I'd still guess under two days, no matter what/how the current implimentation is done. d) Recognize the "hash buster code" and replace it with a marker like "Random words here" with a count of the lines, words and characters - again the "hash buster" ihas often had a unique checksum associated which allows tracking back to the recipient. Possibly noting whether dictionary words, common words or random strings were used. Likely between a half a day to a single long day depending on the existing implimentation and possible contraints (need to minimize time and memory usage for large hashes). These four cases would potentially require a pair of whois lookups, two or three recursive DNS queries and some trivial string manipulations and arithmetic. Most of the results for users could be cached for a significant time (no spammer 120 sec. TTLs) and the whois data could be cached for at least a day and probably a week or more. The only "expensive": operation is the attempt to remove the fake or real "affiliate" codes - this might require two or three attempts to load the spammer's site's page and would have to be performed through a set of proxies to avoid detection of the particular machines used (and, of course the counter-measure of blocking them once identified) though this infomation also, can be effectively cached (likely for at least days). If I guess in 'C' about 1 and a half weeks to both code and create the infastructure needed; For me, add about a half week for fitting into someone else's C++ and likely a week further for typical Perl (though some "clean" Perl would be about the same as for 'C' -- More obscure languages would depend depend on if there is a FLI and how much experience I have in them - many I know are long obsolete; e.g. Fortran [89]x would add several weeks, smalltalk or Lisp are unreasonable choices though Algol68 with library support might be simple and Pascal would be workable, Modula[23] would be similar). This is not volunteering, but I might be persuaded to take this on over a period of time (one to two months total, to fit in in with work and sleep)..
  10. get-even

    DCC - distributed checksum clearinghouse

    The DCC is most similar to both Razor and Pyzor, though somewhat more effective than either of those. I believe I had mentioned it in my response to the thread about unmunged reports and AboveNet and Paul Vixie. Like Paul Vixie, the author and principal behind the DCC, Vernon Shryver, has made many visible contributions to the internet community as a whole (I belive he is the current maintainer of "ping" and one of the original authors and the current maintainer or "routed" and probably a few more things I can't remember off the top of my head).. Just as the entire anti-spam community benefits from the association betwwen SpamCop and SURBL; the massive traffic through SpamCop would be a significant addition to the database(s) of the DCC. The only downside I can see, if that with the size of the traffic SpamCop handles, a dedicated server either at SpamCop, SenderBase or Ironport would be needed (though a < $1000 machine with lots of RAM and a few fast disks would do). The DCC is *not* a blacklist, it is a hash based recognition system to determine if a piece of email is "bulk" or not. Unfortunately, its only "really" clean/convenient interface is through a (few available) milters for sendmail, or its inclusion through Spamassassin (though I think people have hooked it up to most of the common MTAs available). The published hit rates for the DCC are between 60-70% correct positives with few false positives (though it primary goal is to discern bulk mailings, which may not actually be spam - ex. marketing newsletters). One of the great advantages the DCC has over many other tools is the very low overhead per message involved (both in time and resources); Also, I think (I don't use a SpamCop email, that SpamAssassin is available to users, and DCC support is built into the 3.x releases, though it may be disabled in any particular configuration)., it may actually already be in use in some fashion for some users. Proof of its effectiveness can be found in articles in the same spammer oriented newletters which describe how to `avoid" SpamAssassin and `beat' the SpamCop parser have articles on how to "hash bust" the DCC. (Properly interested people can contact me offline for the actual data). IMNSHO, a link between SpamCop and the DCC would be a great boon for everyone involved - users and principals. Much more info available at http://www.rhyolite.com/anti-spam/dcc P.S. Vernon is both brilliant and very stubborn (re. tenacious), two qualities that have made the project very successful (not to mention the support of others like Vixie, Sam Leffler and various other "known" names from the "old" days and quite a few medium to large ISPs).
  11. get-even

    SPAMCOP getting confused by long URLs

    Carol Brisbase == iMedia/Michael Lindsay, AFAIK Wildcard DNS - 'CNAME' abuse % dig '*.sucservice.com' any [at]ns7.wdrhosting.com. ; <<>> DiG 9.3.0 <<>> *.sucservice.com any [at]ns7.wdrhosting.com. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4994 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;*.sucservice.com. IN ANY ;; ANSWER SECTION: *.sucservice.com. 3600 IN CNAME www.sucservice.com. ;; AUTHORITY SECTION: sucservice.com. 3600 IN NS ns1.realdnssystem.com. sucservice.com. 3600 IN NS ns3.autonameservers.com. sucservice.com. 3600 IN NS ns4.bighostsolutions.com. sucservice.com. 3600 IN NS ns7.wdrhosting.com. ;; Query time: 307 msec ;; SERVER: 222.223.134.36#53(ns7.wdrhosting.com.) ;; WHEN: Mon Jan 17 15:56:50 2005 ;; MSG SIZE rcvd: 182 % dig www.sucservice.com any [at]ns7.wdrhosting.com. ; <<>> DiG 9.3.0 <<>> www.sucservice.com any [at]ns7.wdrhosting.com. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16684 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.sucservice.com. IN ANY ;; ANSWER SECTION: www.sucservice.com. 30 IN A 218.7.120.117 ;; AUTHORITY SECTION: sucservice.com. 3600 IN NS ns1.realdnssystem.com. sucservice.com. 3600 IN NS ns3.autonameservers.com. sucservice.com. 3600 IN NS ns4.bighostsolutions.com. sucservice.com. 3600 IN NS ns7.wdrhosting.com. ;; Query time: 320 msec ;; SERVER: 222.223.134.36#53(ns7.wdrhosting.com.) ;; WHEN: Mon Jan 17 15:59:42 2005 ;; MSG SIZE rcvd: 182 additional info: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL20960
  12. An example for why to do this: 4 spam messages, 3 separate domains, each with the same 3 identical 'A' records. Each one parsed showing no "history" for the site (initially) and two different IPs resolved in different reports (instead of all being recognized as a single source/site). http://www.spamcop.net/sc?id=z713073062z25...a68253f862cbd1z http://www.spamcop.net/sc?id=z713073168zd1...9790a4a2943187z http://www.spamcop.net/sc?id=z713073261z96...471c01714160f2z http://www.spamcop.net/sc?id=z713073168zd1...9790a4a2943187z % dig '*.sdfkjhwerg.info' any ; <<>> DiG 9.3.0 <<>> *.sdfkjhwerg.info any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27429 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;*.sdfkjhwerg.info. IN ANY ;; ANSWER SECTION: *.sdfkjhwerg.info. 1200 IN A 65.203.151.193 *.sdfkjhwerg.info. 1200 IN A 211.144.162.61 *.sdfkjhwerg.info. 1200 IN A 211.144.164.201 ;; AUTHORITY SECTION: sdfkjhwerg.info. 1200 IN NS FIRST.darubebam.biz. sdfkjhwerg.info. 1200 IN NS THIRD.darubebam.biz. sdfkjhwerg.info. 1200 IN NS SECOND.darubebam.biz. ;; ADDITIONAL SECTION: FIRST.darubebam.biz. 597 IN A 211.144.164.201 THIRD.darubebam.biz. 599 IN A 211.144.162.61 SECOND.darubebam.biz. 597 IN A 211.144.162.44 ;; Query time: 332 msec ;; SERVER: 199.184.245.68#53(199.184.245.68) ;; WHEN: Sat Jan 15 15:29:34 2005 ;; MSG SIZE rcvd: 205 % dig '*.sdfkjhwerg.info' any [at]SECOND.darubebam.biz. ; <<>> DiG 9.3.0 <<>> *.sdfkjhwerg.info any [at]SECOND.darubebam.biz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38190 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;*.sdfkjhwerg.info. IN ANY ;; ANSWER SECTION: *.sdfkjhwerg.info. 1200 IN A 65.203.151.193 *.sdfkjhwerg.info. 1200 IN A 211.144.162.61 *.sdfkjhwerg.info. 1200 IN A 211.144.164.201 ;; AUTHORITY SECTION: sdfkjhwerg.info. 1200 IN NS FIRST.darubebam.biz. sdfkjhwerg.info. 1200 IN NS SECOND.darubebam.biz. sdfkjhwerg.info. 1200 IN NS THIRD.darubebam.biz. ;; ADDITIONAL SECTION: FIRST.darubebam.biz. 1200 IN A 211.144.164.201 SECOND.darubebam.biz. 1200 IN A 211.144.162.44 THIRD.darubebam.biz. 1200 IN A 211.144.162.61 ;; Query time: 310 msec ;; SERVER: 211.144.162.44#53(SECOND.darubebam.biz.) ;; WHEN: Sat Jan 15 15:29:44 2005 ;; MSG SIZE rcvd: 205 % dig '*.sdfhwbsldf.info' any [at]SECOND.darubebam.biz. ; <<>> DiG 9.3.0 <<>> *.sdfhwbsldf.info any [at]SECOND.darubebam.biz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50388 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;*.sdfhwbsldf.info. IN ANY ;; ANSWER SECTION: *.sdfhwbsldf.info. 1200 IN A 65.203.151.193 *.sdfhwbsldf.info. 1200 IN A 211.144.162.61 *.sdfhwbsldf.info. 1200 IN A 211.144.164.201 ;; AUTHORITY SECTION: sdfhwbsldf.info. 1200 IN NS FIRST.darubebam.biz. sdfhwbsldf.info. 1200 IN NS SECOND.darubebam.biz. sdfhwbsldf.info. 1200 IN NS THIRD.darubebam.biz. ;; ADDITIONAL SECTION: FIRST.darubebam.biz. 1200 IN A 211.144.164.201 SECOND.darubebam.biz. 1200 IN A 211.144.162.44 THIRD.darubebam.biz. 1200 IN A 211.144.162.61 ;; Query time: 315 msec ;; SERVER: 211.144.162.44#53(SECOND.darubebam.biz.) ;; WHEN: Sat Jan 15 15:33:29 2005 ;; MSG SIZE rcvd: 205
  13. get-even

    Is it really doing any good?

    Read spamhaus' definition of a ROSKO spammer (not the actual criteria - three different ISPs - but the description). To paraphrase, a professional thinks of ISPs as a disposable resource. (Still, I agree, this is the best way to drive the cost of spamming up).
  14. get-even

    Cannot reach www.spamcop.net

    % telnet www.spamcop.net 80 is a HTTP connection (for those who are Windows-based clueless). With no third argument telnet defaults to TCP port 23 (for anything else, on any *nix, remember to disable the enviroment passing and protocol negotiation in most cases -- the MS client will not initiate them, so it is actually easier to use in a few cases). One of its great abilities is to connect to any TCP port, and if you know the protocol well enogh, you can test it "by hand". Even the MS version will do this for you - try sometime connecting to a SMTP, HTTP, SSH or any other tcp based server (if you're stuck on a MS box, "putty" works very well and in older versions always requires you to enter the port, current versions default to port 22 - SSH, which really is the intended purpose of the program). In fact, I spent about an hour and a half, this week, helping a registrar debug a problem with his proprietary 'whois' server (which was/is returning short replies) - much of that time was spent with "telnet host.xx.tld 43" and typing the queries manually -- BTW. many name name servers will still respond to "obsolete commands" that have either been removed from bind9 (and some bind8 versions on Redhat) clients or aren't supported by the MS Windows client (the "ls" comand is the most useful and common of these - it does an AXFR of the domain's entire database - if allowed). Learning to use telnet for more than just tcp port 23 is one of the first tools to master if you ever hope to do *real* network debugging. After you get that done, learn a few more tools (in particular netcat or "nc") so you cat debug/test non-tcp ports also (trickier mostly because the protocols are more likely to be binary, and lots of UDP stuff has weird handshaking rules - to make up for the lack of reliable delivery - that you must remember to abide by, or your connection just drops). After you understand "real" connections, we can talk about forged packets, MiM attacks, traceroute spoofing and the variety of "tricks" that both the white and black hat communitees use. You could also have taken a look at the posts and seen that I posted HTTP sessions, just using telnet to initiate them (it shows much more detail than a browser *because* the HTML is uninterpreted (re. "raw"). Also, I have multiple ISPs and lines coming in here, these connections were not only to different addresses, but were done using different source IPs and different outgoing networks (on different ISPs, on completely separate AS's - read as routes, if you don't know what an AS is - once they got outside of my network). Anyway, "my" posts show what clearly is akamai timing out on tallking from the host a369.g.akamai.net to the caching proxy behind it, but internal to akamai's own network (look up the difference between a "404" and a "408" in the protocol) ; I also noted that the connections were immediate with the timeout coming from the other side (something you can't determine from most browsers, though lynx in debugging mode can give you some information). Also, just as a note, all of my 300+ addresses "appear" to respond to pings, traceroutes and *many* other "non-essential" ports, just my first level firewall forges packets in response to the probes to prevent any trivial probing from providing much info (though tools like nmap and hping, can be used to "see' that some of those responses are forged). Administrators who just shut ports usually don't know what they are doing (often creating path-MTU blackholes by blocking ICMP); Unfortunately "common" wisdom is mostly incorrect (particularly the "stealth" vs. "drop" arguments). My network uses the same defenses as those I have built for Fortune 100 companies (and mostly large computer or electronics companies at that). So your only correct statement might be that you can't trust the results you see with ping until you've probed further and with an arsenal of other tools also (I use the "firewalk" project as a guideline, as long as they can't catch the defenses, I feel mostly safe - depending on how you want to count I was "attacked" on various address spaces between 10,00 & 25,000 times last week, logging 347,000 packets that were blocked and either dropped or generated forged responces, so I can tell you that there are plenty of "black" hats out there who know some of this too). The comsumer level "firewall" boxes, even the lower-end Sonicwall , Cisco PIX, etc. boxes aren't really any protection from a knowlegable hacker; Fortunately most home users *are* safe if they don't run any servers AND sit behind a NAT box with at least some SPI. But personally, I know of too many flaws in all the major brands, and so do too many other people, to use them for *anything* which allows *any* incoming connections (i.e. don't let your browser do any active ftp, a hacker or someone like me can hijack the back channel trivially). As a side note, many/most spammers don't bother with firewalls, they do tend to run SEL-Linux and OpenBSD quite a bit on their machines (a real firewall takes a *lot* of resources, and examining the logs is not for the faint-hearted). and
  15. get-even

    Cannot reach www.spamcop.net

    I had thought that my first two posts in http://forum.spamcop.net/forums/index.php?showtopic=3288 had clearly shown the issue. It is internal to akamai.net, and is clearly a case of their own servers timimg out internally (look at the "telnet" tests). P.S. I haven't seem the problem myself since my last post on the subject.
  16. I believe that "frankXXX[at]126.com" is a 'bot for harvesting valid email addresses. I have been shown other information that makes it appear that "AlexanderLinder[at]163.com" is personally Alan Ralsky. For people like Merlyn, who lists his interests as "Researching Spammers.", it can be informative to look up sequential domain registrations on ChinaNet (seemingly created by a scri_pt or `bot - sometimes over a hundred can be created in a ten minute period) by the handle instead of the domain name (so you can see the actual sequence) and count the percent using a [at]163.com account against those using "antispam[at]xxx.xxx.cn". Just for anyone still interested: $ whois bp2-rx.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: BP2-RX.COM Registrar: GANDI Whois Server: whois.gandi.net Referral URL: http://www.gandi.net Name Server: NS1.NS-1.BIZ Name Server: NS2.NS-1.BIZ Status: ACTIVE Updated Date: 06-jan-2005 Creation Date: 21-dec-2004 Expiration Date: 21-dec-2005 >>> Last update of whois database: Mon, 10 Jan 2005 07:38:51 EST <<< NOTICE: The expiration date displayed in this record is the date the registrar's sponsorship of the domain name registration in the registry is currently set to expire. This date does not necessarily reflect the expiration date of the domain name registrant's agreement with the sponsoring registrar. Users may consult the sponsoring registrar's Whois database to view the registrar's reported date of expiration for this registration. TERMS OF USE: You are not authorized to access or query our Whois database through the use of electronic processes that are high-volume and automated except as reasonably necessary to register domain names or modify existing registrations; the Data in VeriSign Global Registry Services' ("VeriSign") Whois database is provided by VeriSign for information purposes only, and to assist persons in obtaining information about or related to a domain name registration record. VeriSign does not guarantee its accuracy. By submitting a Whois query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes that apply to VeriSign (or its computer systems). The compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of VeriSign. You agree not to use electronic processes that are automated and high-volume to access or query the Whois database except as reasonably necessary to register domain names or modify existing registrations. VeriSign reserves the right to restrict your access to the Whois database in its sole discretion to ensure operational stability. VeriSign may restrict or terminate your access to the Whois database for failure to abide by these terms of use. VeriSign reserves the right to modify these terms at any time. The Registry database contains ONLY .COM, .NET, .EDU domains and Registrars. % GANDI Registrar whois database for .COM, .NET, .ORG., .INFO, .BIZ, .NAME % % Access and use restricted pursuant to French law on personal data. % Copy of whole or part of the data without permission from GANDI % is strictly forbidden. % The sole owner of a domain is the entity described in the relevant % 'domain:' record. % Domain ownership disputes should be settled using ICANN's Uniform Dispute % Resolution Policy: http://www.icann.org/udrp/udrp.htm % % Acces et utilisation soumis a la legislation francaise sur % les donnees personnelles. % Copie de tout ou partie de la base interdite sans autorisation de GANDI. % Le possesseur d'un domaine est l'entite decrite dans % l'enregistrement 'domain:' correspondant. % Un desaccord sur la possession d'un nom de domaine peut etre resolu % en suivant la Uniform Dispute Resolution Policy de l'ICANN: % http://www.icann.org/udrp/udrp.htm % % Date: .................. domain: BP2-RX.COM owner-address: Ralsky Rocks Inc owner-address: 8976 Dien Bien Phu, owner-address: HN10000 owner-address: Ba Dinh,Hanoi owner-address: Vietnam owner-phone: +84.913236677 owner-e-mail: ihatespam1[at]PunkAss.com admin-c: HR266-GANDI tech-c: AR41-GANDI bill-c: HR266-GANDI nserver: ns1.ns-1.biz nserver: ns2.ns-1.biz reg_created: 2004-12-21 21:50:46 expires: 2005-12-21 21:50:46 created: 2004-12-22 03:50:47 changed: 2005-01-06 10:10:19 person: Hermish Ralskey nic-hdl: HR266-GANDI address: 8976 Dien Bien Phu, address: HN10000 address: Ba Dinh,Hanoi address: Vietnam phone: +84.913236677 e-mail: ihatespam1[at]PunkAss.com lastupdated: 2005-01-03 16:58:30 person: GANDI Auto Register 4.1 nic-hdl: AR41-GANDI address: GANDI address: 38 rue Notre-Dame de Nazareth address: F-75003 address: Paris address: France phone: N/A e-mail: support[at]gandi.net
  17. Yes iMedia/Michael Lindsay runs that particular site. But even worse, 126.com is Alan Ralsky's personal domain. spam reports to them is one of the very few I uncheck (I don't even have problem with CYVEILLANCE', despite my posting of their 'whois' issue). Don't know about iMedia, but Ralsky will definitely spam you more (his spam almost always contains hidden identifiers, so munged or not, you will be visible in the report).
  18. get-even

    Too Many Links??

    Merit/radb.net show the block as allocated by LacNic. In turn after following a few sub-allocations, it is registered to an organization calling itself "BR IT Consulting" and using (at least) the domain "BRITCONSULTING.COM.BR" (back to some British Isle connection again); However, most of their holdings are registered in either Spain, or Seychelles (as well as Brazil). Additionally (despite my previous comment about it not likely being Ralsky), Spamhaus has two listings, one added Christmas day and another one added on Jan. 5 which do claim that the address space is controlled by Ralsky. URLs below: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL21787 http://www.spamhaus.org/sbl/sbl.lasso?query=SBL22560 Quite likely some very advanced tricks which aren't immediately obvious but may include BGP4/routing abuse as well as DNS tricks and even possible IP hijacking. Far too convoluted to disentangle without probably a few hours of work. Very few people in the world know how to forge routing info, and fewer still can actually cause false routes - as opposed to merely invalid ones - to function; I'm quite certain that I did connect (through an anonymous proxy) to a site in Korea, when I first tried to access the site. Now the site seems to be unavailable.
  19. I purposely add an account at my domain for archiving all reports I make. Is it possible to default such a "third party" check box to be already checked (saving a few seconds for the majority of cases where I don't have to examine the full message, just the Subject header or recognize the URLs (about 1/2 to 2/3 or the time)?
  20. get-even

    Too Many Links??

    In just the few minutes since I typed the previous message, the entire IP block containing the site at 200.146.101.107 seems to now have been re-routed to Brazil (where the site does not respond). Very interesting, maybe some advanced BGP4 tricks (I'll have to dig up some things at Merit/radb.net before knowing what has *really* happened).
  21. get-even

    Too Many Links??

    The real spammer's site is at IP 200.146.101.107 and correspond to the wildcarded address for the domain "dmsyvuu.com". I have reported other sites at this address, I believe, in the past few days. The spammer is using a variety of tricks including "steath DNS' and wildcarded CNAMEs. The DNS servers (not during a spam run) are ns1.grtdnsserver.com & ns2.grtdnsserver (both "known" spam DNS servers); During a spam run they are set (in DNS) to the host prefixes dn303.{dmsyvuu.com} and dn404.{dmsyvuu.com}: This is a signature for the same spammer controlling the sites at 202.102.230.36 and 202.102.230.37. Also, many of the "apparently" innocent links seem to be controlled (e.g. share the same DNS server, or use other servers which can be found in SPEWS or the SBL) - so at least some of the links are under the spammers direct control and are not truely innocent (I coundn't trace them all in just the few minutes I spent). Also, some of the links are completely bogus (i.e. no such domain). Also, many of those links that do seem innocent after a quick check are located (by registration data) in and around the area Alan Ralsky lives - He is not so stupid, so this is likely another attempt to deflect attention toward him instead of the actual culprit (recently, someone has been registering dozens or even hundreds of spam domains in China and Korea using variations on Ralsky's name - personally I don't believe that it is him - he uses many other recognizable aliases/pseudonyms that are best left not publically known). The spreading of this type of behaviour is a strong argument for trying to check for these tricks in the parser (I'm completely unaware of the effort or changes which might be involved). Certainly, some sort of check of the current DNS (when available) against whois data is needed, as is a check for wildcarding. Also, notice this domain is just over two weeks old - it seems that the 202.102.230.3[67] addresses are being blocked effectively by some tools and/or blacklists. Also, despite this site being in Korea, both it and many of the seeming innocent sites are controlled by organizations in the British Isles (the spammer *may* be using some truly innocent links where he has knowledge of the non-spam sites content, behaviour and/or policies to protect himself). Still a quite impressive array of obfuscation methods for a single message.
  22. get-even

    Recipients who refuse munged reports....

    Yes, the same Vixie of Vixie cron, the original bind and the same person who long ago setup the first major ftp server on the internet, gatekeeper.dec.com (which for years I reached by its original IP address, 16.1.0.2 - still know it by heart), along with many many other contributions to the community. But yes, they can be slow to act (because of MAPS, now part of Kelkea, Inc. they were the first provider to have been targeted by spammers for legal harrassment). He is also the driving force behind (and provided the original funding for) the ISC which produces the DHCP implimentation used by most *nix users and many other tools. He and AboveNet have also provided significant support to Vernon Shryver's DCC project. Yes, the are many problems with AboveNet customers, but in my experience, when given what they consider "proper" evidence, at times they have acted very quickly (I've seem the "plug pulled" overnight in at least one clear cut case of fraud). A previous comment in this thread was correct, in almost all cases, the spammer is a customer of a customer and not anyone with whom AboveNet has a direct legal relationship (which greatly ties their hands and explains why they need generally stronger evidence than an ISP who directly hosts the spammer and ths can thus apply a TOS or AUP directly). I say all this, because I believe that AboveNet had been overly attacked in the anti-spam community and their contributions generally ignored -- they have probably done more to stem the tide of spam than any other major bandwidth provider in the US. (compare them to MCI or Sprint for instance, heaven forbid, they should not even be mentioned in the same breath as most cable companies providing internet service). P.S. I have personally pointed out to Spamhaus personnel the contradiction between a quote by their founder that "MAPS is our hero" and their own occasional "tar-and-feathering" of AboveNet (this "hero" quote can be easily found in Google's archives). P.P.S. I am not now or have ever been an employee of AboveNet, any of their affiates or any other "Vixie" company. I have in the past been both a direct and indirect customer, and they have performed "special" favors for me in the past (best left unmentioned in public).
  23. I have been seeing a lot of spam where the site is (mis)using DNS wildcards. This allows the hostname to change for every recipient (and possibly track the recipient from web logs or reports). In particular, it leads the SpamCop parser to state that there have been no recent reports, when I know that I have reported the same site in just the last few days. Two examples from this morning (same spammer - note identical DNS servers) are as follows (using "dig" to demonstrate the wildcarding): % dig '*.lijniahk.info' any [at]first.bubbalog.biz. ; <<>> DiG 9.3.0 <<>> *.lijniahk.info any [at]first.bubbalog.biz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64849 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;*.lijniahk.info. IN ANY ;; ANSWER SECTION: *.lijniahk.info. 1200 IN A 65.203.151.193 *.lijniahk.info. 1200 IN A 211.144.164.201 *.lijniahk.info. 1200 IN A 200.157.21.204 ;; AUTHORITY SECTION: lijniahk.info. 1200 IN NS FIRST.bubbalog.biz. lijniahk.info. 1200 IN NS SECOND.bubbalog.biz. lijniahk.info. 1200 IN NS THIRD.bubbalog.biz. ;; ADDITIONAL SECTION: FIRST.bubbalog.biz. 1200 IN A 65.203.151.192 SECOND.bubbalog.biz. 1200 IN A 222.223.134.42 THIRD.bubbalog.biz. 1200 IN A 211.144.164.201 ;; Query time: 193 msec ;; SERVER: 65.203.151.192#53(first.bubbalog.biz.) ;; WHEN: Wed Jan 5 09:09:32 2005 ;; MSG SIZE rcvd: 202 --- AND dig '*.inflfffc.info' any [at]first.bubbalog.biz. ; <<>> DiG 9.3.0 <<>> *.inflfffc.info any [at]first.bubbalog.biz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63501 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;*.inflfffc.info. IN ANY ;; ANSWER SECTION: *.inflfffc.info. 1200 IN A 65.203.151.193 *.inflfffc.info. 1200 IN A 211.144.164.201 *.inflfffc.info. 1200 IN A 200.157.21.204 ;; AUTHORITY SECTION: inflfffc.info. 1200 IN NS FIRST.bubbalog.biz. inflfffc.info. 1200 IN NS SECOND.bubbalog.biz. inflfffc.info. 1200 IN NS THIRD.bubbalog.biz. ;; ADDITIONAL SECTION: FIRST.bubbalog.biz. 1200 IN A 65.203.151.192 SECOND.bubbalog.biz. 1200 IN A 222.223.134.42 THIRD.bubbalog.biz. 1200 IN A 211.144.164.201 ;; Query time: 89 msec ;; SERVER: 65.203.151.192#53(first.bubbalog.biz.) ;; WHEN: Wed Jan 5 09:10:35 2005 ;; MSG SIZE rcvd: 202 Thus each recipiant gets a unique hostname reported for the site, and the parser doesn't seem able to recognize them as the same! This *really* needs to be addressed quickly. P.S. only "FIRST.bubbalog.biz" current functions, neither "SECOND.bubbalog.biz." or "THIRD.bubbalog.biz." are `up' at this moment.
  24. Another 'CNAME' wildcarder; Notice the difference before and during a spam run: ---- Before, almost normal (though *.grtdnsserver.com" is an identifiable spam support server) % dig '*.dhdhbua.com' any ; <<>> DiG 9.3.0 <<>> *.dhdhbua.com any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13515 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;*.dhdhbua.com. IN ANY ;; ANSWER SECTION: *.dhdhbua.com. 60 IN CNAME dhdhbua.com. ;; AUTHORITY SECTION: dhdhbua.com. 169102 IN NS ns1.grtdnsserver.com. dhdhbua.com. 169102 IN NS ns2.grtdnsserver.com. ;; ADDITIONAL SECTION: ns1.grtdnsserver.com. 81288 IN A 200.146.101.107 ns2.grtdnsserver.com. 53961 IN A 200.146.101.107 ;; Query time: 343 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jan 7 19:12:35 2005 ;; MSG SIZE rcvd: 126 --- During the "spam run" - "*.grtdnserver.com" is in "stealth" mode, and the 'NS' records are changed % dig '*.dhdhbua.com' any [at]200.146.101.107 ; <<>> DiG 9.3.0 <<>> *.dhdhbua.com any [at]200.146.101.107 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24094 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;*.dhdhbua.com. IN ANY ;; ANSWER SECTION: *.dhdhbua.com. 60 IN CNAME dhdhbua.com. ;; AUTHORITY SECTION: dhdhbua.com. 300 IN NS dn303.dhdhbua.com. dhdhbua.com. 300 IN NS dn404.dhdhbua.com. ;; Query time: 236 msec ;; SERVER: 200.146.101.107#53(200.146.101.107) ;; WHEN: Fri Jan 7 19:13:30 2005 ;; MSG SIZE rcvd: 85 % dig 'dhdhbua.com' any [at]200.146.101.107 ; <<>> DiG 9.3.0 <<>> dhdhbua.com any [at]200.146.101.107 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40555 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dhdhbua.com. IN ANY ;; ANSWER SECTION: dhdhbua.com. 300 IN NS dn303.dhdhbua.com. dhdhbua.com. 300 IN NS dn404.dhdhbua.com. dhdhbua.com. 86400 IN SOA dn303.dhdhbua.com. webmaster.dhdhbua.com. 1104709961 14400 1800 1209600 300 dhdhbua.com. 60 IN A 200.146.101.107 ;; Query time: 264 msec ;; SERVER: 200.146.101.107#53(200.146.101.107) ;; WHEN: Fri Jan 7 19:22:41 2005 ;; MSG SIZE rcvd: 131
  25. Did anyone else notice that CYVEILLANCE's domain imaphost.com has had its name servers marked as invalid by NetworkSolution? % whois imaphost.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: IMAPHOST.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS147.NO-LONGER-VALID.COM Name Server: NS148.NO-LONGER-VALID.COM Status: REGISTRAR-LOCK Updated Date: 22-oct-2004 Creation Date: 16-oct-1998 Expiration Date: 15-oct-2006 >>> Last update of whois database: Wed, 5 Jan 2005 19:20:13 EST <<< NOTICE: The expiration date displayed in this record is the date the registrar's sponsorship of the domain name registration in the registry is currently set to expire. This date does not necessarily reflect the expiration date of the domain name registrant's agreement with the sponsoring registrar. Users may consult the sponsoring registrar's Whois database to view the registrar's reported date of expiration for this registration. TERMS OF USE: You are not authorized to access or query our Whois database through the use of electronic processes that are high-volume and automated except as reasonably necessary to register domain names or modify existing registrations; the Data in VeriSign Global Registry Services' ("VeriSign") Whois database is provided by VeriSign for information purposes only, and to assist persons in obtaining information about or related to a domain name registration record. VeriSign does not guarantee its accuracy. By submitting a Whois query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes that apply to VeriSign (or its computer systems). The compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of VeriSign. You agree not to use electronic processes that are automated and high-volume to access or query the Whois database except as reasonably necessary to register domain names or modify existing registrations. VeriSign reserves the right to restrict your access to the Whois database in its sole discretion to ensure operational stability. VeriSign may restrict or terminate your access to the Whois database for failure to abide by these terms of use. VeriSign reserves the right to modify these terms at any time. The Registry database contains ONLY .COM, .NET, .EDU domains and Registrars. NOTICE AND TERMS OF USE: You are not authorized to access or query our WHOIS database through the use of high-volume, automated, electronic processes. The Data in Network Solutions' WHOIS database is provided by Network Solutions for information purposes only, and to assist persons in obtaining information about or related to a domain name registration record. Network Solutions does not guarantee its accuracy. By submitting a WHOIS query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its computer systems). The compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of Network Solutions. You agree not to use high-volume, automated, electronic processes to access or query the WHOIS database. Network Solutions reserves the right to terminate your access to the WHOIS database in its sole discretion, including without limitation, for excessive querying of the WHOIS database or for failure to otherwise abide by this policy. Network Solutions reserves the right to modify these terms at any time. Registrant: CYVEILLANCE (IMAPHOST-DOM) 1555 Wilson Blvd Suite 404 Arlington, VA 22209 US Domain Name: IMAPHOST.COM Administrative Contact, Technical Contact: WITTING, PAUL (PW3960) pwitting[at]OMSERVICES.COM CYVEILLANCE 602 CAMERON STREET ALEXANDRIA, VA 22314 US 703-519-4212 fax: 703-519-1833 Record expires on 15-Oct-2006. Record created on 16-Oct-1998. Database last updated on 6-Jan-2005 08:10:16 EST. Domain servers in listed order: NS1.RISEMULTIMEDIA.COM 216.111.65.217 NS2.RISEMULTIMEDIA.COM 205.171.16.250
×