--On 6 December 2008 20:45:55 +0000 Graeme Fowler <graeme@???>
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).
It seems to me that this supports Marc Perkel's claims. Note the use of
"SHOULD NOT" rather than "MUST NOT", and the last sentence which talks
about correcting "permanent" errors.
That said, and it would almost always be wrong to do this, so I can't see
it ever getting into the main code. Perhaps an "EXPERIMENTAL" build
option...
Better, by far, to focus on DKIM, SPF, or whatever people think will help
to eliminate the problem of unaccountability of sender addresses.
> [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
--
Ian Eiloart
IT Services, University of Sussex
x3148
