Callback verification

For the "callback verifier" software once commonly used by dial-up bulletin board systems, see Callback (telecommunications)#Modem security.

Callback verification, also known as callout verification or Sender Address Verification, 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.

The three hosts involved in an SMTP callout verification. If the address is not forged, the sender and the MX server may coincide.

Purpose

Since a large percentage of e-mail spam is generated from a forged sender ("mfrom") addresses, some spam can be detected by checking whether forging resulted in an invalid address, using this method.

A related technique is "call forwards", in which a secondary or firewall mail exchanger can verify recipients at the primary mail exchanger for the domain in order to decide whether the address is deliverable.

Process

The receiving mail server verifies the sender address, by verifying both parts of the sender address - the domain name (part after the @ character), and the local part (part before the @ character). The first step is to establish a successful SMTP connection to the mail exchanger for the sender address. The mail exchanger is found by looking up the MX records in the domain's DNS zone. The second step is to query the exchanger, and make sure that it accepts the address as a valid one. This is done in the same way as sending an email to the address, however the process is stopped after the mail exchanger accepts or rejects the recipient address. These are the same steps the receiving mail server would take to bounce mail back to the sender, however in this case no mail is sent. The SMTP commands sent out are:

HELO <verifier 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 (a Best Current Practice) recommends, by default, disabling the VRFY command to prevent directory harvest attacks. (One widespread interpretation implies that the MAIL FROM/RCPT TO pair of commands should also respond the same way, but this is not stated by the RFCs.)

Limitations

The documentation for both postfix and exim caution against the use[1][2] of this technique and mention many limitations to SMTP callbacks. In particular, there are many situations where it is either ineffective or causes problems to the systems that receive the callbacks.

Some of these problems are caused by originating systems violating or stretching the limits of RFCs; verification problems are only reflecting these problems back to the senders, like unintentionally used invalid addresses, rejection of the null sender, or greylisting (where, for example, the delay caused by the verifying recipient is closely related to the delay caused by the originator). In many cases this in turn helps originator system to detect the problems, and fix them (like unintentionally not being able to receive valid bounces).

Several of the above problems are reduced by caching of verification results. In particular, systems that give no useful information (not rejecting at the RCPT TO time, have catch-all e-email, etc.) can be remembered and no future call backs to those systems need to be made. Also, results (positive or negative) for specific e-mail addresses can be remembered. MTAs like Exim have caching built in.[2]

References

External links

This article is issued from Wikipedia - version of the Sunday, April 17, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.