A SMTP implementor's conundrumToday I ran across a good example of the sort of engineering conundrum that bedevils people who implement things like SMTP clients:
That is, in a regrettably non-hypothetical example, if you send a
server ' 250-There's a problem. 454 please try later Should your client go on and send a (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 (Then when Exim goes on to send a 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. (5 comments.)
|
These are my WanderingThoughts GettingAround This is part of CSpace, and is written by ChrisSiebenmann. * * * Atom feeds are available; see the bottom of most pages. Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web |