[Top] [All Lists]

Re: Putting it all together

2011-10-30 05:23:57

Paul Smith wrote:

On 30/10/2011 03:57, Hector Santos wrote:

It seems to me ID2 and ID3 are very different since as I understand there is no enforcement in ID2 where its a critical part for ID3.

I think you're over complicating it.

From the point of view of the client AND server, the wait:xxx response doesn't care whether it's enforced or not. The enforcement is a part of the greylisting system, not a part of the protocol enhancement.

Didn't I state that?

The server should not penalise a client which ignores its wait:xxx hints (eg it may choose to do so, if it sees 'wait:100000'), so, in fact, the 'wait:xxx' response is not enforced separately.

I personally don't think this will work without enforcement. When not enforced, the wait proposal now becomes narrow scope for scenarios like down or maintenance periods when many systems already employ redundancy and/or the maintenance job is made to be so short in time, that its not feasible to go thru all this, especially when it was stated it is a "Best Guess" wait and very possible not to be accurate which means there is a whelm of possibility the server will be indefinitely unavailable.

Similarly, a server which is down for an hour, implicitly 'enforces' attempts to reconnect before that hour is up, but it shouldn't be part of a spec that it should do so, it just happens. All the 'wait:xxx' enhancement is, is a bit of helpful info for the client, if it wants to use it.

Sure, like anything else. But IMV, no enforcement equates to less effectiveness, but then again, its a narrow scope and there are already solutions for down and maintenance periods. There is a different between being "Down" and "Maintenance Period." Down is Down. No one is answering and there is an explicit (socket) error code that can be tied to altering retry schedules (i.e, not part of the normal 4yz reasons). For maintenance, it all depends what that means and not everyone uses the same package nor can we assume a protocol will work under the premise all software does maintenance the same way. Your (speaking in general) maintenance needs could will be very different than mine. (We have an RPC client/server framework - maintenance is at the back end and the SMTP server does not need to go into 421 mode.)

In my experience, sites with normal and regular maintenance schedule needs will factor the feasibility of the amount down time vs implementing redundancy - i.e. there is never a receiver unavailable. Certainly not for the idea of "maintenance." Some systems also have hot file I/O, backups and don't need to go into a maintenance mode. The system runs 24x7x356.

So its all very different for many.

I guess I don't see the need myself just for this 421 wait when the particular scenario is maintenance. If maintenance takes a long time, they need to revisit the setup or make sure additional servers are available that will at a minimum receive the mail perhaps and keep it in a queue.

As I stated in the other post, what I do see is a saving in the connect timeout when you have a listening server for the sole purpose of issuing a 421 with a wait hint. But if its just a best guess with the possibility it can be wrong, and still induce wasted attempts, then IMV just turn off the listening server and allow the MTA to get the connection timeout so it can increase the delay for the next retry.

Beyond the 421 and the service is open, I don't see the benefits for issuing a wait hint when there is no enforcement. By benefits, it includes the inevitable need to deal with those that don't support it or ignore it making wait hints less effective.

My opinion.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net