Re: [exim] Exim Development

Graeme Fowler wrote:
> On Mon, 2008-12-08 at 10:32 +0000, Ian Eiloart wrote:
>
>> 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.
>>
>
> And there's the wonderful thing about RFCs... this clause can be read in
> different ways. Focussing on the "human user" element:
>
>
>> 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).
>>
>
> ...which I took to mean "the person sending the mail can try to send it
> again". This is not the same as treating a 5yz (permanent) result as a
> 4yz (transient) result, because transient results are designed to be
> retried by the machines involved where permanent results require human
> intervention to repeat the original command sequence - and even then
> this is usually after they have changed something, so strictly speaking
> it's *not* the original command sequence in those cases.
>
> Perhaps I wasn't clear enough about that yesterday. In fact, I think
> that clause isn't really clear about it in the first place, but the
> "human user" part is the key IMO.
>
> Graeme
>
>

There's another issue here that supersedes the RFCs. If the recipient
server intends to reject the message then I agree. However if the
recipient server is a customer of mine and I know for sure based on the
response code that the rejection is in error, that it was unintended,
and that the customer would want me to detect, report, and preserve the
email then that's different. In my case I know that if I forward email
to the customer and I get a 500 - Relaying Denied error that is not what
the customer really wants to happen.

My point - if the server replies with 550 but is doing so in error -
that's different.