More on reverse DNS lookups? Inconceivable!

"A clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool. You would have counted on it, so I can clearly not choose the wine in front of me."
— Vizzini, The Princess Bride

More on why reverse DNS lookups are bad for SMTP.

Let's say you're arguing with someone from the stone age who swears that RFC 2821 is horseshit, and that anything other than RFC 821 is heresy. This philosophical divide does exist in places, and I can't help but think of it as a low-stakes modern-day version of Martin Luther nailing his ninety-five theses to the church door. Don't draw an isomorphism here between my opinions herein and the Protestant Reformation; that is not my point. My point is that in the realm of web standards, there is no scripture more holy than the RFC and there are those who refuse to deviate by it, even at great harm to themselves and their brethren.

"I don't genuflect before anything that isn't in RFC 821," our hypothetical opponent says. "And RFC 821 doesn't say anything about resolving addresses of hosts listed at the start of a connection, so doing so is therefore not against scripture."

Your opponent can have one of two viewpoints here:

1. Nothing not explicitly listed in RFC 821 is permissible. Follow only the rules given by St. Postel and ignore all extensions. Only the word of Postel is truth.
   
   or
   
   
2. Everything not explicitly restricted by RFC 821 is permissible. RFC 821 is meant to be a guide and any extensions that don't violate the standard must, therefore, be allowed by same said standard.

The good news is that, like Vizzini, your reverse DNS-loving opponent is wrong no matter which tack he takes. If the opponent has the first point of view, forced by his love for RFC 821 to swear by no other, he must concede that if RFC 821 doesn't mention reverse DNS lookups, then he should not be using them. Game over, end of story, Q.E.D., call the wife and tell her to pour the gin 'cause you're on your way home.

The only even remotely viable view left for the opponent is to obey what is stated in RFC 821 to the letter and be of the mindset that since reverse DNS lookups aren't mentioned as either good or bad, then they must be OK.

At this point, the man in black drinks his wine, sets it down, and says "You guessed wrong."

Now, I'm not about to take credit for this next bit. I had to go looking for it way down in RFC 1651, section 4.1. If your opponent won't believe RFC 2821, you may be able to persuade him down to RFC 1651, but this won't matter for the hardcore RFC 821 zealots. Fortunately for us, it doesn't matter since the important passage is just a reference to something mentioned in the holiest of holies.

(An easy litmus test to run on your opponent's SMTP server: check to see if it uses the EHLO verb. EHLO is pervasively common these days, and wasn't debuted until RFC 1425. If your SMTP server speaks EHLO, it's grown beyond RFC 821 and you can point that out to your opponent, too. In case you couldn't tell, this entry is all about winning your case by rote quoting of chapter and verse.)

RFC 1651 states:

"Some SMTP servers are known to disconnect the SMTP transmission channel upon receipt of the EHLO command. The disconnect can occur immediately or after sending a response. Such behavior violates section 4.1.1 of RFC 821, which explicitly states that disconnection should only occur after a QUIT command is issued."

And darned if they aren't right. I reprint the relevant portion of RFC 821 section 4.1.1 here for posterity, (emphasis added):

"QUIT (QUIT) This command specifies that the receiver must send an OK reply, and then close the transmission channel. The receiver should not close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender should not close the transmission channel until it send [sic] a QUIT command and receives the reply (even if there was an error response to a previous command)."

Since I have yet to see an implementation that still accepts a message after a failed lookup, I can only conclude that those who abide by such a demented system have no clue what they're doing.

"But RFC 821 was obsoleted by RFC 1123," an opponent may say. They have no allegiance to RFC 821, but they have found flaws in Klensin's RFC 2821 and have drawn their wagons around RFC 1123, which essentially put the rubber to the road as far as Internet protocols go: SMTP isn't alone; RFC 1123 also pays heavy attention to telnet and FTP. Fortunately, you may point your opponent at RFC 1123 section 5.2.5, which states:

"The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification."

How's this different from RFC 2821 you ask? RFC 2821 prefers EHLO over HELO. Now, you have two RFCs that clearly state reverse DNS lookups are permissible but that their results should not be considered grounds for terminating the connection, whether for HELO or for EHLO.

So what does this mean for us? It means that doing reverse DNS lookups doesn't violate the SMTP standard, but configuring your mail server to refuse all messages that fail to meet your reverse DNS criteria does according to RFC 2821, RFC 1651, RFC 1123, and the holiest of holies, RFC 821. There are absolutely no RFCs anywhere that support dropping the connection because of a failed reverse DNS lookup.

I'm tired now. Go find someone who swears by reverse DNS lookups and hit them for me.