------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1066 --- Comment #10 from Graeme Fowler <[email protected]> 2011-01-13 13:21:06 --- (In reply to comment #7) > There's room for disagreement here. I think I'm in the minority of the Exim > Devs with my view, but I'm not opposed to having an option to *upgrade* the > severity of an error. You're right, there is room for disagreement :) I do not believe, personally, that this is a feature we should implement. It directly contradicts the latest revision of the SMTP protocol specification RFC5321. Section 4.2: An SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text unless specified otherwise in this document. The number is for use by automata to determine what state to enter next; the text is for the human user. The three digits contain enough encoded information that the SMTP client need not examine the text and may either discard it or pass it on to the user, as appropriate. ... An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); ... So if we were to write up a function of the proposed type to act on a response to a remote transport, that would be a strict breach of protocol. I appreciate that there are several "accepted" breaches of protocol already (the underscore workaround in HELO/EHLO, for example) but I personally believe that this would be going a step too far. I stand by the previous comment (and yes, I run a large mail system) that if a remote server tells you something then you should not subvert the meaning of that response, either by upgrading it (as proposed) or downgrading it, nor just ignoring it. That way madness lies - cf. Hotmail's "amazing disappearing email" trick where they tell you the message has been accepted, but it never arrives... Graeme -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
