--On Monday, 30 April, 2007 04:34 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
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.
Yes.
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).
From the standpoint of 2821 (and 821) this is a different
message. Not that makes any difference, since neither
specification has any model of keeping server state between mail
sessions.
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.
yes
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.
As far as 821/ 2821 are concerned, there is no vocabulary for
"collecting the body" (or any signature or approximation to the
body). At the time a 4yz or 5yz (or a post-DATA 2yz) reply is
delivered, the server is finished. 2821 doesn't even specify
logging.
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.
Why? Why (other than greylisting and other tactics) should the
server even care? All it has said is "not now, try again
later.".
Of course, IMO that is not a requirement, but I am wondering
if there is any need to mention that in the above text.
Almost certainly not a "need" and, as the person who will be
blamed for the length of this document, I'm reluctant to add
text about the general character of mail practices for which
there is no RFC-documented theoretical or architectural
foundation.
john