On Fri, 22 Sep 2006 13:16:23 -0500, "Seth Goodman" <[EMAIL PROTECTED]> wrote:
>I do not operate large MTA's, though I have known people who do and they >are definitely not fools. They understood that testing for forward DNS >!= reverse DNS at connection time is an extremely cheap way to reduce >the spam load. Some actually do reject for this. The reason that many >don't is the level of user complaints they experienced when they tried, >or experiences of other operators they know. Many users won't complain, because they're glad to have an INBOX free of porn spam and other garbage. For that, they don't mind sacrificing a potential 2% false positives. For users who can't overcome the fear factor, I can change their spam setting from BLOCK to TAG. Then they receive everything, garbage and all. The spam which would have been blocked, is tagged with a header "X-Delivery-Tag: UCE" followed by a descriptive reason. They can key on that for client-side filtering and/or sorting with whatever client software they prefer. But I don't get involved with that. Anyone who exerts that much effort just to avoid a few false positives, is on their own. >If most of the large MTA's implemented this policy, you would no longer >see a significant false positive rate, as everyone who could would be >forced to comply :) It's time to move in that direction. We don't need an RFC saying we MUST, we just need the collective willpower to do it. >There are still a significant number of systems in the developing world >whose providers don't delegate reverse DNS or who can't set it for you. Those users will just have to relay through a smart host, like all the dynamic cable and dsl users in the developed world. >However, even that modest set of requirements has been too much for >the largest providers to implement for fear of the breakage it would >cause. It's more fear, than breakage.