ietf-smtp
[Top] [All Lists]

Re: Server Enforcement of Time Blocks (wait=)

2011-10-28 23:34:06

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>

<Prev in Thread] Current Thread [Next in Thread>