On Wed, Sep 12, 2007 at 03:43:22PM -0600, Jason J. W. Williams wrote:
In my opinion, the first and fourth statements are not necessarily in conflict. A reputation system based purely on reverses is pretty broken.
Actually, it's amazingly reliable, when the patterns (literal string matches and regular expressions) are carefully compiled and cross-checked. One example of the thousands of patterns I block outright is *.fios.verizon.net. I do this (a) because I'm seeing lots of spam from generically-named hosts in that subdomain, e.g., within the last hour attempts have been noted from: relay=pool-71-164-205-139.dllstx.fios.verizon.net [71.164.205.139] relay=pool-71-170-104-162.dllstx.fios.verizon.net [71.170.104.162] relay=pool-71-170-70-195.dllstx.fios.verizon.net [71.170.70.195] relay=pool-71-172-239-30.nwrknj.fios.verizon.net [71.172.239.30] relay=pool-71-189-201-76.lsanca.fios.verizon.net [71.189.201.76] relay=pool-71-190-246-40.nycmny.fios.verizon.net [71.190.246.40] relay=pool-72-73-220-84.cmdnnj.fios.verizon.net [72.73.220.84] relay=pool-72-76-240-99.nwrknj.fios.verizon.net [72.76.240.99] relay=pool-72-84-85-199.nrflva.fios.verizon.net [72.84.85.199] relay=pool-72-89-97-187.bflony.fios.verizon.net [72.89.97.187] relay=static-71-183-52-18.nycmny.fios.verizon.net [71.183.52.18] (b) because I've yet to receive a single report of a false positive from this pattern after using it for a considerable period of time and (c) because Verizon seems disinclined to do anything about the problem other than have their paid professional spokesliars repeat the usual B.S., viz.: http://www.theregister.co.uk/2007/09/10/isps_ignore_strorm_worm_and_other_ma... ISPs turn blind eye to million-machine malware monster By Dan Goodin in San Francisco Published Monday 10th September 2007 06:02 GMT [...] Verizon turned down requests for an interview with a security engineer, but a spokeswoman said officials are aware of the rankings and are working to put new measures in place by the end of the year to curb the spam flowing out of its network. "We are concerned about it," the spokeswoman, Bobbi Hensen, said. "We don't like spam. We are aggressively working on that." [...] Uh-huh. This problem was reported to Verizon roughly FIVE YEARS ago, and should have, of course, been competently addressed withing a matter of days. It hasn't been. There is no sign that it will be. It's therefore been necessary for those of us enduring torrential quantities of Verizon-originated abuse to take appropriate defensive actions. Like rejecting all SMTP traffic from *.fios.verizon.net. And Verizon is merely one of the offenders -- the article cited above lists several others. I just happened to single them out for use as an example here because I found the contrast between their years-long history of utter negligence and their officially-stated position to be particularly striking. Comcast, Charter, SBCGlobal, Ameritech, Level3, SWBell, Nextgentel, Pacbell, and Qwest, just to name a few off the cuff, are equally culpable. Anyway: the use of generic rDNS patterns for outright rejection turns out to be quite effective with a very low FP rate.
Regarding the second, you're absolutely right. It's not your responsibility if a 3rd party doesn't have a rDNS entry (at all or non-generic), however the reality is you're going to have to deal with it anyway. If your customers allow you to tell the senders to buzz off and fix it, that's terrific. However, you're in a more authoritarian (IT-wise) environment than most I would suspect. Also, you risk hurting your customers. As an example, it's not a suitable answer to our law firm customers who are critically-dependent on receiving e-mail from hopelessly broken senders.
Any firm that is critically dependent on email (beyond an intranet environment) is being naive and foolish by relying on a known-unreliable communications medium. Connections fail. DNS breaks. Servers croak. Disks fill. Poor software is deployed. And the entire Internet-wide infrastructure for mail is under constant stress from spam, DoS attacks, misconfiguration, and outright stupidity (e.g. SAV). As to hopelessly-broken senders, we do not do them any favors by accomodating their brokeness. It is better in the long term for all of us to educate them about the not just the de jure, but the de facto minimum requirements for mail servers -- which in 2007 include not only functional rDNS, but rDNS pointing to non-generic hostnames. ---Rsk