Interaction between greylisting and persistent host status

Vernon Schryver
Mon Nov 17 23:13:13 UTC 2003

> From: "John R Levine" <>
> To: "Gary Mills" <mills@cc.UManitoba.CA>
> Cc: "" <>

> > The persistent host status feature is extremely useful to
> > streamline queue processing on a large mail server.
> Yes.  qmail has a global host status table that does just what you say, it
> keeps it from wasting time trying to contact hosts that have recently been
> observed not to answer.

Not answering differs significantly from answering with a 4yz.  The
differences include not only the likely causes but the likely results
of a retry and the costs of trying again.  For example, a failure by
an SMTP server to answer makes the SMTP client pay the costs of keeping
a context alive and waiting for a timeout for perhaps 10 times longer
than the typical duration of an SMTP transaction.

> > The other question is:  Is the SMTP temporary failure response
> > a server property or a recipient property?
> Wouldn't that depend on when the response happens?  If it's in response to
> RCPT TO, it's the receipient.  Any other time, its's the server.

I disagree.  A 4yz in response to 
  - a Rcpt_To is probably but not necessary directly related to
      the parameters in the Rcpt_To command. 
  - a HELO/EHLO or Mail_From command cannot be tied to any Rcpt_To
      value because there hasn't been one.
  - a DATA command might be related to one of the Rcpt_To values or
      something else.
  - any other command might be related to anything.

An SMTP client that presumes to assume about what made the SMTP server
say 4yz without understanding the accompanying text or at least the
extended code is too smart by half.  This is as true of the SMTP
clients that retry within 5 seconds after getting a 4yz for a DATA
command as those that retry 24 hours later.  Those that retry within
seconds (e.g. Cox and AOL) are as broken as those that retry 24 hours
later.  Unfortunately for greylisting, there is no hope of fixing the
many too smart by half SMTP clients.

The suggestion in RFC 2821 of about 30 minutes is the best you can do.
It makes little sense to assume that an SMTP server that was busy and
wanted your SMTP client to come back later either 5 seconds or 24 hours
will be happy now.  It makes no sense to assume the server's objection
will be fixed in 5 seconds or won't have gone and returned over 24 hours.

I think 3 hours is almost as much too long as 24 hours, but your
mileage way vary.  It seems to me that if you are trying to shed load,
then you should shed load.  That means not running the queue if your
SMTP client is too busy.  Whether a given SMTP server blew off your
client several hours ago is irrelevant to whether your client has time
to try again now and implies nothing about whether the server will
again be too busy now.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.