Marc Perkel wrote: > > 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. >
We seem to go throught this exercise at annual intervals. Exim should be given the ability to ascertain 'intentions', read minds, if you will. Usually at some point, a request for a pony is injected into the thread. AFAICS, no pony has ever actually been delivered. Nor appeared on its own. Nor even passed through. Which leaves us with a mystery, does it not? Bill -- ## 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/
