RE: spamcop
On Thursday, September 21, 2006 8:49 PM -0500, John Kelly wrote:
> On Thu, 21 Sep 2006 16:33:26 -0500, "Seth Goodman"
> <sethg@GoodmanAssociates.com> wrote:
>
> > > But once you get a grip and hang on for a while, you realize
> > > that sacrificing 2% is a piece of cake.
>
> > If users value reliably getting their messages more than they
> > value spam reduction, which seems to be the case, it will cost
> > you. Large system admins are not fools. They have tried this
> > and people don't accept it.
>
> Is that your experience, or speculation?
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.
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 :) 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. Taking a hard-line here would prevent many people
from operating a useful mail server. This is the same reason that the
sensible RMX proposal for tagging hosts that are permitted to send mail
on behalf of a domain failed: the reverse DNS system is in poor
condition in many places.
People have known for quite a while that forcing systems to take
responsibility for their outbound mail flow is the primary issue. That
means forward DNS, reverse DNS and EHLO name should all agree. It also
means that MTA's must control submission rights, either by IP or
preferably with SMTP AUTH, so users can also submit mail remotely.
Furthermore, MTA's can limit the use of sender identities to those that
the submitter has a right to use. If your network includes insecure
systems, it is prudent to force them to submit mail to a smarthost and
use both virus and spam filters on outgoing traffic. That small set of
best practices would both make it easier for sending MTA's to curtail
abuse and then take responsibility for what they send. 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.
--
Seth Goodman
Reply to: