ietf-asrg
[Top] [All Lists]

Re: [Asrg] A New Plan for No Spam / Velocity Indicator

2003-04-26 14:50:32
Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> wrote:
  It gives the "pulling" server more control over the traffic it
accepts.  Too much spam in alt.sex?  Stop asking for it.

That is wrong or irrelevant.  Netnews spam was and is not controlled
by trimming newsfeeds files.

  ... on servers.  Individual users of NNTP can still decide to trim
*their* reading of usenet, to avoid areas containing large amounts of
spam.  That can't be done easily with SMTP.  You've got to set up
local filters, which have unknown (and possible large) false
positives/negatives.  At least by not reading alt.sex, you *know*
you're choosing a 100% false positive rate.

  It's basic psychology.  Most of the time, people will choose
well-known negatives over the unknown.

I don't agree unless you add SIEVE to the mix, and then it is still
wrong about netnews.  A netnews "reader" (e.g. trn) cannot ask a
netnews server for the non-spam articles in a group.

  I agree.  That's an implementation choice.  Many MUA's are adding
spam filtering, so I see no reason why the same couldn't be done for
NNTP clients... except for the fact that spam isn't as much of a
problem there.

That's all true, and as I've been pointing out for many years, those
are all necessary and desirable characteristics of SMTP.

  Then why are we wasting our time in ASRG?  Why not just give up, and
live with a broken protocol which is designed to be easily abused?

  I'd like to think more positively.  If it's possible to fix the SMTP
protocol or implementations to work around these issues, then we can
by design, avoid much of the spam problem.

You cannot identify real strangers, which is to say you cannot
meaningfully authenticate them.

  I agree.

 (Some of the other troublesome characteristics are somewhat
distinct.  For example, without "traffic amplification" this mailing
list could not exist.)

  I disagree.  The "traffic amplication" of lists is an MTA which accepts
one message, and chooses to send copies to multiple destinations.  The
"traffic amplification" is RFC 2197 comman pipelining.  Section 4.2,
number (2) appears to allow multiple RCPT TO: with one DATA, and MTA's
allow this.

  Due to poor MTA implementation, one message to multiple recipients
may be stored multiple times.  This is more difficult to do with NNTP
messages, due to both protocol and implementation differences.

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



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