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 blogger.com 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.
--
HLS