Here’s how a sender verification callout works. Let’s say I’m an innocent mail server, and some jerk is trying to send me a message. There’s a very strict procedure for how mail servers talk to each other. Here’s an example, with the sender’s (22.214.171.124) stuff in red, the receiver’s (126.96.36.199) stuff in blue, and an explanation of each part in black:
[Establish TCP connection to receiver]
220 server.receiving.com SMTP Sendmail Fri, 05 Mar 2010 15:47:18 -0600
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
This is the receiver saying hi. If the receiver is broken, or if the IP address of the sender is considered “bad” for some reason, then the receiver won’t send a “220″. The “220″ is a status code meaning “Hi let’s talk”.
The sending server introduces itself. “EHLO” is part of SMTP protocol. “server.sending.com” is the hostname of the server sending the message. The receiver can now run sender verification on the sending server’s hostname. This is not a “sender verification callout” – it’s just “sender verification”.
250-server.receiving.com Hello server.sending.com [188.8.131.52], pleased to meet you
Sender verification passed. Receiving server tells the sender some basic guidelines about how it likes to communicate.
MAIL FROM: <firstname.lastname@example.org> SIZE=1405
Sender tells the receiver what mail account created the message. The receiver can now run a sender verification callout.
Callout must have checked out. Sender’s mail address checks out, and transaction can proceed.
Sender reports the email address to which it’s trying to send.
Receiver acknowledges that it will, in fact, accept mail addressed to that account.
Sender says it wants to send the actual message now.
354 Start mail input; end with <CRLF>.<CRLF>
Receiver says to go ahead, and says that after the entire message has been sent, indicate that the message is done by sending a period (.) on a line by itself.
Hey dude, those lines up there are headers, and this crap right here is the message body.
The message. Headers come first. The period by itself indicates there’s no more to the message.
250 Ok: queued as 1234567890
Receiver indicates it got the message, and stuck it in the mail queue.
Sender says goodbye.
Receiver says goodbye.
So that’s how mail servers talk to each other when everything goes smoothly. I kind of skimmed over the actual sender verification, and the sender verification callout. So, using the above exchange as an example, here’s what happens behind the scenes.
Sender Verification: The receiving server knows the IP address of the sending server as soon as the TCP connection is established (obviously – there are two IPs in the conversation, and one’s itself). Once the sending server sends the “EHLO” line, then the receiver knows the hostname of the sending server. Sender verification is when the receiving server performs a reverse DNS lookup on the IP address of the sender, and makes sure the reverse DNS response matches the hostname in the “EHLO” line.
You can check the reverse DNS of the sender’s IP like so:
root@server[~]# host 184.108.40.206
220.127.116.11.in-addr.arpa domain name pointer server.sending.com.
Since reverse DNS for the IP is “server.sending.com”, and the EHLO line reported the hostname “server.sending.com”, sender verification passes.
Sender Verification Callout: Sender verification related to the hostname of the sending server. The callout relates to the specific mail account sending the message. In the “MAIL FROM:” line, the sender is claiming that an email account “email@example.com” exists, and that it created this message. The receiver performs a callout to make sure this account does in fact exist. To do this, the receiver pretends like it’s going to send an email to that account, and if it’s able to send a message, then the callout passes. The important thing to note here is that the receiver doesn’t necessarily connect back to the sending server. Here’s what the receiver does to perform a callout:
“MAIL FROM” is firstname.lastname@example.org? OK. Let’s make sure someone didn’t make that up. What server hosts mail for “sending.com”?
root@server[~]# host -t mx sending.com
sending.com mail is handled by 10 server.mailhost.com.
Alright then, what’s the IP address of this so-called “server.mailhost.com”?
root@lucient[~]# host -t a server.mailhost.com
server.mailhost.com has address 18.104.22.168
So if I try to send a message to “email@example.com”, with the server at “22.214.171.124″ take the message? If so, then this is probably a valid account. If not, then it’s probably not a valid email account, and someone could very likely be trying to send me spam. Let’s find out:
Connected to server.mailhost.com (126.96.36.199).
250-server.mailhost.com Hello server.receiving.com [188.8.131.52], pleased to meet you
MAIL FROM: firstname.lastname@example.org
RCPT TO: email@example.com
Apparently “firstname.lastname@example.org” is a valid email address. That means the sending account passes sender verification callout. At this point “server.receiving.com” disconnects from 184.108.40.206. Notice how the callout didn’t actually send a message – it just made sure that it’s possible to send mail to the address.
Now, if the account “email@example.com” is fake, then the DNS lookups for “sending.com” or “server.mailhost.com” might have failed, or a connection to 220.127.116.11 port 25 (SMTP) may have timed out, or the server at 18.104.22.168 may have just refused to accept a message for that account, with an error message like this:
550 No such domain at this location (firstname.lastname@example.org)
There are any number of ways the callout could have failed. What you need to know is that unless everything goes smoothly during the callout, the original message from server.sending.com (22.214.171.124) will be rejected by server.receiving.com (126.96.36.199) on the basis of “sender verification callout” or “sender verify callout”.
Moral of the story: Don’t send mail *from* an email address unless you can send mail *to* that same address.