Callback Verification Article Index for
Callback 		Website Links For
Callback 		 

Information About

Callback Verification
  CATEGORIES ABOUT CALLBACK VERIFICATION
   
spam filtering
   
anti-spam
   
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...




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 Record s), pretending to be creating a bounce, but stopping just before any e-mail is sent. The commands sent out are:

HELO
MAIL FROM:<>
RCPT TO:
QUIT

This technique is technically compliant with the relevant SMTP RFCs (RFC 2821).


DRAWBACKS


STMP callbacks can have several drawbacks:
  • Some regular mail exchangers do not give useful results to callbacks:

  • --- Servers that reject all bounce mails (contrary to the RFCs). This problem can be alleviated by using the local Postmaster address in the MAIL FROM part of the callout.

  • --- Servers that accept at RCPT stage but reject at DATA stage.

  • --- Servers that accept all mails during the SMTP dialogue (and generate their own bounces later). 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).

  • 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).

  • 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.

  • 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).


Several of the above problems are alleviated by Caching of verification results, which reduces the amount of duplicate callbacks.

There are also two essential problems with callbacks:
  • spending other people's resources to implement an anti-spam measure

  • as spammers move to real addresses instead of forged ones, the measure becomes ineffective



COMMON MISTAKES IN IMPLEMENTATIONS


  • Some implementations treat a 4xx SMTP error code as a 5xx SMTP error code - this is clearly wrong and they should only fail on a 5xx error.

  • Some implementations cache per host eg. they get a sender verify call out failure for address@domain.test and then list the entire ---@domain.test as bad!



REFERENCES



SEE ALSO

  • VRFY , an SMTP extension used to verify the existence of an address

  • EXPN , an SMTP extension used to expand an alias or mailing list