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)