Having made a stupid mistake in connection with temporary errors and
outgoing SMTP transport in 2.05 (see previous posting and patch), I went
back to the drawing board and thought up a new strategy. Some changes
have been made in the development source, and I thought it might be
useful to post the specification here for comment. The text below is
taken from the entry in the NewStuff file for the next release. Comments
invited.
During SMTP delivery, three different kinds of error are recognized:
host errors, message errors, and recipient errors.
(A) A host error is not associated with a particular message or with a
particular recipient of a message. The host errors are:
. Connection refused or timed out
. Any error response code on connection
. Any error response code to HELO/EHLO
. Loss of connection at any time
. I/O errors at any time
. Timeouts during the session,
other than in response to MAIL FROM or RCPT TO
A host error causes all addresses to be deferred, and retry data to be
created for the host. It is not be tried again, for any message, until its
retry time arrives. If the current set of addresses are not all delivered
in this run (to some alternative host), the message is added to the list of
those waiting for this host, so if it is still undelivered when a
subsequent successful delivery is made to the host, it will be sent down
the same SMTP connection.
(B) A message error is associated with a particular message when sent to a
particular host, but not with a particular recipient of the message. The
message errors are:
. Any error response code to MAIL FROM, DATA, or "."
. Timeout after MAIL FROM
A permanent error response (5xx) causes all addresses to be failed, and a
delivery error report to be returned to the sender. A temporary error or a
timeout after MAIL FROM causes all addresses to be deferred. Retry data is
*not* created for the host, but instead, a retry record for the combination
of host plus message id is created. The message is *not* added to the list
of those waiting for this host. This ensures that the failing message
will not be sent to this host again until the retry time arrives. However,
other messages that are routed to the host are not affected, so if it is
some property of the message that is causing the error, it will not stop
the delivery of other mail.
(C) A recipient error is associated with a particular recipient of a message.
The recipient errors are:
. Any error response to RCPT TO
. Timeout after RCPT TO
A permanent error response (5xx) causes the recipient address to be
failed, and a delivery error report to be returned to the sender. A
temporary error or a timeout causes routing retry data to be created for
the failing address. This means that the address will not be processed
again, in any message, until its retry time arrives. The message is *not*
added to the list of those waiting for this host. Use of the
host for other messages is unaffected, and except in the case of a timeout,
other recipients are processed independently, and may be successfully
delivered in the current SMTP session. After a timeout it is of course
impossible to proceed with the session, so all addresses get deferred.
However, those other than the one that failed do not suffer any subsequent
retry delays. Therefore, if one recipient is causing trouble, the others
have a chance of getting through when a subsequent delivery attempt occurs
before the failing recipient's retry time.
In all cases, if there are other hosts (or IP addresses) available for the
current set of addresses (for example, from multiple MX records), they are
tried in this run for any undelivered addresses, subject of course to their
own retry data. In other words, recipient error retry data does not take effect
until the next delivery attempt.
Some hosts have been observed to give temporary error responses to every MAIL
FROM command at certain times ("insufficient space" has been seen). It would be
nice if such circumstances could be recognized, and defer data for the host
itself created, but this is not possible within the current Exim design. What
actually happens is that retry data for every (host,message) combination is
created.
The reason that timeouts after MAIL FROM and RCPT TO are treated specially is
that these can sometimes arise as a result of the remote host's verification
procedures. Exim makes this assumption, and treats them as if a temporary
error response had been received. Timeouts at other times are treated as
host errors, assuming a problem with the host, or the connection to it. If a
timeout after MAIL FROM or RCPT TO is really a connection problem, the
assumption is that at the next try the timeout is likely to occur at some other
point in the dialogue, and will then be treated as a host error.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
