2 Bit Hacker

I often have a number of projects floating around in my head that I’d like to get done around the apartment. Largely for my own tracking, I’ve decided to list them here, roughly in the order I’d like to get them done.

1. Home Server: For a while now I’ve been wanting to build a NAS box for the apartment. A place to backup all my important files from other systems so I don’t have to worry about what I’m losing when I randomly decided to format and reinstall my OS. I was originally thinking of reusing an older Mini-ITX board I have kicking around, giving it a SATA controller and a few large hard drives. I’ve also wanted to do my own router for the apartment. I’m currently using a Linksys WRT54g running dd-wrt, which works fine, but I’d like more control. I think the most economical solution is to combine the two projects into a single Home Server, probably running FreeBSD. It’ll need at least 2 network interfaces, and preferably 4 or more SATA channels. I could easily reuse one of the 5 or so motherboard I have kicking around the apartment, as I don’t need a ton of CPU power or memory. Software wise, just the normal file sharing stuff, NFS, Samba, a web server, maybe look into WebDAV.
2. HTPC: I’d still like to get a Home Theater PC hooked up. I tried this a few years ago without much luck, but now that I have a TV with HDMI inputs, it should be nice and easy. I originally wanted to do this with MythTV, but I think I’ve cooled on that. I think it’ll actually run Windows, primarily for the ability to play streaming Netflix.
3. Replace Desktop: Now that a couple of guys at work have eee PCs I’ve been reconsidering my own systems. I rarely use my desktop at home anymore (perhaps repurpose it to HTPC?) so I’ve been tossing around the idea of replacing the desktop and my ThinkPad T43 with a heftier laptop, like a T61 or an ASUS G1S. Basically, a laptop decent enough to game on if I feel like it. Then pick up an eee to use for portability and quick things like checking e-mail or fixing stuff for work. The Nokia n800 works pretty well for the latter things currently, but the lack of keyboard hurts a bit. And the eee PC is a plain x86 CPU, so I could run XP on it and be able to use Slingbox, which would be nice.
4. Car PC: Yeah, still keeping this dream alive. Some day I’ll build it. It seems to be getting easier though. Bluetooth GPS, Bluetooth serial adapter on the OBD2. Maybe someone will figure out how to hack into the Prius MFD by then.

Recently at work I have been noticing an annoying trend in large provider e-mail installations. Due to the nature of our e-mail forwarding services, we occasionally get blocked by providers such as Comcast and AT&T. This normally isn’t a big deal, but a few months ago Comcast made a change to their mail system, and now when you get blocked it will respond to an open connection with a 554 error and close the connection. AT&T now does something similar, issuing a 550 error and closing the connection. I don’t mind getting blocked so much, but the manner in which they do so violates the SMTP RFCs, and that just gets on my nerves.

The specific RFCs in question are 821 and it’s proposed successor, 2821. The section in question in both of these documents is 4.3, which specifies what responses can be returned for various commands. 821 specifies that the initial client connection can be answered with a 220, which is normal, or a 421, meaning the service is not available, and the connection will be closed. The 421 can be issued at any time during the conversation, and usually indicates that the server is shutting down and can’t complete what it’s doing. RFC 2821 changed this, allowing the 220 or a 554. AT&T’s response code of 550 is not a valid response in either RFC, so AT&T isn’t following the RFC at all with their reply. Comcast’s reply is technically valid, but I feel it’s being used incorrectly.

The was an interesting thread on the exim-users mailing list on the topic, beginning with Exim’s handling of 554 on connect and expanding into the meaning of the return code. Some people think it means that you are being told you will never be able to deliver the message you are trying to send and should discard it, which is how Exim handles it. Others (including myself) think it’s intended meaning is to indicate that the server in question cannot take the mail, but the delivery should be attempted at other MX records for the domain, or other A records for the current MX. Keep in mind that the server doesn’t know anything about the message at this point, the client hasn’t had a chance to say EHLO, let alone give sender and recipient information. RFC 2821 states the meaning for 554 on connect to mean “No SMTP service here”, which is fairly vague. My opinion is that this indicates that this particular server will not except mail for any reason, not that the message is undeliverable (unless this is the only A record for the recipient domain’s MX record.) In this case, using 554 on connect to reject mail from a particular server isn’t really helpful. The generally accepted method of rejecting after RCPT commands is probably a better route, since the server may be trying to send to your postmaster address, which you’re obligated to take mail for.

Regardless of the meaning of 554 and the appropriateness of it’s use as a rejection mechanism against spammers, Comcast and AT&T are also ignoring the RFCs by dropping the connection after issuing their error codes. Here’s the relevant part of RFC 2821:

The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT (see section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with “503 bad sequence of commands”. Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.

See that “MUST still wait for the client to send a QUIT“? Both Comcast and AT&T don’t follow that. It would be permissible to timeout after that, but the RFC doesn’t allow for simply dropping the connection.

So what to do about this people? I’m not really sure. It would be nice if large e-mail providers respected the rules put forth by the Internet community, but how do you penalize them if they don’t? The only idea I currently have is to form something similar to the existing rfc-ignorant.org listings, but for general RFC breakers, as opposed to their specific lists. This could then be used to block mail from sites that don’t follow the rules, which if you’re big enough would get their attention, but hurts users by rejecting their e-mail.

As a mixed blessing, the Internet is designed to allow people to do pretty much whatever they want to do with the servers they run, and there’s just no good way to get some sites, especially large company sites, to follow the rules if they don’t want to, unless you deny them access to things they want.