Callbacks: Difference between revisions
No edit summary |
m (callout -> callback) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{ast | |||
|date=early 2000s | |||
|difficult=Low | |||
|popular=Low | |||
|effective=Low | |||
|harm=High | |||
|where=MTA | |||
}} | |||
''(Also known as Callouts)'' | |||
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. | 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. | |||
Latest revision as of 13: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.
