A SMTP implementor's conundrum

December 13, 2006

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.

Written on 13 December 2006.
« A limitation of OpenBSD bridging NAT firewalls
An example of Unix's slow fossilization »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 13 01:06:35 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.