ietf-asrg
[Top] [All Lists]

RE: [Asrg] C/R - What people say

2003-05-15 17:00:18
At 06:14 PM 5/15/2003 -0400, Daniel Feenberg wrote:

On Thu, 15 May 2003, Vernon Schryver wrote:

>
> What is the real goal a C/R system?  I thought it had something to do
> with reducing "spam."  How does spam differ from any other bulk mail
> except in whether it is solicited?
>
> As I've pointed out, a substantal amount of the unsolicited bulk
> mail in my traps has headers just like mail from other "lists"
> including this one.
>
> If a C/R system only stops spam from transient, "hit-and-run" systems
> that do not stand still long enough to receive and answer a challenge,
> it won't be very impressive.
>

I was hoping someone would bring this up. I didn't because it seemed like
I was missing something. Did I also miss the discussion of how two C/R
systems would interact if both sender and receiver have them? This must
have come up in real life - do the users of these systems have experience
to relate?

I would have thought the role of standardization in the C/R system would
not be to standardize the challenge, which needs to be non-standardized so
that automated systems can't respond effectively, but rather to provide an
effective route around the C/R system for legitimate lists.

At this point, as outlined, Eric is proposing an automated protocol for C/R not for internal use but for actually responding to challenges automatically. As I mentioned before, we need to better define the goals of C/R. Is is to make sure that senders are legit, or is it going to an extra level to making sure the sender is human (essentially creating a Turing Test). As for having spammers set up automatic responders, see TDMA FAQ, section 1.1 (http://tmda.net/faq.cgi?req=all):

------snip--------
"1.1. Can't spammers just setup an auto-responder to defeat TMDA? *

In theory yes, but in practice this is not likely to happen. Most SPAM is unrepliable, so TMDA's confirmation requests are never delivered to them. They use non-valid return addresses as to not incur the cost of the tremendous number of bounces they generate. Using a valid return address to process all the bounces looking for confirmation messages to auto-reply to would defeat their economies of scale. It would also make them easy to block, track down and report, sue, etc. In short, trying to thwart TMDA in this manner would defeat the cost-effectiveness of the bulk-mailing process. Simple economics keep us safe.

But should these facts change, TMDA could modify its (currently very simple) challenge/response to make it more difficult for a computer to auto-reply to. The level of difficulty could increase as much as is necessary for the sender to prove their humanity and legitimacy.

The idea is to keep the challenge/response as simple as possible to avoid inconveniencing legitimate senders, while at the same time difficult enough to thwart an automated response system. At the present time, TMDA offers the ability to confirm by a simple e-mail reply, or by clicking on a URL. There is no evidence to suggest that a more challenging procedure is even close to necessary.

If spammers do resort to auto-confirmation however, we've won a huge battle for the community by raising the bar and forcing them to leave a breadcrumb trail leading back to their lair. As the focus on legislation continues, and spamming becomes an increasingly illegal activity, who will take these great risks for such a little reward? "
-----snip--------

Perhaps the primary purpose of C/R should be counteracting the basic flaw in SMTP that allows anyone to send email without verifying who the sender is? Or perhaps not? Disabling the ability for automated systems to be able to send email is something we might not want to do. There are also various other issues, such as the ones raised in section 7.1 of RFC 2821 which as we mentioned apply to mailing lists.

Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>