Jump to content

get-even

Members
  • Content Count

    75
  • Joined

  • Last visited

Posts posted by get-even


  1. Which the spammers (or the spam-software authors) are quite aware of, and probably do it JUST to get around being reported. *sigh*

    New spew, slightly different URL now: http://e-mor-t-gage.com now instead of "http://morgage-loa-n.com" or whatever.. *sigh*  :(

    23533[/snapback]

    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.


  2. I've gotten something on the order of a half-dozen spams promoting http://mort-loa-ns.com in the past two days to my work email. I have reported every one of them this morning. However, I'm having to manually LART the URL because SpamCop is not picking it up. I'm not sure why... I know it's not all GIF/JPG file, because I can mouse-over it and get the URL. In any event, here's the "tracking URL" from the latest one:

    http://www.spamcop.net/sc?id=z723775947z61...c3cca0da93abc7z

    23526[/snapback]

    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).


  3. 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).


  4. I don't understand why 99% of all reputable ISPs can't have verified accounts that are allowed to send to mail lists, and stop all others that send anything looking like a mass mailing before it gets out the door.

    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).

    I don't understand why the biggest offenders, Chinese, Korean, Brazilian etc., are not simply blocked by all the others who want to be civilized (anyone who says the Chinese can't stop it overnight are ....).

    Many people do block by country (look at xxx.blackholes.us); But... some of us get valid email from those countries also.

    I don't understand why spam reporting seems to have no effect. I do it because I "have faith", I suppose, but it has made no difference to my volume, unless constancy is considered a good thing.

    Just console yourself with the fact that the problem would be *even worse* if noone did report.

    I don't understand why the spammers keep sending to addresses that end in "spamcop.net", or why they don't remove reporters from their lists.

    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).

    I don't understand why they suddenly started using random letter names on their forged emails instead of fake names.

    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.

    I don't understand why they don't totally make up the forged email address, instead of using what mostly seems like real domain names (except for the stupid sender name).

    Reverse DNS blocking - Invalid domains are *too* easy to filter out.

    I don't understand if there is any point in reporting anymore, since it's been a long time that I saw a reply saying that such and such account had been closed down.

    Many ISPs will cite "privacy" concerns - check and see and you'll find many accounts do get shut.

    I don't understand how companies like Sprint can totally ignore the spam traffic that the Chinese pay them for, and still pretend to be be part of the civilized internet.

    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.

    Has anyone published a thorough, not excessively technical, document on these issues and the ones I haven't listed?

    Not that I've ever seen (though technical content abounds).


  5. ...

    No MX records found for myvzw.com

    23433[/snapback]

    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.


  6. Don't forgot the instances where they disguise your e-mail address with rot13.

    23308[/snapback]

    That and sha1 or md[45] hashs of your email *usually* are covered by the cases (B) 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).


  7. There doesn't seem to be a lot of exactness in your proposals.

    What do you do for the cases where the above assumtions are incorrect and you have now reported to the wrong location?

    Only the spammer really knows where the identifiers are located.  Perhaps if we pass a law that says the spammers need to identify all their identifiers in a particular way....sorry.

    23299[/snapback]

    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).

    B) - 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.


  8. And only to add ... if you can figure out how to write a routine that works the miracles you ask, please share ....  moving to the "New Features / Suggestions" Forum ....

    23292[/snapback]

    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.

    B) 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)..


  9. OK, in that case, I'll move this over to the New Feature Request Forum ... thanks for following up.

    23218[/snapback]

    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).


  10. ...

    Domain name: SUCSERVICE.COM

    Administrative Contact:

        Brisbine, Carol  cbrisbine_w[at]yahoo.com

        6059 Jane Dr.

        Mentor, Ohio 44060

        US

        +1.3157756301

    Technical Contact:

        Brisbine, Carol  cbrisbine_w[at]yahoo.com

        6059 Jane Dr.

        Mentor, Ohio 44060

        US

        +1.3157756301

    ...

    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


  11. Please adjust the Parser to identify all A Records and follow all CNAME Records for spamvertized URLs in order to more completely inform the ISPs of the systems providing spam support services in the form of web services for those URLs.  Thanks!

    21918[/snapback]

    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


  12. What if the ISP's removed their spammers?

    I believe this would be the best solution!

    23143[/snapback]

    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).


  13. I don't think so. You don't test a web server's response using either Telnet or Ping. You test it only via attempted HTTP connections. A long time ago, you could ping and/or telnet to servers, but due to the various types of DOS (denial of service) issues in recent years, server admins have closed all the non-essential ports on web servers and the routers/firewalls that lead to them, so this type of testing only works on servers that aren't fully protected.

    I think that the problem for both of you OP's is local to your own connectivity and/or computers.

    DT

    22916[/snapback]

    % 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).

    % telnet www.spamcop.net 80

    Trying 209.247.88.168...

    Connected to a369.g.akamai.net.

    Escape character is '^]'.

    HTTP/1.0 408 Request Time-out

    Server: AkamaiGHost

    Mime-Version: 1.0

    Date: Sun, 26 Dec 2004 13:39:08 GMT

    Content-Type: text/html

    Content-Length: 163

    Expires: Sun, 26 Dec 2004 13:39:08 GMT

    <HTML><HEAD>

    <TITLE>Request Timeout</TITLE>

    </HEAD><BODY>

    <H1>Request Timeout</H1>

    The server timed out while waiting for the browser's request.<P>

    </BODY></HTML>

    Connection closed by foreign host.

    and

    % telnet www.spamcop.net 80

    Trying 166.90.133.200...

    Connected to a369.g.akamai.net.

    Escape character is '^]'.

    HTTP/1.0 408 Request Time-out

    Server: AkamaiGHost

    Mime-Version: 1.0

    Date: Mon, 27 Dec 2004 12:40:38 GMT

    Content-Type: text/html

    Content-Length: 163

    Expires: Mon, 27 Dec 2004 12:40:38 GMT

    <HTML><HEAD>

    <TITLE>Request Timeout</TITLE>

    </HEAD><BODY>

    <H1>Request Timeout</H1>

    The server timed out while waiting for the browser's request.<P>

    </BODY></HTML>

    Connection closed by foreign host.

    Fatal error in process.


  14. ...

    But the answer is clear that this Frank1976/126.com/bp2-rx address is one to stay away from if you're just a pawn like me. And I've learned to only check the boxes at the very top.

    22861[/snapback]

    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


  15. It will probably do no good to contact anyone regarding bp2-rx.com as it belongs to Michael Lindsay / iMedia Networks a very wll known ROKSO listed spammer, check out http://www.spamhaus.org/rokso/listing.lass...edia%20Networks

    canonical name bp2-rx.com.

    addresses 211.158.35.246

    Running his "Bullet Proof" hosting out of China

    211.158.35.246 is listed in the SBL, in the following records:

    http://www.spamhaus.org/sbl/sbl.lasso?query=SBL19859

    http://www.spamhaus.org/sbl/sbl.lasso?query=SBL10264

    http://www.spamhaus.org/sbl/sbl.lasso?query=SBL21421

    All he will do is spam you more when he finds out you don't want it.

    22843[/snapback]

    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).


  16. 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.


  17. The real spammer's site is at IP 200.146.101.107 and correspond to the wildcarded address for the ...

        Also, despite this site being in Korea, ...

    22774[/snapback]

    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).


  18. I'm guessing that "Saving links for later processing" really means "Ooh, look, a shiny new link (one whose IP Address I haven't resolved with this new code before).  Let me just save it by adding it to this new database of links and IP Addresses (or new IP Address field in an existing database of links) Julian made for me to combat spammers' new DNS shenanigans.  Ok, it's saved, moving on..."  If it does, thanks, Julian!

    The sporadic appearance of it would be because some links have already been saved and some haven't.

    22756[/snapback]

    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.


  19. the same guy who wrote vixie-cron?

    22735[/snapback]

    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).


  20. Please stop doing your own word-wrapping, you're hurting my eyes.  Thanks!

    22696[/snapback]

    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


  21. Seems to be fixed now?  I don't get that response when I check it now.

    22693[/snapback]

    No, it has not been fixed, which 'whois' client used makes all the difference. Many clients "dump" data returned before the registrar's identifier. For instance, on the box I'm typing on, 'jwhois' doesn't show the issue, but simple 'whois' does. Try checking the web page at the Internic (i.e. wdprs.internic.net), this should behave identically for all systems (MS or *nix); It currently returns:

    Current Whois Data

    REGISTRAR WHOIS:

    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 7-Jan-2005 03:43:23 EST.

    Domain servers in listed order:

    NS1.RISEMULTIMEDIA.COM 216.111.65.217

    NS2.RISEMULTIMEDIA.COM 205.171.16.250

    REGISTRY WHOIS:

    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: Thu, 6 Jan 2005 19:17:15 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.

    Registrar: NETWORK SOLUTIONS, LLC.

    Whois Server: whois.networksolutions.com


  22. At the expense of being the only respondent to my own post. This morning a spam with a unique

    variation appeared; 'CNAME'' instead of 'A' wildcarded DNS records.

    example:

    % dig '*.oemlist.com' any [at]ns3.xml-soft.info.oemlist.com.

    ; <<>> DiG 9.3.0 <<>> *.oemlist.com any [at]ns3.xml-soft.info.oemlist.com.

    ;; global options: printcmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9281

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

    ;; QUESTION SECTION:

    ;*.oemlist.com. IN ANY

    ;; ANSWER SECTION:

    *.oemlist.com. 120 IN CNAME oemlist.com.

    ;; AUTHORITY SECTION:

    oemlist.com. 120 IN NS ns3.xml-soft.info.oemlist.com.

    ;; Query time: 239 msec

    ;; SERVER: 195.85.213.146#53(ns3.xml-soft.info.oemlist.com.)

    ;; WHEN: Thu Jan 6 10:50:26 2005

    ;; MSG SIZE rcvd: 77

    What is needed is for the parser to check for wildcards in the all domains containing the URI short of

    the TLD. Otherwise simple math will allow a spammer to use 3 runs of a million spams, and a hundred

    unique hostnames, and be able to distinguish each reporter (or 9 runs with only 10 hostnames).

    Combined with "steath" DNS and a hundred domains the parser would never accumulate enough

    reports for a single host to report it. Combine 10 wildcarded 'A" or 'CNAME' records with 5 or 6

    different addresses and a run could be complete before ever being recognized (reports would believe

    that different virtual host sites were used, and decrease in this case by a factor of 50-60x).

    Additionally, it should be necessary, if a wildcarded 'A' record or 'CNAME' is found, for the URI in the

    spam to be obfuscated to use a '*' or other identifier instead of the original unmunged link. (Sorry, don't

    know what to do about "fake" affiliate-like idenifiers tacked on the tail for identification -- example:

    ht_tp://sitea.subd.spammer.biz/?xyz678IknowYou


  23. 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


  24. Anyone know/heard about the crap at http://www.faxo.com ???

    ...

    Directly from the internic (where registrars, in principal, can't lie):

    REGISTRAR WHOIS:

    Registration Service Provided By: e2e Partners, Inc.

    Contact: steveu[at]e2epartners.com

    Visit:

    Domain name: faxo.com

    Administrative Contact:

    e2e Partners, Inc.

    Steven Urciuoli (steveu[at]e2epartners.com)

    +1.3144773237

    Fax: +1.3147549189

    743 Spirit 40 Park Drive

    Suite 250

    Chesterfield, 63005

    US

    Billing Contact:

    e2e Partners, Inc.

    Steven Urciuoli (steveu[at]e2epartners.com)

    +1.3144773237

    Fax: +1.3147549189

    743 Spirit 40 Park Drive

    Suite 250

    Chesterfield, 63005

    US

    Technical Contact:

    e2e Partners, Inc.

    Steven Urciuoli (steveu[at]e2epartners.com)

    +1.3144773237

    Fax: +1.3147549189

    743 Spirit 40 Park Drive

    Suite 250

    Chesterfield, 63005

    US

    Registrant Contact:

    e2e Partners, Inc.

    Steven Urciuoli (steveu[at]e2epartners.com)

    +1.3144773237

    Fax: +1.3147549189

    743 Spirit 40 Park Drive

    Suite 250

    Chesterfield, 63005

    US

    Status: Locked

    Name Servers:

    NS1.UUNU.COM

    NS2.UUNU.COM

    Creation date: 30 Dec 2002 08:07:52

    Expiration date: 30 Dec 2005 08:07:52

    Also note the DNS is designed to cause timeouts (refresh time is greater than expire time).

    % nslookup -type=any faxo.com ns1.uunu.com.

    Server: ns1.uunu.com.

    Address: 69.155.184.153#53

    faxo.com mail exchanger = 10 mail.faxo.com.

    faxo.com

    origin = ns1.uunu.com

    mail addr = hostmaster.faxo.com

    serial = 6

    refresh = 70

    retry = 60

    expire = 60

    minimum = 60

    faxo.com nameserver = ns1.uunu.com.

    faxo.com nameserver = ns2.uunu.com.

    Name: faxo.com

    Address: 69.155.184.152

    AND

    % nslookup -type=any mail.faxo.com ns1.uunu.com.

    Server: ns1.uunu.com.

    Address: 69.155.184.153#53

    Name: mail.faxo.com

    Address: 69.155.184.154

    Also,

    % nslookup -type=any ns1.uunu.com. ns1.uunu.com.

    Server: ns1.uunu.com.

    Address: 69.155.184.153#53

    Name: ns1.uunu.com

    Address: 69.155.184.153

    % nslookup -type=any ns2.uunu.com. ns1.uunu.com.

    Server: ns1.uunu.com.

    Address: 69.155.184.153#53

    ns2.uunu.com canonical name = mail.uunu.com.

    --- Very questionable setup, seems fully intended to obscure attempts to trace. Lots of interesting

    DNS "tricks".

×