[ On Mon, August 4, 1997 at 12:43:29 (-0400), Dana Hudes wrote: ]
Subject: Re: Summary of ANTI-spam techniques now available
(And this from huge players who should have implemented filter
rules to prevent their users from doing ip spoofing and from
using mail servers other than UUNET and other authorized
servers).
Ah! The opening line I was looking for! 
As some of you may know I'm both an avid anti-abuse campaigner and the
principal maintainer of smail-3 to which I'm adding various capabilities
to assist in the fight against spam.
One of the obvious things to do, of course, is for the mailer to protect
itself against illegal third-party relay abuse.
Unfortunately a number of the "huge players" are for some reason failing
to implement such anti-relay protection. This is likely due to the fact
that many of them have painted themselves into a corner too often
visited by big operations -- i.e. they cannot quickly and safely evolve
their operating software base.
The other issue mentioned by Dana is the fact that everyone (esp. the
"huge players"!) should have already implemented anti-spoofing IP
filters and should also be preventing dial-up customers from connecting
to anything but the providers authorised mail gateways on port 25.
(I still don't know why routers don't default to minimum anti-spoofing
and private net filtering rules!)
In every spam report I send to providers who have been either subjected
to relay abuse, or who have been the source of connections from their
dial-up customers to the abused relay host, I try to suggest these
measures as a means not only to reduce the abuse that is possible
without them, but also as a means of reducing the load on their
postmasters and customer support departments.
From private face-to-face discussions I've had with several "huge
players" I've discovered that the failure to enforce use of authorised
mail gateways is also sometimes due to the "painted into the corner"
syndrome where the networks and systems supporting dial-up operations
and mail gateways have grown "organically" without consideration and
planning for enforcement of AUPs and other such logical things. Others
are concerned with the CPU cycles necessary to implement such filters.
I'd like to open a discussion of these issues in this group from an
operations point of view (i.e. not the politics, but rather the issues
involved with implementation and maintenance).
Please though if you want to discuss the politics of these issues (eg.
are such filters legal, "right", bad, etc.) do it only in private
e-mail.
I think we may all agree that such filters and restrictions are probably
effective ways to enforce AUPs and reduce abuse, but can we implement
them in our networks without other adverse affects and without swamping
ourselves with maintenance nightmares. I.e. all I want to know about
are concerns, issues, etc. related to how these forms of filters and
restrictions can be implemented in already existing networks and systems
that may not have been designed with them in mind (and may not have been
designed from scratch for their current purpose in the first place! ;-).