Re: Putting it all together

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.


--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net