== A SMTP implementor's conundrum Today I ran across a good example of the sort of engineering conundrum that bedevils people who implement things like SMTP clients: > In a multiline [[SMTP reply > http://utcc.utoronto.ca/usg/technotes/smtp-intro.html]], which reply > code should you use if different lines of the reply have different > codes? That is, in a regrettably non-hypothetical example, if you send a server '_MAIL FROM:_' and get back: > 250-There's a problem. > 454 please try later Should your client go on and send a _RCPT TO_, go away to try again later, or just run screaming? (Sending such a multiline reply is not spec compliant, but our core mailer is held together by bailing wire and chewing gum, so these things surface every so often.) [[RFC 2821 http://tools.ietf.org/html/rfc2821]] is silent on this, unsurprisingly. Our usual MTA and all the code I've had a hand in has used the last line's reply code, and I've been assuming that that's how everyone operated. But today I found out that [[Exim http://www.exim.org/]] appears to use the first line's reply code instead, and so thinks that its _MAIL FROM_ was accepted. (Then when Exim goes on to send a _RCPT TO_, the server sees it as an out of phase command, which is a 5xx hard error and Exim bounces the message. I think they were all spam messages, so I'm not too broken up about this.) I think our choice of using the last line's reply code makes more sense (and is more likely to be the server's intention). But I can't exactly blame Exim for its decision, and I have to admit that I'm biased.