Callback verification

'Callback verification, also known as callout verification or sender address verification (SAV) , is a technique used by SMTP software in order to validate e-mail addresses. The most common target of verification is the sender address from the message envelope (the address specified during the SMTP dialogue as "MAIL FROM"). It is mostly used as an anti-spam measure.

Purpose

Since a large percentage of e-mail spam has forged sender ("from") addresses, some spam can be detected by checking that the sender address is valid using this method.

Another context where callbacks can be used is the communication between different mail servers - for example, a secondary mail exchanger can verify recipients at the primary mail exchanger for the domain in order to decide whether the address is deliverable.

Process

A mail server can try to verify the an address by making an SMTP connection back to the mail exchanger for it (found via the usual MX records), pretending to be creating a bounce, but stopping just before any e-mail is sent. The commands sent out are:

    HELO <local host name>
    MAIL FROM:<>
    RCPT TO:<the address to be tested>
    QUIT

Equivalently, the MAIL FROM and RCPT TO commands can be replaced by the VRFY command, however the VRFY command is not required to be supported and is usually disabled in modern MTAs.

Both of these techniques are technically compliant with the relevant SMTP RFCs (RFC 5321), however RFC 2505 recommends controlling the use of the VRFY command to prevent directory harvest attacks, and by implication, the MAIL FROM/RCPT TO pair of commands should also respond the same way.

Implementation Issues

In implementing callback verification it is important to keep in mind that each callback creates some load on the server of the domain being verified. If a spammer is spoofing a domain and the domain is hosted on a low speed connection or has other resource limitations it could significantly impact that server's ability to send and receive email. It is therefore important to use this technology lightly so as not to inadvertently cause problems for innocent third parties. Thus in order to increase the speed of your spam filtering and reduce the load of call outs on other servers, callback verification should be used after other spam filtering technologies have been tried.

Several Mail Transfer Agents such as Exim, Postfix and Sendmail support callback verification technology. But callback verification is more process and bandwidth intensive that other spam fighting technologies such as DNSBLs, checking HELO, and other types of more efficient checks. Another example is to verify the recipient first before verifying the sender so if the recipient is invalid the sender need not be checked.

Developers of callback verification software should cache results of recent callbacks so that a callback isn't performed for every message received. It is good practice to keep the volume of callbacks down so that the spoofed domain isn't burned with responding to excessive callback requests.

Implementing Callback Verification Support

Callback verification support allows other email servers to query your server to verify if an email address is actually valid. Supporting these callbacks has several advantages.

It allows other email servers to determine if the sender is good and reject email from spoofed senders that don't exist. This helps other email servers to blacklist spam sources so that spammers who use your domain for spoofing get blacklisted.

It reduces backscatter because email can be rejected at connect time as an invalid sender rather than later generating a bounce message that is wrongly returned to your server.

Spammers tend to avoid using spoofed domains that support callback verification because they are less likely to successfully deliver their spam and more likely to get their spam servers blacklisted. Spammers tend to spoof domains that seem to accept email destined for any email address.

To support callbacks from other servers so that they can verify email addresses for your domains.

Wildcard addresses or catchall addresses should be avoided because if your email server will accept any email address (*@yourdomain.com) then it both attracts spam and attracts spammers to spoof your domain when spamming others.

Avoid rejecting email from empty senders <> at the MAIL stage. If you are going to reject all bounce messages it is better to do it at the DATA stage.

Reject bad recipients at the RCPT stage, not the DATA stage.

Use a 5xx response, not a 4xx response, to reject bad recipients.

Avoid using SMTP delays and greylisting on verification calls.

References