Re: SMTP traffic control

The cliche is nice, but there is a recognized problem and a 
reproducible proof of concept solution possible to help minimize the 
impact.  Why does it have to be everyone's problem before a solution 
is sought?  I guess some see smoke and others needs to see fire before 
acting on a solution.
MH Michael Hammer (5304) wrote:
> Personally I think this is a solution looking for a problem. 
>
> > -----Original Message-----
> > From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
> > smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Murray S. Kucherawy
> > Sent: Monday, October 24, 2011 9:50 AM
> > To: ietf-smtp(_at_)imc(_dot_)org
> > Subject: RE: SMTP traffic control
> >
> >
> > > -----Original Message-----
> > > From: Rosenwald, Jordan 
> > > [mailto:Jordan_Rosenwald(_at_)cable(_dot_)comcast(_dot_)com]
> > > Sent: Monday, October 24, 2011 6:07 AM
> > > To: Murray S. Kucherawy
> > > Cc: ietf-smtp(_at_)imc(_dot_)org
> > > Subject: RE: SMTP traffic control
> > >
> > > Murray,
> > > I don't think I'm squashing such an idea (standardization is usually
> > > beneficial). I'm more asking, IF we standardize what benefits do we
> > > expect given that many large ISPs do provide much of the feedback
> > (just
> > > not in a standardized format)?
> > [So that's what that button does.]
> >
> > Right, and I believe the goal is an optimization that reduces retries
> > that are doomed to fail.  The question you could probably answer from
> > your perspective is whether or not those retries are a problem for
> you,
> > either as a sender that provides queueing services for customers, or
> as
> > a receiver that periodically temp-fails for resource reasons.
> > Standardizing the reply increases the likelihood that clients will
> > adhere.  But if the current setup isn't a pain point for you or
> others,
> > then that suggests there's not really a problem here worth solving.