on Mon, Sep 22, 2003 at 10:40:07AM -0700, JLM ([EMAIL PROTECTED]) wrote:
> on Thu, Sep 22, 2003, Karsten M. Self" <[EMAIL PROTECTED]> wrote:

> > What makes your spam better than the original spammer's?
> 
> Who said it was better?

Ah.  So you concede the point.

Thank you.



> >> The latter is unfortunate, but TMDA hardly relies on it.  It's more of
> >> a grudging acceptance of reality. Most challenges are sent to spoofed
> >> addresses, but there's not much anyone can do about that.
> > 
> > Bollux.  There are existing content/context based filters which
> > discriminate between spam and non spam with better than 98% accuracy,
> > and less than 0.02% false positive rates.
> 
> Not bollux. Yes, there are other spam reduction tools, and it would be
> great if more C/R users put them to use before issuing challenges. I
> do, and thus very few "C/R spam" messages, as you like to call them,
> are issued at all.  But even in this scenario, the number of
> challenges sent to spoofed addresses (that get past SpamAssassin) will
> exceed the number sent to legitimate correspondents. My original point
> stands: there's not much anyone can do about this.

Objection on the basis of inachievability of perfection.

A 98% reduction in false challenges would be a 98% improvement over the
current situation.  This works to the benefit of TMDA/C-R inasmuch as
people don't automatically treat C-R challenges themselves as spam.

> >> It's more important to make sure that (a) recipient in-boxes aren't
> >> inundated,
> > 
> > How do you plan to coordinate the actions of your personal C-R node with
> > that of tens, hundreds, thousands, or millions of other C-R users?  Last
> > I checked, this was technically infeasible.
> 
> (yawn)

Noted.

Is there any reason you don't take this criticism seriously?



> >> and (b) valid correspondents are able to get through
> > 
> > Of course.
> > 
> >> (albeit after going through the challenge).
> > 
> > If they're valid in the first place, and you can determine this, why
> > challenge them?  Ego-stroking on your part?

> If messages are flagged as spam, they don't get challenged. If they
> match the white list, they don't get challenged. Clearly I can't
> determine whether they are valid if (a) their message passes through
> SpamAssassin and (b) they aren't on my white list. That's why they get
> challenged. Your "ego-stroking" assertion is both laughable and sad at
> the same time.

What portion of the messages passing both virus and spam filtering turn
out to be reasonably challenged?  That is, how many of these are mail
you wouldn't have read in the absense of TMDA or C-R?  And what is your
basis for determining that a third party is the appropriately tasked
with solving this problem for you?  Your premise for sending the
challenge is to authenticate the sender.  And that on the basis of the
inability for you to authenticate the sender, that it is the purported
sender's responsibility to accept this task from you.

I reject this premise.


> >>> He refuses to respond to them on principle. He claims he is not
> >>> alone.
> >> 
> >> I'm sure he is not alone. But I personally have little desire to
> >> accommodate obstinate folks. That type of response sounds to me like:
> >> "Sorry, but my time is more important than your time."
> > 
> > No, it sounds to me like a perfectly valid reaction.  Your reason for
> > sending a challenge is that you can't determine that a given sender is
> > valid.  What's your basis then for deciding that I am the person who has
> > to solve this problem for you?
> 
> Because it's my in-box. Not yours.

Precisely.

There's no basis for me to determine what is in your inbox, moreso if
the mail wasn't sent by me.  I've been saying this consistently since
2001 in my GPG rant:

    http://kmself.home.netcom.com/Rants/gpg-signed-mail.html

    Why is it your responsibility? Simple: you know you've received mail
    from me. I may or may not know I've sent it. As is well known, email
    is an insecure, unauthenticated medium. It's quite possible that
    someone is sending something claiming to be someone they aren't. In
    fact, this happens as a matter of course with spam. Since you (the
    recipient) have the evidence in front of your eyes, and I've no idea
    it's been sent, if it's not from me, the burden of authentication
    lies with the recipient.

    If it's not signed by me, your assumption should be that it isn't
    from me.

> > I receive a fair amount of spam for spam mitigation systems.
> 
> I'm sorry to hear that.
> 
> > I suppose by your logic that these are acceptably legitimate mails,
> > as they are spam in the name of reducing spam.  That's what C-R
> > challenges to spoofed addresses are, after all.
> 
> As I said before, running SpamAssassin and other spam filtering tools before
> TMDA renders this point (and nearly all of your other points) quite moot.

Fully admitted.  I've stated this explicitly.  My point is that this
isn't an option, it's a requirement.

