[Top] [All Lists]

Retries - may be related to closed issue 12 4yz behavior

2007-04-30 01:50:58

I would like to hear comments on the idea of retries using the same ENV information, in particular the same reverse-path?

In regards to the 4yz response,

  4yz  Transient Negative Completion reply
     The command was not accepted, and the requested action did not
     occur.  However, the error condition is temporary and the action
     may be requested again.  The sender should return to the beginning
     of the command sequence (if any).  It is difficult to assign a
     meaning to "transient" when two different sites (receiver- and
     sender-SMTP agents) must agree on the interpretation.  Each reply
     in this category might have a different time value, but the SMTP
     client SHOULD try again.  A rule of thumb to determine whether a
     reply fits into the 4yz or the 5yz category (see below) is that
     replies are 4yz if they can be successful if repeated without any
     change in command form or in properties of the sender or receiver
     (that is, the command is repeated identically and the receiver
     does not put up a new implementation.)

I think the above has an implied consideration that suggest when the server issues the 4yz response, the error is only temporary and thus the client may issue the request again with the idea the parameters are the same.

Why do I bring this up?

Well, I seen a SMTP client from Google that is getting greylisted with a 451 error but it is retrying (in new sessions) with a different MAIL FROM (reverse-path).

Now, I don't wish to debate the greylist idea that many systems are using, but in general, the idea of what is expected when an 4yz is issued.

I am not sure if this should be part of the spec but the above text is written with semantics that the CLIENT is expected to try again with the same information at some later point.

I am wondering if there is any good reason to provide insight as such.

In the case of Google, today, I was helping my wife set up a blog at Google's and it was doing an email verification. It wasn't coming in so I checked the logs.

It has tried 3 times in the last 24 hours.

I know for sure it was the same transaction because our greylist system is implemented at the DATA stage which allows us to save the temporary rejected mail body for operator perusal. I was able to compare the various email bodies it tried, and it was all the same email verification attempt.

I believe many Greylist implementations simply reject at the RCPT TO, and do not collect the body.

Greylisted or not, if a server is temporarily rejecting an email transaction for typical normal (4yz) reasons as indicated in the example reply codes, I believer server implementations is basing this idea that the retry attempts will be made again with the same information.

Of course, IMO that is not a requirement, but I am wondering if there is any need to mention that in the above text.


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