Richard Kay wrote:
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).
Its an interesting implementation idea to consider for extreme cases
where maybe its the 4th or 5th attempt or maybe even the final attempt
will it will finally try a split into single transactions.
Off hand, I think the 2nd faster retry worked well enough that would
not make this necessary.
Also, consider, that if any of the RCPT are remote (not local address
or hosted domains), where a relay situation will be required for final
delivery once the receiver accepts the message, then in the case,
most systems require authentication or authorization - otherwise you
have an open relay system, and the acceptance of local RCPT should not
trump the authorization requirement for a remote RCPT address:
(for non-ESMTP AUTH session)
RCPT TO: local
250 OK
RCPT TO: remote
550 Authentication/Authorization required.
DATA
354 ...
451 Try again later
For us, when ESMTP AUTH occurs, the sender totally by-pass all SMTP
level receiver AVS strategies, and the operator decides at the content
level what happens there:
(for ESMTP AUTH session)
RCPT TO: local
250 OK
RCPT TO: remote
250 OK
DATA
354 ...
250 Message accepted
> 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.
I believe many servers do employ connection and session loading
limits. I don't think the greylist response should not have any other
meaning other than what the SMTP model defines 4yz - a temporary
situation - try again later.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com