garrett.allen@comcast.net [2/7/2004 4:55 PM] :

this may be deemed off topic - if so apologies in advance. however i respect many of the opinions i see here so thought i would take a chance and ask.

we are a stub network, injesting about 30k emails daily. about a year ago we implemented a spam filtering product. it works well. recently we turned on the knob to enable it to do reverse lookups. only the mild version, a reverse is made on the ptr rr for the ip address sending the email. if it fails the spam filter issues a 421 and closes the connection. unfortunately, we have 6 sites thus far that are legitimately trying to communicate with us but don't have ptr's associated with the ip address sending emails. since it obviously isn't a requirement to have one is it generally accepted to do so? any sense for how many end networks do and don't?

Having proper rDNS is a good thing, strongly recommended but definitely not required for sending mail. There are quite a few sites (including the freebsd.org mailserver, and, on a case by case basis, even AOL) that do refuse mail from IPs without rDNS, but turning on a "must have rDNS or you can't email us" setting will definitely result in a non trivial amount of false positives. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

garrett.allen@comcast.net writes:

we are a stub network, injesting about 30k emails daily. about a year ago we implemented a spam filtering product. it works well. recently we turned on the knob to enable it to do reverse lookups. only the mild version, a reverse is made on the ptr rr for the ip address sending the email. if it fails the spam filter issues a 421 and closes the connection. unfortunately, we have 6 sites thus far that are legitimately trying to communicate with us but don't have ptr's associated with the ip address sending emails. since it obviously isn't a requirement to have one is it generally accepted to do so? any sense for how many end networks do and don't?

I've run all my mailers with aggressive PTR checks for about a year, and while some of my guests aren't getting all the e-mail that's sent to them, it's had no impact on me other than that periodically I have to tell some remote postmaster that their PTR's are missing or that they don't match the HELO hostname. Invariably they fix it. This is counter to RFC821, and also Jon's old mantra "be liberal in what you accept and conservative in what you generate." The trouble is, this is information warfare now, not a grand experiment in interoperable communications. The bad guys aren't going to be conservative in what they generate. By being nonliberal in what I accept I keep 20,000 or more malicious messages per day from hitting my personal inbox. This brings the load down to something postgresql and MH can actually cope with: lartomatic=# select date(entered),count(*) from spam where date(entered)>'today'::date-'10 days'::interval group by date(entered) order by date(entered) desc; date | count ------------+------- 2004-02-07 | 2691 2004-02-06 | 2660 2004-02-05 | 3181 2004-02-04 | 3910 2004-02-03 | 4712 2004-02-02 | 4706 2004-02-01 | 4866 2004-01-31 | 4326 2004-01-30 | 3712 2004-01-29 | 2723 (10 rows) I think the tipping point went by a while ago, and that anyone who wants their e-mail to be accepted will make sure their mail relay has a PTR and that that this PTR holds the same name used in the SMTP HELO command. -- Paul Vixie