Content deleted Content added
Marcperkel (talk | contribs) Reverting back to andrews version |
|||
| Line 1: | Line 1: | ||
'''Callback verification''', also known as '''callout verification |
'''Callback verification''', also known as '''callout 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. |
||
==Purpose== |
==Purpose== |
||
| Line 18: | Line 18: | ||
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. |
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 |
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 attack]]s, and by implication, the MAIL FROM/RCPT TO pair of commands should also respond the same way. |
||
==Limitations== |
|||
| ⚫ | |||
The documentation for both [[postfix (software)|postfix]] and [[exim]] do not recommend<ref name="postfix">[http://www.postfix.org/ADDRESS_VERIFICATION_README.html Postfix Address Verification Howto]</ref><ref name="exim">[http://www.exim.org/exim-html-4.50/doc/html/spec_39.html#SECT39.31 Exim Callout verification]</ref> using this technique and mention many limitations to SMTP callbacks. In parituclar, there are many situations where it is either ineffective or causes problems to the systems that receive the callbacks. |
|||
* [http://www.exim.org/exim-html-4.50/doc/html/spec_39.html#SECT39.31 Exim Callout verification] |
|||
* [http://www.postfix.org/ADDRESS_VERIFICATION_README.html Postfix Address Verification Howto] |
|||
* Some regular mail exchangers do not give useful results to callbacks: |
|||
** Servers that reject all bounce mails (contrary to the RFCs). To work around this problem, postfix uses either the local [[postmaster (computing)|postmaster]] address or an address of "double-bounce" in the MAIL FROM part of the callout. This work-around, however, will fail if [[Bounce Address Tag Validation]] is used to reduce [[backscatter (e-mail)|backscatter]]. Callback verification can still work if rejecting all bounces happens at the DATA stage instead of the earlier MAIL FROM stage, while rejecting invalid e-mail addresses remains at the RCPT TO stage instead of also being moved to the DATA stage.<ref name="postfix"/><ref name="exim"/> |
|||
** Servers that accept all e-mail address at RCPT TO stage but reject invalid ones at DATA stage. This is commonly done in order to prevent [[directory harvest attack]]s and will, by design, give no information about whether an e-mail address is valid and thus prevent callback verification from working.<ref name="postfix"/> |
|||
** Servers that accept all mails during the SMTP dialogue (and generate their own bounces later).<ref name="postfix"/> This problem can be alleviated by testing a random non-existent address as well as the desired address (if the test succeeds, further verification is useless). |
|||
** Servers that implement [[catch-all]] e-mail will, by definition, consider all e-mail addresses to be valid and accept them. Like systems that accept-then-bounce, a random non-existent address can be detect this. |
|||
* The callback process can cause delays in delivery because the mail server where an address is verified may use slow anti-spam techniques, including "greet delays" (causing a connection delay) and greylisting (causing a verification deferral).<ref name="postfix"/> |
|||
* If the system being called back to uses [[greylisting]] and returns a 4xx response code instead of a 5xx response code when given an invalid e-mail address, the callback will return no useful information until the greylisting time has expired.<ref>[http://projects.puremagic.com/greylisting/whitepaper.html The Next Step in the Spam Control War: Greylisting]</ref> |
|||
* Some e-mail may be legitimate but not have a valid "[[envelope from]]" address due to user error or just misconfiguration. The positive aspect is that the verification process will usually cause an outright rejection, so if the sender was not a spammer but a real user, they will be notified of the problem. |
|||
* If a server receives a lot of spam, it will do a lot of callbacks and if those addresses are invalid, the server will look very similar to a spammer who is doing a dictionary attack to harvest addresses. This in turn might get the server blacklisted elsewhere.<ref name="postfix"/> |
|||
* Every callback places an unasked for burden on the system being called back to, with very few effective ways for that system to avoid the burden. In extreme cases, if a spammer abuses the same sender address and uses it at a sufficiently diverse set of receiving MXs, all of which use this method, they might all try the callback, overloading the MX for the forged address with requests (effectively a [[Distributed Denial of Service]] attack). |
|||
* Callback verification has no effect if spammers spoof real email addresses. |
|||
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 addressas can be remembered. MTAs like [[Exim]] have caching built in.<ref name="exim"/> |
|||
| ⚫ | |||
{{reflist}} |
{{reflist}} |
||
==External links== |
|||
* [http://spamlinks.net/prevent-secure-backscatter.htm#callout spamlinks: Sender Callout Verification] |
|||
[[Category:Spam filtering]] |
[[Category:Spam filtering]] |
||
Revision as of 19:46, 20 February 2009
Callback verification, also known as callout 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.
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.