Subject: One SPAM side effect

From: Bob Braden <[email-masked]>
Date: Fri, 16 Aug 2002 19:35:40 GMT

I have an interesting (if that's the word) example of how the current
storm of spam can really gum up the works.  The RFC Editor has for 20
years been running an automated SMTP server for searching and
retrieving RFCs and other online documents.  It is still used 10-20
times in a typical day.  In the past size months, and with increasing
frequency, this daemon has been breaking due to spam.

What happens, apparently, is that a spammer sends a message to the RFC
Editor server, purporting to come from a site that is in fact another
automated SMTP servers.  Each server is very polite, responding with an
error message including the entire request message.  So they go into a
loop, being very polite to each other... This loop continues until
either our disk gets full from the log files or real requests get
completely squeezed out by this bogus traffic.  We do notice, after a
few days...

I don't know how many other SMTP-based servers there are, but the
server at the IETF web site has gotten us twice, and yesterday we got
into a tango with an email-based computational server at the
Computational Biochemistry Research Group (CBRG) at the ETH in Zurich,
as in:
	"PepPepSearch
	 AminoAcidSequence (may be in several lines)

	   Search the given amino acid sequence against the entire
 	   SwissProt peptide database using Smith-Waterman's version.."

Needless to say, the RFC Editor's site did NOT wish to do a peptide or
amindo acid search, but it was very persistant in NOT wishing to.
Nor did the ETH folks REALLY want to look up an RFC, but they were
equally persistant in not doing so.

So, this is amusing in a way, but it is also a royal pain.  Of course
we can put in better spam filters and some smarter mechanism to
recognize and break a loop, but like most of you I have better things
to do with my time.  One solution would be to give up on automated SMTP
servers in the Internet, removing useful services for a lot of people.

Bob Braden

---

From: Randy Bush <[email-masked]>
Date: Fri, 16 Aug 2002 13:22:05 -0700

rfc1123

      5.3.3  Reliable Mail Receipt

         When the receiver-SMTP accepts a piece of mail (by sending a
         "250 OK" message in response to DATA), it is accepting
         responsibility for delivering or relaying the message.  It must
         take this responsibility seriously, i.e., it MUST NOT lose the
         message for frivolous reasons, e.g., because the host later
         crashes or because of a predictable resource shortage.

         If there is a delivery failure after acceptance of a message,
         the receiver-SMTP MUST formulate and mail a notification
         message.  This notification MUST be sent using a null ("<>")
         reverse path in the envelope; see Section 3.6 of RFC-821.  The
         recipient of this notification SHOULD be the address from the
         envelope return path (or the Return-Path: line).  However, if
         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
         notification.  If the address is an explicit source route, it
         SHOULD be stripped down to its final hop.

randy

---

From: Aaron Falk <[email-masked]>
Date: Fri, 16 Aug 2002 13:33:10 -0700

> equally persistant in not doing so.

The consequences of such behavior are thoroughly documented in
"The Forbin Project" (http://us.imdb.com/Plot?0064177).  ;)

--aaron

---

From: "Perry E. Metzger" <[email-masked]>
Date: 16 Aug 2002 18:26:53 -0400

> servers in the Internet, removing useful services for a lot of people.

The spammers are destroying the usefulness of enormous amounts of
wonderful infrastructure. Time for everyone to get on the phone with
their congressman and ask them if they are interested in what 98% of
the planet wants or what the Direct Marketing Association wants.

Perry

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Aug 2002 15:49:19 -0700

>the planet wants or what the Direct Marketing Association wants.

In the form you present it, Perry, this is an incredibly bad suggestion.

What it will most likely do is create a frankly hysterical response from 
Congress, with the most likely effect being censorship.

Congress does not invent answers.  They ratify them.

A coherent community needs to develop a coherent, workable, useful proposal 
and THEN contact Congress (if passing laws is required.)

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 20 Aug 2002 10:33:01 +0200

this mode of breaking is all too well known.

At one time (before RFC 2000), we tried to get a document out that 
specified rational behaviour for mail robots, including a near-absolute 
prohibition on the robot sending mail where FROM: pointed to an address 
that would elicit an automated response (such as the address of the server 
itself).

The effort, like too many other good things, was lost in the mists of time.

Note: Some heavily-safeguarded versions like Listserv's confirm messages 
can be OK - but in general, adding "-errors" to that From: line is a Good 
Idea nearly 100% of the time.

                       Harald