At 10:39 AM 10/14/2008 -0700, Michael Deutschmann wrote:
>On Mon, 13 Oct 2008, David MacQuigg wrote:
>> I didn't see any response to my suggestion of sending a challenge to
>> the author via SMTP reject. That still seem like the better alternative,
>> and one that doesn't have the "weak antibiotic" problem.
>
>Uh, of all the anti-spam methods, C/R is probably the poster child for
>the antibiotic problem.
We need to define what we mean by "weak antibiotic". I would say that an anti-spam tactic has this problem when it is so weak that it encourages the development of better spamware to nullify the tactic. Is it likely that spamware will attempt to nullify C/R systems?
>When a single person uses a homebuilt C/R, it's extremely effective, with
>the only false negatives being when the backscattering variant is used and
>angry backscatter victims deliberately confirm forged e-mail to punish the
>C/R user.
I would not call a C/R system with backscatter a "variant". A better word would be "mistake", or "bad design".
>But if it's widely deployed, many people will be using identical C/R
>software, and spamware will be extended to handshake with it. Captcha is
>not an impregnable obstacle.
There are many ways to implement a challenge. Even with CAPTCHA, you can dial up the difficulty enough to make it unprofitable for spammers, but not too difficult for individual authors with important messages. I would sure like to see some data on this, but my guess is that even 30 seconds of effort to find a webpage would be enough. Add a paragraph of instructions that change from day to day, and spammers will not be able to automate a response.
The important point is the variability of the challenge, even if every Receiver in the world is using identical C/R software. Spamware developers will not even try, if they know that it is easy for Receivers to change the challenge. Think about how you would write a challenge with endless variations only a human would understand. It's not difficult.
>We just haven't seen this because most people competent enough to
>implement C/R reject it out of hand due to the backscatter problem, which
>has clamped usage to the point that spammers haven't had to adapt.
I have seen discussions like this go on for days, with the anti-C/R folks assuming that all C/R systems have backscatter, and not even acknowledging statements to the contrary.
>C/R in the 550 message, as you propose, avoids the backscatter problem
I'm glad to see you are not one of those folks.
>but not the antibiotic problem. It also has the issue that some senders
>may not ever see the 550 text.
Let's drop the word "sender", since we now need a little more precision. If the Transmitter does not handle the text of the SMTP reject message properly, and by that I would assume simply relay it to the original Author of the message, if that is the problem, it is not the Receiver's responsibility. The Receiver has done his job by sending a clearly-worded reject message.
If both the Receiver and the Transmitter do their job, and the problem is that the Author does not know what to do, he needs to ask his mail-system admin. Receivers cannot be held responsible for these kind of problems on the sending side.
Has anyone read Erickson's paper on whitelisting? http://www.ceas.cc/ Would you agree that this is a good use of C/R?
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
>On Mon, 13 Oct 2008, David MacQuigg wrote:
>> I didn't see any response to my suggestion of sending a challenge to
>> the author via SMTP reject. That still seem like the better alternative,
>> and one that doesn't have the "weak antibiotic" problem.
>
>Uh, of all the anti-spam methods, C/R is probably the poster child for
>the antibiotic problem.
We need to define what we mean by "weak antibiotic". I would say that an anti-spam tactic has this problem when it is so weak that it encourages the development of better spamware to nullify the tactic. Is it likely that spamware will attempt to nullify C/R systems?
>When a single person uses a homebuilt C/R, it's extremely effective, with
>the only false negatives being when the backscattering variant is used and
>angry backscatter victims deliberately confirm forged e-mail to punish the
>C/R user.
I would not call a C/R system with backscatter a "variant". A better word would be "mistake", or "bad design".
>But if it's widely deployed, many people will be using identical C/R
>software, and spamware will be extended to handshake with it. Captcha is
>not an impregnable obstacle.
There are many ways to implement a challenge. Even with CAPTCHA, you can dial up the difficulty enough to make it unprofitable for spammers, but not too difficult for individual authors with important messages. I would sure like to see some data on this, but my guess is that even 30 seconds of effort to find a webpage would be enough. Add a paragraph of instructions that change from day to day, and spammers will not be able to automate a response.
The important point is the variability of the challenge, even if every Receiver in the world is using identical C/R software. Spamware developers will not even try, if they know that it is easy for Receivers to change the challenge. Think about how you would write a challenge with endless variations only a human would understand. It's not difficult.
>We just haven't seen this because most people competent enough to
>implement C/R reject it out of hand due to the backscatter problem, which
>has clamped usage to the point that spammers haven't had to adapt.
I have seen discussions like this go on for days, with the anti-C/R folks assuming that all C/R systems have backscatter, and not even acknowledging statements to the contrary.
>C/R in the 550 message, as you propose, avoids the backscatter problem
I'm glad to see you are not one of those folks.
>but not the antibiotic problem. It also has the issue that some senders
>may not ever see the 550 text.
Let's drop the word "sender", since we now need a little more precision. If the Transmitter does not handle the text of the SMTP reject message properly, and by that I would assume simply relay it to the original Author of the message, if that is the problem, it is not the Receiver's responsibility. The Receiver has done his job by sending a clearly-worded reject message.
If both the Receiver and the Transmitter do their job, and the problem is that the Author does not know what to do, he needs to ask his mail-system admin. Receivers cannot be held responsible for these kind of problems on the sending side.
Has anyone read Erickson's paper on whitelisting? http://www.ceas.cc/ Would you agree that this is a good use of C/R?
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com