You can quote all the rules you like but if a customer misconfigures
their server and in spite of their error I can store and then redeliver
the email that would otherwise have bounced then I am a hero. I don't
intent to retry on 5xy errors but I want the option of storing the email
for either inspection and troubleshooting or in the xase that the
customer fixes their server and wants the email.
Graeme Fowler wrote:
> 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
>
>
>
