On Sat, 2008-12-06 at 11:36 -0800, Marc Perkel wrote:
> I do use recipient callout and that is my work around. However there are
> legitimate reasons not to always honor 5xy codes when you KNOW the
> reason it is being rejected is a mistake.
No there are not. There may be instances where you KNOW the remote MTA
is broken, but that does not mean you should code around what the RFCs
tell you are the standards for this protocol.
http://www.rfc-editor.org/rfc/rfc5321.txt
4.2.1. Reply Code Severities and Theory
...
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client SHOULD NOT repeat 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).
[note that the principal difference here between RFC2821 and RFC5321 is
a change from "is discouraged" to "SHOULD NOT". Both state "in the same
sequence".
The key word there, though, is "Permanent".
For 4yz replies, the interesting bit of the RFCs in both cases states:
4yz Transient Negative Completion reply
...
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).
So we can sum up that a 4yz error SHOULD be retried by the client at
some interval, but the 4yx code should only be returned by the MTA if
the identical retry may succeed in future with no change of properties
of client or MTA.
A 5yz error SHOULD NOT be retried by the client, unless something
changes (via the client or the MTA changing something). In your case
this means your client sorts out their misconfiguration, and off you go
delivering again.
I imagine that Philip, although no longer the primary developer of Exim,
would have kittens if another developer seriously suggested an
RFC-busting change of the nature you suggest.
IMO further discussion on this should take place on exim-dev, if at all.
Alternatively you could join the relevant IETF working group and see if
you can get the RFC rewritten to suit your specific problem. Good luck!
Graeme
