[Top] [All Lists]

Re: SMTP traffic control

2011-10-24 10:36:02

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?"


       "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 
Sent: Monday, October 24, 2011 6:07 AM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: SMTP traffic control

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)

<Prev in Thread] Current Thread [Next in Thread>