Wandering Thoughts archives


An example of Unix's slow fossilization

If you walk up to the console of some Linux machines that have their capslock turned on and try to log in, an interesting thing happens:

keyx login: CKS

(This works with Ubuntu 6.06, but not with Fedora Core 6.)

Why does this happen?

Once, long ago, there were terminals that only did upper case, and there were people who wanted to connect them to Unix systems. So Bell Labs put a very special hack into getty: if it saw a login name that was all in upper case, it assumed that you were using such a terminal, lower-cased the name, and set a special terminal mode where lower case was converted to upper case on output and upper case converted to lower case on input.

(Of course this doesn't work very well if your password has any actual upper-case characters. Or your username, or the names of your files, or any command options, or etc etc. People who needed this hack were presumably going to avoid all of that.)

It has probably been at least twenty years since such a terminal was connected to a Unix system. In all that time, very few people removed this feature, and so it lurks around many systems to this day. Including systems reimplemented from scratch, where people can't even claim that it was less work to leave old code alone instead of removing it.

(To be fair, this seems to have been removed from the latest version of the Single Unix Specification. Also, FreeBSD and OpenBSD seem to not support 'stty lcase', although Linux does, which I find ironic.)

unix/UnixFossilizationExample written at 22:03:53; Add Comment

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.

tech/SmtpResultConundrum written at 01:06:35; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.