Re: Server Enforcement of Time Blocks (wait=)

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.
--
HLS

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.
>
> Cheers,
>   Steve
--
Sincerely

Hector Santos
http://www.santronics.com