Post by Adam AubePost by Marc A. PelletierTry as I might, I can't see any valid reason (or careful weighting) to
blindly replacing 500 with 502.
Programming simplicity. If I strictly adhere to the RFC, I have to
code handlers for all SMTP commands, even those I don't implement.
If I only code the ones I do implement, and respond 502 to anything
else, I save some code space and some effort.
Err, no. You need not recognize a command that you do not implement at all.
It would be perfectly legal to respond with 500 to a SOML FROM command for
instance. (Indeed, 4.2.2 defines 500 as "Syntax error, *command not
recognized*" [emphasis mine]). If you want just the one error, then it
should be 500 not 502.
Replying 502 is, quite clearly, intended to mean "I know what you're trying to
do, but I don't implement that". Responding 502 to a command which is not
valid breaks that.
4.5.1 gives the (very short) list of commands which an SMTP implementation
must recognize. Anything not in that list is fair game to a 500.
Post by Adam AubeThis is also beneficial in case of extensions to the protocol. If
a new SMTP command is added in a new RFC, I can't return 500 anyomore,
because it's now a valid command. I would have to recode the SMTP
server to respond 502 for those new commands.
Again, you *can* return 500 to a command that exists but you don't recognize
yourself.
Post by Adam AubeOn the other hand, if I already respond 502 to any command I don't
implement (which is permitted under the RFC), there is nothing to
modify in the code.
Permitted, but not needed. In fact, RFC 2821 says you should do the opposite.
And while we are picking nits, the well intentionned behavior of qmail-smtpd
of breaking the connection when it receives a bare CR or LF is also forbidden
(4.5.2 states: "The mail data may contain any of the 128 ASCII characters.
All characters are to be delivered to the recipient's mailbox, including
spaces, vertical and horizontal tabs, and other control characters.")
Remember that the fact that your client MUST NOT send bare CR or LF [2.3.7]
doesn't mean that you are allowed to drop the connection because it does.
Indeed, [3.9] forbids closing the connection unless you have accepted a QUIT
command or have to forcibly close with with a 421 whose message text is fixed
[4.2] and which means the service must shut down (nothing about errors in
protocol there).
Keep the golden rule of interoperability in mind. "Be exacting in what you
provide, and lenient in what you accept."
That said, I don't beleive it is entirely unreasonable to refuse messages
containing bare CR or LF to coerce broken implementations to be fixed. It
should be refused with an appropriate reply code, tough, and not shut the
connection down. Perhaps 554 might be appropriate.
-- Marc A. Pelletier