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, 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:<something>
' 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 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 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.
|
|