Re: Principles of Spam-abatement

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

 



On Tue, 2 Mar 2004, Michael Thomas wrote:

>  >    Case 3: an external agent screens everything;
> 
> This is the only case that is "new" in the sense
> that there isn't any standardized way to do this
> now.
> 
>  > > Well, I don't understand because it sure seems to
>  > > me that the principle requires omniscience in
>  > > isolation...
>  > 
>  >    No more so than the three cases listed above
>  >   (or others not listed).
> 
> Like what? If the principle only leads to exactly
> one new thing you can develop toward, then there

And this isn't new either -- it is in widespread use at many different
levels today.  There are excellent reasons for it NOT to be
functionally/operationally standardized; the only aspect that can
reasonably be standardized is its "required" insertion as part of the
MTA as opposed to as a user agent.

This has been discussed, but I really don't think it has been discussed
enough, if this is the only significant outcome of a list of oblique
"principles" designed to lead to some sort of spam-resistant email.
First of all, it is impossible, literally, in protocol, to prevent MUA
spam filters from being inserted into the pipeline between MTA and mail
spool and user.  Second, filters have to be psychic to work perfectly,
so they won't work perfectly -- "consent" is a silly term to apply per
piece of mail, although not so crazy at the network level or host
level.

Third and perhaps most important, did it not occur to you that you just
used three metaphors drawn directly from telephones?  Three FAILED
metaphors from the point of view of controlling phone spam?  Phone spam
continued its time and resource expensive trail across the world until
it was prohibited by law in a way that held phone spammer's accountable
-- caller-id was a joke, call screening (letting it pick up and
listening to the message to decide whether to actually answer) cost time
and was annoying.

I repeat -- what is needed now is not significant changes to smtp (not
if one makes those changes expecting to abate spam or viruses).  What
MAY be needed is a way of tightening up the mapping between positively
identified humans, their positively IP addresses, and a mechanism for
refusing to route traffic from rogues.  ALL traffic, not just smtp.

The URL I posted a couple of days ago had a set of 'principles' for
doing just that.

I spoke of the metaphor that the Internet is like having every bad
neighborhood in the world metaphorically sitting just outside your front
door, since from the user's point of view there are "equal" routes from
every system to every system on the planet.  The only way I can think of
to abate spam and viruses and all sorts of nuisance traffic is to
engineer a way of making this no longer so -- to disconnect the bad
neighborhoods until they hire police and post agents at their own major
intersections to keep the riff-raff (spammers and abusers) and crazy
folk (virus infected ravers) off the street.  This doesn't even require
new law -- it just requires a reexamination of the notion of AUA and the
insertion of a new agency enabling the rapid disconnection of any given
branch of the Internet from all routing.  There are lovely reasons to
think about such an agent anyway -- it provides a rapid response
mechanism agains technoterrorists, for example.

One day I WILL put forth a bit of a diatribe about the difference and
barriers between evolutionary change and revolutionary change, and how
one is easy and slow but reasonably effective and how the other is
(generally) strongly resisted as an argument for why smtp might evolve
but very likely isn't going to be replaced by something radically
different, but not just now.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@xxxxxxxxxxxx





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]