Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

933 profile views

GraemeL's Achievements

Advanced Member

Advanced Member (3/6)



  1. OK, I see your problem now. This is going to be pretty technical, but it should make sense to your IT staff. The replies are correct given the queries that your server is sending, but the queries are meaningless. When querying a blocklist, the quads are reversed. If I want to test the IP address, the query actually gets sent as So the IP address you are querying isn't (which does belong to HP) but which is in IANA reserved space. This would seem to indicate that the mail server that you're attempting to do the lookups from doesn't receive mail directly from the internet, but instead gets it from another server which is connected to the internet and then relays it over your internal network. Since the sort of lookups that you're attempting only ever check the address of the machine that is involved in the current SMTP transaction, all your lookups will be for One solution would be to do the RBL checks on the external gateway. I'm assuming that your setup looks something like this: Internal server <---> External gateway <---> Internet So all checks on the internal server will always check the address of the external gateway. If you can do the tests at the external gateway, you will be testing the address of the machine on the internet that is trying to send you mail.
  2. Here are responses to an unlisted and a listed address formatted by dig. You can see how the formatted data relates to what you're seeing in your packet captures. Unlisted dig ; &lt;&lt;&gt;&gt; DiG 9.3.1 &lt;&lt;&gt;&gt; ;; global options: printcmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 63664 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; AUTHORITY SECTION: zen.spamhaus.org. 900 IN SOA need.to.know.only. hostmaster.spamhaus.org. 2007120407 3600 600 432000 900 ;; Query time: 193 msec ;; SERVER: ;; WHEN: Tue Dec 4 02:00:09 2007 ;; MSG SIZE rcvd: 108 Listed dig ; &lt;&lt;&gt;&gt; DiG 9.3.1 &lt;&lt;&gt;&gt; ;; global options: printcmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 35876 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 23, ADDITIONAL: 3 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: 1357 IN A 1357 IN A 1357 IN A ;; AUTHORITY SECTION: zen.spamhaus.org. 46681 IN NS c.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS d.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS f.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS g.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS h.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS i.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS k.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS l.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS m.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS n.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS o.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS q.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS r.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS s.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS t.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS x.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS y.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 1.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 3.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 4.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 8.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS a.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS b.ns.spamhaus.org. ;; ADDITIONAL SECTION: 1.ns.spamhaus.org. 10373 IN A 1.ns.spamhaus.org. 10373 IN A 3.ns.spamhaus.org. 10373 IN A ;; Query time: 72 msec ;; SERVER: ;; WHEN: Tue Dec 4 02:00:17 2007 ;; MSG SIZE rcvd: 511
  3. NXDomain is the reply you should expect to see if the IP you are testing is not listed on the blocklist you're testing against.
  4. Not quite sure from your description, but I may have an explanation for you. Early fast ethernet was all 100BASE-T which was half duplex (i.e. single channel over a single twisted pair). This wasn't a problem for most users, but in some applications there was a need for fast bi-directional data exchange. One solution was to make a device with two 100BASE-T connections and tie them together in such a way that they appeared to be a single full duplex interface. One channel for uplink and one channel for downlink. 100BASE-TX came along with full duplex (two channels over two twisted pairs) and made the kit obsolete. Cat-5 contains 4 twisted pairs, so you could run two 100BASE-TX connections over it, splitting out the pairs to two RJ45s at each end or doing some magic in the NIC.
  5. You may well still get complaints people using your proxy to comment spam or using it to launch attacks against other systems. I hope your ISP is understanding. I wont even comment on the possible liability issues.
  6. David is correct. The open proxy is your problem, kill it and you will stop relaying spam.
  7. The cbl (and njabl) data is added to zen (actually to xbl which is included in zen) by regular zone transfers and not in real time. The xbl FAQ says the transfers happen every 15 minutes. Personally, I only used zen at the MTA for a short time before going back to querying cbl, njabl, pbl and the sbl. Both njabl and cbl are extremely dynamic and I had a noticeable increase in leakage when querying zen.
  8. They blocks are actually in RIPE address space (not APNIC as claimed by the article) and still seem to be allocated to RBN front companies. They all have registration addresses in China/Hong Kong/Taiwan and were being advertised via Chinese ASs (Spamhaus list). Strange that the Chinese seem to be willing to host so many scams, but stopped advertising the RBN space so quickly. If only somebody at RIPE would look into the companies behind the allocations and ask them to prove that they actually have legal business addresses (not PO boxes) in the RIPE area. If they don't, the allocations violate RIPEs own rules. On the bright side, Yambo Financials may still be pumping out the spam, but their domains all resolve to RBN space that's not currently routable. Edit to add: Oops, forgot to mention that there is a blog dedicated to tracking the activities of the RBN.
  9. If you have a SpamCop email account and have Thunderbird configured to connect to both Spamcop and Gmail via IMAP, then it's all very simple. All you need to do is select the spam in gmail, right click -> move to -> Spamcop -> Inbox -> held mail. Then go to your reporting page on Spamcop and either quick or normal report it. No messing around with plugins or forwarding. Oh, remember to set up your mailhosts for Google too.
  10. Mi havas sufiĉ de problemo pri La angla kaj estas mia denaska lingvo.
  11. This has been a tough learning experience for Pedro, but I think he's about to come to the end of it now. He now has: Updated anti-virus software on his machines. A firewall installed. Removed all obviously weak user/password combinations. The Senderbase statistics for today show a 0.0 magnitude for his IP address. I have made a few more recommendations to him in PMs, but everything that I would consider critical has now been taken care of. Although it took longer than would have been optimal, I think we're close to closing this one off now. Thanks to Pedro for working through getting his systems cleaned up.
  12. I've tried several methods for seeding spam traps. The address I seeded by filling out unsubscribe forms was by far the most successful and accounts for over 80% of my spamtrap hits.
  13. He doesn't have a firewall... He now knows that that was a bad decision and (I think) has people working to rectify it.
  14. Every bit of it needs to include alternate data streams on every file on the box. You should also do a full scan with Rootkit Revealer. Even if those checks were run, my level of confidence in the integrity of the box would still be low. Once there is a chance that the box has been compromised, you can never be sure that it can be trusted. I replied to your other point in a PM as it included sensitive information.
  15. Correct. I've exchanged a couple of PMs with him in the last 24 hours going into more detail, which is why I didn't reply to the thread here again.
  • Create New...