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.
