Re: SMTP traffic control

Carl S. Gutekunst wrote:
> Steve Atkins wrote:
> > It would be nice if the server could say "give me a minute to get my 
> > stuff together and come back", have the client retry in 60 seconds and 
> > get the mail accepted for delivery - with a delay of a minute or so, 
> > rather than a delay of 30 minutes. The server gets to shed load, the 
> > client gets to dump a message out of it's queue and the human 
> > correspondents see fast, in-order mail delivery rather than slow, 
> > out-of-order delivery.
> > That's the end-user visible part of the thought behind 
> > https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/ 
> > anyway.
> >   
> I'd support that proposal. I might even implement it.
>
> Unfortunately, the dominant conversation seems to be around an SMTP 
> response that only applies to greylisting. I'd never use that or support 
> it, it's such a teeny-tiny corner case, especially in the B-to-B world 
> where I live.
Does this suggests that your B2B market is oblivious to the outside 
world remote server behaviors employing 4yz temporary rejections?
Keep in mind, whether its that or this proposal, implementing a 
structure "wait=" or "retry=" time delay syntax inherently means two 
things:
Client:

Common to all proposals, leveraging the server suggested delay in retries.

Server:

Common to all proposals, adding logic to monitor, track the original 
4yz restricted client so that it does not violate the wait/retry= 
delay or blocking time.
That my friend, for lack of a better term, is called a "Greylisting" 
methodology in contemporary times.
Even is the issue of putting all this under a different, more 
appeasing IETF quality terminology, you still need to (re)design the 
same "Greylisting" ideas.
--
Sincerely

Hector Santos
http://www.santronics.com