[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: spamcop



On Fri, 22 Sep 2006 13:16:23 -0500, "Seth Goodman"
<sethg@GoodmanAssociates.com> 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.






Reply to: