Re: SMTP traffic control

Hi Paul,

I disagree with the "pain point" criteria being used a barrier to 
address a recognized issue.  Pain is a subjective concept and as in 
humans, even mail systems have different tolerance for "pain." I 
really hope we don't measure the need to move forward to improve the 
"ills" of the system by waiting until XYZ system gets a belly aches 
and it becomes a pain in the neck for them.
When I see my MTA wasting attempts, delaying the mail delivery - that 
is "pain" to me and my customers because it isn't working for them as 
well as they wish it will.  I am tired of having to answer customer 
questions such as
       "Why it taking so long to send this message and fast to
        send that another message?"

or

       "I thought by using DKIM, these rejections were going to go away."

Go figure.  So that guys "pains" if we to put it in those terms, is 
felt by us as well.
In ideal terms, some AI is required.  MTAs need to learn on a PER 
remote site basis how they are accepting/rejecting transactions. For 
example, it might learn that XYZ domain required 10 mins delays. It 
may learn this after it initial first time transaction of 4 attempts 
and 20 minutes, and maybe use a binary 50% cut the next time, etc.
This is too much. The simple solution is to not to try to figure out 
the server's reasons but to propose a simple data point it can expose 
the idea:
      "ok, you rejected me, when do you want me to try again?"

I really don't care what the server reasons are and I don't wish to 
add tons of dollars and time to research a super advanced queuing 
concept that most likely isn't to work across the board anyway by 
using a Guessing Game on retries.

Paul Smith wrote:
> On 24/10/2011 14:49, Murray S. Kucherawy wrote:
> > > -----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.
> We get 'pain' from these limits, but mainly on customer facing 
> submission servers ('smarthosts'), rather than MX servers. It would be 
> good if we could easily tell that a '4yz' error we got was due to trying 
> to send 6 messages in a single session (when we could immediately start 
> a new session) rather than it being due to the server's disk being full 
> (in which case immediately starting a new session would be pointless)
> I haven't come across it much in MX servers, but that could be because 
> most of our customers are small businesses, so sending large numbers of 
> messages to a particular MX server is unlikely, and the automatic 
> retries probably mask the few cases where it happens.
> (Of course we have bigger 'pain points' - the '10 errors and we'll drop 
> you' is the worst:
> rcpt to:<invalid(_dot_)address(_at_)bad(_dot_)domain(_dot_)com>
> 4yz invalid recipient
> rcpt to:<another(_dot_)address(_at_)another(_dot_)bad.domain>
> 4yz invalid recipient
> ... 8 more times
> 4yz too many syntax errors, connection dropped
>
> (now a message in the outbound queue which will never go)
> but that's off topic)