[RFCI-Discuss] Rejected listing for gruver.net (was RFCI-Discuss Digest, Vol 40, Issue 5)

[Eric Johnson]

On Sat, 13 May 2006 10:27:33 -0700 (PDT)
Administrative Account <hostmaster at Plectere.com> wrote:

> 	Well I guess somehow I got on the same "narrowly" tailored
> 	blocklist.
> All I see is a *v-e-r-y* slow 220 and the same tarpit behavior.

There is a 10 second (default) stutter on connections.  This is because
of claimed observations that many spam daemons detect a stutter in 10
seconds or less and give up.

For example, from
http://archives.neohapsis.com/archives/openbsd/2005-04/0557.html

	Greylist connections used to be always talked to at 
	full speed. You don't want to delay them overly, 
	because that hurts people you talk to the first time, 
	However, no real mailserver is really going to to 
	notice a 10 second network slowdown. The spammers, 
	however, do now, a lot of them do. This diff makes 
	spamd greylisting stutter at all greylisted 
	connections for the first 10 seconds, and then talk 
	full speed after that. This means that according to 
	my stats on my servers right now, about a third of 
	the bot-generated spammers who currently hit your 
	greylist and just might be smart enough to retry, 
	give up before they even attempt to send a message. 
	That's nice. Means they have to put up with the 
	possibility of being tarpitted in order to talk to 
	you. It seems to be very effective in practice.

The man pages for spamd, 
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&sektion=8
are dated December 18, 2002 and don't fully reflect this 
change:

 	-S secs
 		Stutter at greylisted connections for the 
		specified amount of seconds, after which 
		the connection is not stuttered at.  Defaults
		to 10.
   
	...

	With this configuration, spamd-setup(8) should be used 
	to configure blacklists in spamd and add them to the 
	spamd pf(4) table.  These connections will be stuttered 
	at by spamd.  All other connections not in the
	spamd-white table are redirected to spamd but will 
	not be stuttered at.  Such connections will be 
	considered for greylisting and eventual whitelisting 
	(by addition to the spamd-white table so they are not 
	redirected) if they retry mail delivery.

The stutter may be easily modified or turned off.  After sending this,
I'll remove it and see if it seems to make any difference.

You all have got me curious about why it displays the messages instead
of a simple

	451 Temporary failure, please try again later.

as the man pages indicate should be displayed.  I never really thought
about it before.

Time to check out the code.  (Of course, it might have already been
changed on OpenBSD 3.9 which was released a couple of weeks ago.)

Eric Johnson