[Spambayes] Bouncing Spam

[Bill Yerazunis]

   Organization: WoozleWorks (woozle.org)
   X-Thought: If I had a computer like that, I wouldn't need friends either.
   X-PGP-Key-Fingerprint: A862 F105 13EF 7FAF 4F08  78B4 9168 856B 48BF F157
   X-Callsign: KD7OQI
   From: Neale Pickett <neale@woozle.org>
   Date: 27 Nov 2002 09:41:53 -0800
   cc: Spambayes <spambayes@python.org>
   Sender: spambayes-bounces@python.org
   X-Spam-Status: No, hits=-12.8 required=7.0
	   tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,
		 SPAM_PHRASE_01_02,USER_AGENT
	   version=2.41
   X-Spam-Level: 

   So then, Tim Stone - Four Stones Expressions <tim@fourstonesExpressions.com> is all like:

   > Well, ok then, the question arises as to whether or not spambayes
   > should offer some functionality that is integratable into MX agents,
   > or an MX agent proxy, or something like that, that is spambayes
   > enabled, for webmasters or others who administer such things...  I
   > certainly wouldn't have the slightest idea how to make such a thing,
   > but it seems reasonable.

   Can't.  You have to send the 5xx response before any message data,
   including headers, is even sent.

I used to think that- in fact, it's _not_ necessary.  You can bounce after 
the "data" / 354 "message text, end with '.' on a line by itself" exchange.

    By the time they've sent the whole
   message and you get to tokenize it, the spammer has moved on to the next
   victim.  If they don't care about bounce mail they're not going to care
   about 500 errors after they've sent the entire message.

My understanding (having it beat into me by people who do RFC2821/2822
for a living, including some of the original implementors back at
the 821/822 level) is:

 1) tme spammers do in fact "pipeline" and not wait for any error
     messages, but:

 2) it's a violation of the RFC to not wait for the 250 OK message
     from the recipient's server, and any mail sender that doesn't
     wait for the 250 OK cannot expect reliable delivery, hence it's
     OK for us to toss the spam rather than doing the
     otherwise-required deliver-or-bounce-without-fail.

 3) it _is_ legitimate to return a 55x error code after message data.

 4) it's actually desirable that we 5xx after the data, that way
    a legitimate sender (i.e. a false reject) will get a bounce 
    message from their MTA and will know to retry the messae or
    use another medium, rather than expecting the nominal "deliver
    or bounce but never just drop" behavior.

At least, I've been beat up on another list enough about it, and
re-read the RFC with the bloody nose enough to believe them.  :-)

Read section 4.1.1.4 DATA (DATA) of RFC2821 at:

    http://www.faqs.org/rfcs/rfc2821.html

and also section 4.2.3, same URL, for the list of nominative reply
codes.  550 is reasonable to use for rejection, 554 is also 
reasonable.

If you wanted, you could even split out Nigerians and other 
make.money.fast scams, and vector those as in:

  551 User not local; please try uce@fcc.gov		

which might have interesting consequences.  :-)

      -Bill Yerazunis