Callbacks: Difference between revisions

From ASRG
Jump to navigationJump to search
No edit summary
m (callout -> callback)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{ast
{{ast
|date=early 2000s
|date=early 2000s
|difficult=medium
|difficult=Low
|popular=Low
|popular=Low
|effective=Low
|effective=Low
Line 8: Line 8:
}}
}}


SMTP server connects to SMTP client on port 25 during transaction. 
''(Also known as Callouts)''


Usually, following MAIL FROM and at least one RCPT TO, the SMTP server opens a connection to the SMTP client system on port 25 and uses the RCPT TO value in a MAIL FROM commands, and the MAIL FROM value in a RCPT TO command, in an attempt to see if the client system is an SMTP server and accepts mail.
During an SMTP transaction, following MAIL FROM and at least one RCPT TO from the client, the SMTP server opens a connection to the host name in the MAIL FROM address and uses the RCPT TO value in a MAIL FROM commands, and the MAIL FROM value in a RCPT TO command, in an attempt to see if the client system is an SMTP server and accepts mail for that address.


This is a deceptively attractive approach, since it appears to validate the client system as a proper server.  However, it quickly runs into numerous problems.  The most severe is that if both systems try this, they both deadlock and mail cannot be exchanged. Other problems include temporary unavailability of the mail system, sites which operate separate systems for sending and receiving mail, etc.
This is a deceptively attractive approach, since it appears to validate the client system as a proper server.  However, it quickly runs into numerous problems.  The most severe is that if both systems try this, they both deadlock and mail cannot be exchanged.
The usual way to avoid this is to do the callback as a fake bounce with a <> null sender address.
 
The most obvious problem is that it doesn't work to verify addresses. There's lots of reasons why the naively implemented checks that callbacks use can succeed for a non-existent address or fail for a good address. Some mail systems accept all addresses at the RCPT TO, and reject the bad ones at the DATA command, giving the callback system the mistaken impression that bad addresses are good. Conversely, systems that implement techniques against spam blowback (bounces from spam forging their addresses) can often reject callbacks because they look just like blowback, giving the callback system the mistaken impression that good addresses are bad.
 
Even when it works, address verification is not an effective spam filter. These days most spam uses other people's real addresses taken from the spam target lists, so all you're verifying is that they stole someone's address.
 
Callbacks are abusive. Since upwards of 90% of mail is spam with forged addresses, 90% of your callbacks are to people who never sent you mail or otherwise bothered you.
 
Callbacks are likely to get you blacklisted, since the behavior of callbacks is indistinguishable from spammers trying to to do bulk listwashing of bad addresses.
 
Callbacks are discredited. Every large ISP that used to do callbacks, most notably Verizon, found it was counterproductive and stopped.

Latest revision as of 14:57, 12 August 2008

Anti-spam technique: Callbacks
Date of first use: early 2000s
Effectiveness: Low
Popularity: Low
Difficulty of implementation: Low
Where implemented: MTA
Harm: High


(Also known as Callouts)

During an SMTP transaction, following MAIL FROM and at least one RCPT TO from the client, the SMTP server opens a connection to the host name in the MAIL FROM address and uses the RCPT TO value in a MAIL FROM commands, and the MAIL FROM value in a RCPT TO command, in an attempt to see if the client system is an SMTP server and accepts mail for that address.

This is a deceptively attractive approach, since it appears to validate the client system as a proper server. However, it quickly runs into numerous problems. The most severe is that if both systems try this, they both deadlock and mail cannot be exchanged. The usual way to avoid this is to do the callback as a fake bounce with a <> null sender address.

The most obvious problem is that it doesn't work to verify addresses. There's lots of reasons why the naively implemented checks that callbacks use can succeed for a non-existent address or fail for a good address. Some mail systems accept all addresses at the RCPT TO, and reject the bad ones at the DATA command, giving the callback system the mistaken impression that bad addresses are good. Conversely, systems that implement techniques against spam blowback (bounces from spam forging their addresses) can often reject callbacks because they look just like blowback, giving the callback system the mistaken impression that good addresses are bad.

Even when it works, address verification is not an effective spam filter. These days most spam uses other people's real addresses taken from the spam target lists, so all you're verifying is that they stole someone's address.

Callbacks are abusive. Since upwards of 90% of mail is spam with forged addresses, 90% of your callbacks are to people who never sent you mail or otherwise bothered you.

Callbacks are likely to get you blacklisted, since the behavior of callbacks is indistinguishable from spammers trying to to do bulk listwashing of bad addresses.

Callbacks are discredited. Every large ISP that used to do callbacks, most notably Verizon, found it was counterproductive and stopped.