: -----Original Message-----
: From: current-users-owner@NetBSD.org 
: [mailto:current-users-owner@NetBSD.org] On Behalf Of Steven 
: M. Bellovin
: Sent: Thursday 26 February 2004 05:28
: To: Aidan Kehoe
: Cc: NetBSD-current Discussion List
: Subject: Re: Spam suggestion... 
: 
: 
: In message <16445.53295.384677.41566@gargle.gargle.HOWL>, 
: Aidan Kehoe writes:
: >
: >  Rendering all spam traceable is
: >significantly improved functionality.
: 
: Really?  What good does tracing it do?  What are you going to do with 
: the information?  
: 
: I get hundreds of spam messages a day.  I can't spend the 
: time finding 
: out who owns the system and notifying someone responsible -- if, 
: indeed, they'd even listen.  (I went to the trouble of figuring out 
: which of my wife's correspondents had a worm-infected machine 
: that kept 
: bestowing its "gifts" on my wife's inbox.  My wife passed along the 
: information.  The only response thus far has been several more copies 
: of the worm...)

Let me get this straight...

"SPF is useless because tracing spam is useless, because even if we
can trace it, we cannot filter on the discrepancies which would
accurately
mark it as spam, because SMTP has the flaw in which we must either
reject
based on some sort of authentication of increasingly nebulous, and thus
increasingly ineffective, nature, or we must accept, and thus read, an
entire
message, regardless of size, before we decide on its disposition."

To put it bluntly, SMTP as it stands has outlived its utility.  

I think SPF is just an attempt at a bridge towards a better mail
protocol.
SMTP as it stands has been rendered nutless when it comes to being able
to
control (read: deny) mail transfer, because the conditions for filtering
acceptance are too easily spoofed or must be too draconian to be useful.
By the time you decide to accept the mail, you must accept the whole
message.
That's too late -- you've already been soaked for the bandwidth.

The mail transfer protocol *really* needs to be updated.  A multi-phase
acceptance would be helpful (host auth, sender auth, header vs.
host/sender
sanity check, and finally data).  Pretty much anything which could force
the
headers and the authentication to match up would be a step in the right
direction.  There must be something to be done.  I could just disallow
foreign subnets smtp access at my firewall, but my other MX hosts would
have to do the same, and there's no guarantee that will happen.

And I don't know what list this belongs on; regardless of common
interest,
I somehow don't think it belongs here (or is that what about four others
have said?  And I'm oblivious to it for this reply; sorry.  I'll mind
myself
in the future -- just point me to the right forum).

: 		--Steve Bellovin, http://www.research.att.com/~smb