On Fri, Aug 08, 2008 at 06:16:11PM -0400, Hector Santos wrote:
Tony Finch wrote:
On Fri, 8 Aug 2008, Frank Ellermann wrote:
Also different from what I had in mind. IOW it really deserves
a clarification. I wonder if this could be coupled with the
"selective reject" ideas (draft-hall) posted here a year ago.
No, it's hard enough to clarify retries without introducing new
complexity.
Tony.
I'm having a hard time why the solid SMTP state machine driven by 4yz,
5yz reply codes is being question now.
For me, there are only a few technical goals for all retry strategies:
- Understand when delivery (or bounce) is required - not an option,
in fact, understand there might be legal requirements and there
is a risk to behave with negligence and malpractice.
Depending on the type of message, including who owns it, only
the client can decide how important is satisfying delivery
expectations.
- Don't send duplicates, and
- Don't bother trying forever when you continue to get the
same results over an extended reasonable time.
From this, IMV, all retry strategies can be modeled per site, per
implementation, per software. Its a common goal we all share and its
really mail network independent.
Off hand, the only pressure we got to alter our current retry strategy
was to satisfy the growth of greylist systems.
Here, a new design factor was introduced to help guide a faster 2nd
retry to help minimize delayed delivery due to 1st time greylisted
rejected. The GreyList document recommends a 451.
However, as it was found, not all support this and common sense tells
you it should not matter - a 45x means a retry is possible. So doing a
generic faster 2nd retry for 45x responses proved to work better in all
cases.
Would it be worth considering whether or not to recommend after a first 45x to
DATA, the sender splits the message up on the second attempt ?
This IMV, creates a semantic issue and enables a 45x to data to
carry additional meaning to the client - the server is saying
maybe I'm busy try later (traditional meaning) or maybe different
recipients require different responses (new meaning).
The problem with reinterpreting what used to mean "I'm busy" to mean
"split the message up so I can give definitive responses for
individual recipients who have different policies" is
that this will tend to overload servers which are genuinely
busy by asking them to do more work by splitting the message
up between many recipients. But perhaps the traditional interpretation
is less likely in practice. Perhaps then if the server is
genuinely overloaded it should not respond to the
next helo/ehlo from the same client, and the client should back off
increasing delays each attempt.
Richard.