[Top] [All Lists]

Re: Server Enforcement of Time Blocks (wait=)

2011-10-28 22:47:09

Steve, thanks for the clarification.

Indeed, if the proposal does not offer a server enforcement methodology, then its not going to be modeled on a Greylisting concept with its key idea of a blocking time enforcement, hence I can see value when the HONOR system is followed. This is good for private networks or those with working relationships.

But I am sure there would be a concern with a no enforcement model in the open market since the tendency will be "why bother?" Even within the Honor System, good intention clients who feel they must get a message delivered, or simply has no incentive to bother with code changes, will cross their fingers and just retry again. After all, the new please "wait=" idea is for the *other guy" and not them.

Yes, I understand completely the maintenance and perhaps for loading balancing/limiting.

The latter is more complex. GL at 421 is rare but it does exist. In general its just to control loads. But for the specific example of a down system, the feasibility of offering a wait probably is lower than just having it down for a short fast maintenance period. Most systems will have redundancy in place. But I can see smaller system using some TinySMTP program, like many use the popular small footprint TinyWeb for these informative "Temporarily Out of Service" single page web announcements. With TinySMTP, it can provide the 421 with the "wait=" hint so compliant MTAs don't have waste time trying again. And for these scenarios, if a system opts to do this, then they really cares any MTA retrying anyway. Its only going to be done for a very short period anyway.

Anyway, I just think the no enforcement approach, to me, provides no incentive to put in the time and money to support it. While I could support it as a client, as a server, to spit out this information, it has to have some weight behind it. My opinion.


Steve Atkins wrote:

On Oct 28, 2011, at 7:11 PM, Hector Santos wrote:

Steve Atkins wrote:

My point is if like Atkins proposal and might implement it, once you do, you 
will be behaving like a Greylisted server.
That's simply not true. Please stop stating that.
Are you saying your proposal offer a server issuing of a "wait=" time with no 
server tracking and enforcement?

Yes. It's purely a protocol for the server to communicate to cooperative 
clients. I foresee the primary usage to be not enforced by the server, 
certainly not on a real time basis, though it's something that would be quite 
usable if the server were tracking clients in that way.

Its not be meant to be a negative and it doesn't help with ongoing attempts to 
create division.

Any proposal that includes a "time delay" for a client to use, and more 
importantly the server will enforce, is 100% *behaving* (keyword) like a Greylisting 
Server model.  I can't see how you can avoid it.

Actually it's not, but that's a different issue. (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 client is doing this blinding.  If it encounters a server with this "wait=" in a 4yz 
response, its going to have the same MTA software rescheduling code for supporting any other kind a 
"retry=" or parsing of the informal existing greylisting servers with their time hints.

So unless the proposal is not offering server enforcement, it is very much a 
Greylisting Model.

It's a traffic management enhancement. It could certainly benefit a greylister, 
but it's of broader value than that narrow niche.



Hector Santos

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