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 > > > -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
