Best of the ISP-Lists

General

Monitoring E-Mail Monitors

ISPs are using larger and larger numbers of lists of spammers to fight spam, but are finding that some anti-spam systems have to be watched carefully.

[September 29, 2003]

On the ISP-Tech list in September, JD asked:

What do you guys recommend for RBL lists? I have been having horrible luck with these freebie lists. They seem to just put anyone they want on them.

[PH observed] "I recommend certain of these lists. The thing to do is to read up on what their parameters for being listed actually are. For example SPEWS lists the hosting ISP if the ISP doesn't stop the spam (first time) or disconnect the spammer (second time or well known spammers). If that is not what you want to block mail on, then you should not use that list. Your network; your rules. The thing to do is be well aware of what the differences in DNSBLs really are."

[ISP-Planet suggested] "Are you using anything to complement RBLs? There are a lot of options. See ISP-Planet's (growing) directory and this recent article: The Spam Conundrum."

LC had several detailed recommendations:

You can enforce various levels of credentials compliance or error against compliance with RFCs, "best practices", for SMTP behavior and DNS setup, and block 1000s of spammers.

1. PTR hostname. AOL now rejects mail based on the single criteria of NOT having a PTR hostname. If that's good enough for AOL, why isn't if good enough for you?

About 35 percent of MTA IPs have no PTR, so none of those IPs can send to AOL. And probably 99+ percent of the 35 percent are spammers.

Think about it a minute: what business mail server purporting to be legitimate in late 2003 doesn't have any PTR record? It will have horrendous problems sending mail, so I see no problem in me contributing to their mail-delivery problems. : )

2. HELO hostname

a. must say the HELO command, else reject

and the HELO command:

b. must have a hostname, else reject

c. it must be valid characters, else reject

d. it must be a fully qualified domain name, else reject. (domain.TLD)

e. it must not contain IP address /a.b.c.d/

f. it must not contain a domain in /mydomains/

g. it must be a domain.TLD with either an A or MX record in DNS, else reject (VeriSign's SiteFinder made this test useless)

3. MAIL FROM: sender@sender.domain

a. sender.domain must be valid characters, else reject

b. sender.domain must fully qualified hostname, else reject.

c. sender.domain must have an A or MX record, else reject (VeriSign's SiteFinder made this test useless)

d. The MX for sender.domain must accept mail to sender@sender.domain. You must accept @. But, if a sender@ is presented, then:

d.1 If the sender.domain=B4s MX says sender@sender.domain is an unknownuser, reject (forged sender)

d.2 If the MX of sender.domain is not "reachable", reject with 450. (may be a transient network/DNS/etc. problem)

(the preceding test is called sender_address_validation and is effective when all preceding tests pass).

I would assume that every single Imail admin that follows this list will have Imail (and DNS) in perfect shape and be able to send mail to any MX that is imposing the above credentials. And if you can do present impeccable credentials to other mail servers, the why can't every business mail server present you with the same credentials?

A big problem is forgeries of the above info (except PTR hostname, I have not seen that, yet).

Two-criteria tests cut down on forgeries of BigISP (hotmail, aol, msn, compuserve, yahoo, lycos, earthlink, netscape, etc):

If your helo hostname is [bigisp], then your PTR hostname must be [bigisp].

If your sender@sender.domain is [bigisp], then your PTR hostname must be [bigisp].

If your PTR hostname is [bigisp], then your @sender.domain must be [bigisp]

If your PTR hostname is [subscriber access network], then you are 99+ percent probably a spammer.

If your @sender.domain is [one of 3500 frequently domains at monkeys.com], then your A and PTR records must "match" each other (but not have to match the sender.domain).

[DB noted] "where you say a. must say the HELO command, else reject Or EHLO, some of us use ESMTP where possible."

[DT worried] "Actually I run my business (like a lot of people) from a relatively small DSL connection and use DDNS. Personally I just think SMTP has had it and we need something more like SMTP plus SSL with handshaking and certificates."

[PH replied] "And how do we make sure spammers don't get certificates? Or should we have a CA we really really really really trust to not issue certificates to spammers (as opposed to Verisign and their ilk)?"

[DT admitted] "I don't have all the answers. The point is that if a company has to prove their identity to get a certificate spam can be tracked, if a CA issues certs to spammers the CA can be removed from the registered CA list so it's not in their interest to allow falsely identified certs to be issued or their business becoimes worthless."

[CF complained] "Collateral damage on a whole new level. Now it's not everyone else on this class-C that gets blocked when one person spams, but 1/8th of the world when $HUGE_CERT_COMPANY issues certs to spammers.

To change the wording a bit of ABC news Vice President: "Spammers would not declare the spam." Just like Terrorists wouldn't declare they are trying to import uranium, Spammers wouldn't tell the CAs that they plan on spamming with that certificate.

I don't have a solution for stopping spam. But I do run SpamAssassin, SpamBouncer and DNSBLs to filter my e-mail. When there is a solution (Probably in SMTPv3 or so) I will be extremely happy."

[ZZ opined] "I have found Mdaemon mail server more than sufficient with its spam fighting abilities as a stand alone product for Windows, and an excellent outsourced and very affordable solution even for a small ISP from a company I deal with."

—End