2006-12-13
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 PASSWORD: [...] CKS@KEYX:~$
(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.)
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.