The full list of requested remedies, from debian-devel / Debian BTS:

  http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03765.html

    My suggested remedies are as follows:

      - TMDA should be configured, by default, with C-R disabled.  This
        appears to be the case currently.

      - TMDA should carry a warning to the user about possible consequences
        of activating the C-R mechanism, including sending spam, risking
        blacklisting or registration in spam-reduction services such as
        SpamCop, and a likelihood that some, and perhaps a majority of
        challenges will not be responded to.  The warning should require the
        user to assume full responsibility for doing so.

      - Challenges should only be sent as a last resort.

      - Configuration templates for C-R challenges _must_ incorporate virus
        and spam filtering, _prior_ to issuing a C-R challenge.  Preferably,
        tests against obvious header spoofing, if possible, should be
        performed.  Debian tmda packages _must_ depend on corresponding spam
        and virus filters, if this functionality isn't built into TMDA.

      - Additional strong validation mechanisms, including RFC 2015 PGP
        signed mail and S/MIME signatures, _must_ be used to validate
        sender, including use of web of trust to identify a reasonable
        probability of trusted user status.

      - If possible, TMDA should be moved to SMTP-time filtering, so that
        mail rejection occurs at SMTP time.  As SMTP doesn't offer a
        protocol for challenge-response, this introduces interesting
        challenges for TMDA's developers.

      - TMDA's performance _must_ be independently validated and the target
        maximum of 2% challenges to spoofed addresses be confirmed.

   

> >> As has been said by others many times before, I refuse (on principle)
> >> to allow my in-box to become a hell-hole
> > 
> > If you're swallowing the line that TMDA/C-R is the only way to keep your
> > inbox clean, you're sadly deluded.
> 
> A rather silly assumption on your part. I never said TMDA/C-R is the only
> way. Better to think of it as a useful last line of defense.

Small argument.  I still feel it's unwarranted.  However the harm is
largely mitigated.  I can live with users shooting themselves in the
foot.  I draw the line when the target is my own or innocent third
parties.

> >> just because a few curmudgeons can't take five seconds out of their
> >> day to do a one-time confirmation that they're human.
> > 
> > How many of those five second decisions are going to be based on spoofed
> > challenges?
> 
> Given that I'm using other spam filtering tools before TMDA? Almost zero.

OK, find, that covers you.

What's my assurance that a given C-R challenge comes from someone with
your foresight, consideration, skills, and concomittant accuracy?

Nil?  Or close enough for government purposes?

And as a consequence, my decision to /dev/null the requests is
vindicated in my eyes.  Note that this demonstrates what I call C-R's
social response memetic failure:  You're relying on an uncontrolled
element, the challenge recipient's response, to be predictable.  Abuse
me, deride me, handwave me, dismiss me.  Your problem hasn't gone away.

> > Again:  what makes your spam more valid than the original spammer's?
> 
> Again: moot.

In your case perhaps.

I'll re-ask the question in the general case of C-R:  what makes a C-R
challenge to a spoofed address more valid than the original spam?


> >> Nobody questions whether C/R is annoying. But to shun it on principle
> >> is to deny us the one truly useful weapon we have in this war.
> > 
> > Again, wrong.  What is your basis for determining that all other methods
> > fail?  Where is your empirical proof?
> 
> Not wrong. You're misinterpreting my use of "one truly useful weapon."
> Clearly tools like SpamAssassin are useful -- just not foolproof. 

Not foolproof.  Sufficient.

*That* is the specific claim of the TMDA homepage.  I quote:
"Content-based filters can't distinguish SPAM from legitimate mail with
sufficient accuracy".  It is a false statement.


> C/R is the one tool that allows me to filter the very few messages
> that get through.
> 
> Your stance is:
> 
> "If very few messages get through, why not just delete them? Why
> bother with TMDA at all?"
> 
> Answer: because I choose to. Because I don't like spam. Because very
> few of my challenges are sent to spoofed addresses.

Then deal with the consequences.


Should you spam me, however, I will take an appropriate response.

> > Peace.
> 
> I always love it when people make unnecessarily snide remarks and then
> finish up with a "can't we all just get along?" tagline. Highly comical.


Peace.

-- 
Karsten M. Self <[EMAIL PROTECTED]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
  TWikIWeThey: An experiment in collective intelligence.  Stupidity.  Whatever.
    Technical docs, discussion, reviews, opinion.
      http://twiki.iwethey.org/

Attachment: signature.asc
Description: Digital signature

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to