Recently at work I have been noticing an annoying trend in large provider email installations. Due to the nature of our email 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 18.104.22.168) 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 email 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.
Cross posted at http://weblog.2bithacker.net/work/rfc-ignorance.html