At 6:43 +0530 2003/03/17, Suresh Ramasubramanian wrote:
>At 12:37 AM 3/17/2003 +0000, Giuliano Gavazzi wrote:
>5xx mostly demands that if you retry, do so later, *manually*. What it
>>>does say is that the remote domain refuses to accept delivery of the
>>>current message.
>>
>>what current message? [BTW, the connection might have been just a
>>sender/callout verify]
>
>the message (I don't care if it was a callout, a mail sent from outlook
>express, whatever) which, when sent, was rejected with a 5xx response.
>
>>I am sorry, but until the intention of delivering a message has been
>>stated, the error cannot mean that the domain refuses to accept *the*
>>delivery.
>
>Connection to a host on port 25, implies some attempt to deliver, even if
>the attempt is partial (such as a callout).
if you had failed connecting to the host on port 25 because of a
network problem/firewall block/else would you also say that the
attempt to deliver has failed? The RFC is quite clear in
distinguishing 554 in this context from the same error in other
contexts where in general means "Transaction failed" (the RFC gives
also more specific meanings depending on the SMTP phase).
>> To provide reliable
>> mail transmission, the SMTP client MUST be able to try (and retry)
>> each of the relevant addresses in this list in order, until a
>> delivery attempt succeeds. However, there MAY also be a configurable
>> limit on the number of alternate addresses that can be tried. In any
>> case, the SMTP client SHOULD try at least two addresses.
>
>Did the RFC above say what kind of error it is talking about? In this
>context, I can only conclude that they are referring to 4xx
The context is the general context of "Address Resolution and Mail Handling".
Since it seems that the main block in this discussion is "how should
5XX" errors be handled, I have been looking for where this is
discussed in the RFC 2821.
I have found this (in "4.2 SMTP Replies")
[...] new codes may be added as the
result of new Standards or Standards-track specifications.
Consequently, a sender-SMTP MUST be prepared to handle codes not
specified in this document and MUST do so by interpreting the first
digit only.
This does not mean that the sender-SMTP must base its actions on the
first digit only. I think this is the first misinterpreted point.
Indeed, further down, in the following "4.2.1 Reply Code Severities
and Theory":
[...] An SMTP client
that wants to know approximately what kind of error occurred (e.g.,
mail system error, command syntax error) may examine the second
digit.
And
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client is discouraged from repeating the exact
request (in the same sequence). Even some "permanent" error
conditions can be corrected, so the human user may want to direct
the SMTP client to reinitiate the command sequence by direct
action at some point in the future (e.g., after the spelling has
been changed, or the user has altered the account status).
So two facts seem clear to me:
1) what is forbidden is to repeat the exact request (in the same sequence).
2) although it mentions here human intervention, it is clear that in
this case human intervention cannot change the order of MX, if you
exclude talking to the DNS maintainer, and even this action might be
precluded if the maintainer has got an address in the same domain.
Contact telephone numbers are not necessarily available too.
If, as Florian and I suggested, we repeat the request changing the
parameter that caused the failure, that is changing the MX used in
this case, we are within the standard. And before anyone says that
retries should be at 30m intervals at least, let me repeat that the
standard explicitly allows the SMTP client to be more flexible when
it can determine the cause of failure (in this case: using a
particular MX).
In summary, to the point of the 554 at connection (greetings), my
interpretation of the letter and spirit of the RFC is that a second
MX should be tried, and also a warning should be sent to the local
postmaster with the text of the 554 error, to alert him of a possible
misconfiguration of the local SMTP client (a possibility mentioned in
this regard in the RFC). A failure on the attempt to the second MX
(with no delay) should then result in a permanent failure with error
message sent to the sender, after all, as Philip pointed out, this
554 might just mean that there is no SMTP service at the domain as a
whole (not just the MX host). Clearly this last possibility indicates
that the email address was incorrect and the user must be told
immediately.
If this means too much extra complication added to exim, let's forget
about it, it is a rare occurrence after all.
May I assume that G.A.W. will say that I am taking these RFC
paragraphs out of context?...
Giuliano
