Re: Server Enforcement of Time Blocks (wait=)

Steve Atkins wrote:
> (Greylisting requires keeping track of remote clients in some way, so as to treat 
> them differently the first time you see mail from them. As a concrete example of a 
> server enforcing delays that's not greylisting consider a mailserver with a database 
> backend, where you need to take the backend down for maintenance for a few minutes. 
> While the database is down, the server may respond to any transaction with a 4xx (or 
> even with a 4xx wait=<number of seconds until the database server comes back 
> online>). Attempted redeliveries before that will be deferred again.)
The specific case I had in mind was an SMTP server that comes up and is 
able to respond to connections long before it's actually able to process 
messages. (The backend process that filter the mail take a long time to 
start.) It would be useful to be able to say when the server will 
actually be available. In that scenario the server is oblivious to 
client behavior.
There's another common problem I have, though, that may be more of what 
Hector was thinking of. Suppose I have an SMTP receiver that's been down 
for a small number of hours, so I'm still within the range where clients 
are retrying pretty aggressively. When the receiver comes back up, it 
gets swamped with connections, a situation was used to call a "deferral 
storm." In this situation, some number of the clients will get 4xy 
responses again, while others would be accepted, and the rate of 
accept/defer will be likely be tied to the connection rate of the 
clients, whether I intended it to be that way or not. Here, what would 
be useful is a way to apply controlled back-pressure to the storm.
It's not "greylisting" as Levine described, but it seems like it fits 
Hector's characterization of a "greylist behavior."
<csg>