[Top] [All Lists]

Re: 2821bis consideration - New 2nd attempt Retry Strategy recommendation

2007-11-16 11:01:22

Hi Hector,
At 06:53 16-11-2007, Hector Santos wrote:
I believe the z digit in x5z is undefined:

The 1st paragraph, last sentence in 4.2.1, says:

   "The third digit and any supplemental information that may be
   present is reserved for the finest gradation of information."

I see the example literal text for 451 says "processing error", but the literals are meaningless to SMTP. Offer no flow control logic. Right?

The literals in there serve as guidance to when we would use such a reply code. There's no different flow control logic on the literals. From an operator's point of view the reply code is helpful to troubleshoot a problem. I believe that we should differentiate between policy and processing errors.

Yes, I agree, it would ideal if a special code can be detected.  Hmmm,
the Greylist specs shows  a 4.7.1 extended code:

      451 4.7.1 Please try again later

I believe that the reply code mentioned in that whitepaper is incorrect. The extended code is correct. I recommend using "450 4.7.1 Text" when the temporary failure is due to a policy decision.

We use the 5 minute 2nd retry interval because anything else is deemed too long for these deliberate 1st time only rejects - an action that should not occur under normal circumstances. I have not seen or heard of any negative impact due to a shorter 2nd retry interval. But there were an awful amount of reports from confused operators before we added the variable frequency table to address the increasing hits on remote GL systems.

The decision on what interval to choose for the second retry is guided by technical specifications but one also has to take the market into account. It's a "SHOULD" which I read as unless you have a good reason not to follow it. If you have not seen or heard of any negative impact due to the shorter second retry, then it's not a problem. That setting should be customizable though.

As a general rule, I would use 30 minutes as receivers reading RFC 2821 will expect that. This question came up on the mailing list some time back.