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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Apr 2003 17:42:29 -0700

> In two light readings of the document, I failed to find any explicit
> references to Verisign anti-spam authentication.  That may be 
> my error,
> or perhaps it will be discussed in a future document.

It is intended to be a survey of the whole field. The paper on the
velocity indicator is a separate one. Perhaps I should have sent
the two separately to avoid confusion.

> Relatively minor, easily seen problems in the current document are
>   - A definition of the spam problem based on 89 messages received by
>    one person is less than convincing.  Several times that 
> many messages
>    every day in my filters and traps have convinced me that you need
>    many thousands of samples drawn from many targets to say much.

I agree, however the point I was trying to make there was that you
do not need to have a huge sample to start to see a certain pattern,
i.e. a very large proportion is not simply junk it is outright fraud.

I don't think the sample size is the biggest problem, the fact there
is only one sample source and thus a huge bias is a bigger problem.

The point is that we should do some actual studies. We have some spam
traps going and we are collecting data for a bigger study. However
someone somewhere must be doing this in an academically rigorous way
surely?

>   - The section about blacklists in the document describes actions by
>    minor blacklists such as attempted extortion as if they were
>    representative.  They are not.

The extortion issue is a minor one, however the problem with 
accountability is a much larger one. I don't like the idea that my
ISP should just sign up for the Fox news or Pat Buchannan spam
blacklist without my consent. This type of thing tips into censorship
very quickly.

>   - On page 10, the document mischaracterizes NNTP as using a 
> "pull model."

NNTP is a pull model, both at the client to server and server to
server levels. Each server queries the others as to what is new 
within a particular set of newsgroups. Then individual messages
are requested on an individual basis.

>   - Page 13 seems to mischaracterizes the DCD as using 'honey-pots' or
>    other automated or manual spam sampling techniques and 
> "fingerprints"
>    of "known spam messages."  That is not what the DCC is about.

I sent you spome questions in that respect and you bounced them.

>   - Page 23 seems to deny the existence of SIEVE.

Does SIEVE have the buy in of the major email MTA and MUA software
vendors? Standards, shmandards, the test of a standard is support.
The road to hell is paved with Internet Drafts...

> There are other, more complicated errors in the document, such as
> its discussion of legislation and foreign sources of spam.

Be specific.

		Phill

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 25 Apr 2003 20:41:06 -0600 (MDT)

> From: "Hallam-Baker, Phillip" <[email-masked]>

> ...

> ...

I am bothered by the facile talk from many quarters of a spam corpus
of a few thousand messages collected over months or years.  Characterizing
spam in an academically rigorous way is hard and I heard of no serious
efforts in that direction.  If one doesn't have many current samples
from many addresses at many different kinds of domains, I do not see
how one could claim to have more than mildly interesting anectdotes.
We're talking about a population of 1,000,000,000s of messages sent
daily to 100,000,000s of addresses.  Any sample of fewer than 0.1% or
1,000,000s of messages/day (millions per day!) requires convincing
arguments that it is representative instead of mere anectdotes.

There have been major shifts to and fro in various characteristics of
spam in my traps.  For example, base64 encoding is much less common than
it was a few months ago.  Before that, it was less common than it is
now.  Those characteristics are representative, but only of what my
traps see, which is to say they are mere anectdotes.

> ...
> The extortion issue is a minor one, ...

Overstated or misleading rhetoric is not good when trying to convince
people of things they don't already believe.  Besides, I think you
mischaracterized those particular trivial incidents.  It is more
accurate to say anything from Verisign is the work of the devil because
of Verisign's history than to point at requirements for payments for
investigations by operators of what were in effect private blacklists
or to reason that the major blacklists are vigilantism because the
Rhyolite Software list of unwelcome domains is kooky.

> ...

The NNTP "ihave/sendme" server-server mechanism is not a "pull model"
similar to "pull" for email.  If the NNTP client-server or reading
mechanism is involves a "pull model", then so does email because of
IMAP and probably POP.  Besides, the "pulling" of NNTP had nothing
to do with controlling netnews spam.

> I sent you spome questions in that respect and you bounced them.

Descriptions of the DCC are easily found with
http://www.google.com/search?q=dcc

I think verisign.com has not received any "bounces" from my SMTP server.
However, there have been SMTP rejections.  As has been repeated
pointed out by others here, the distinction is significant.

Private conversations require minimal trust and mutual regard.

> ...

Do Verisign's ideas "have the buy in of the major email MTA and MUA
software vendors"?  The transition problem is real and cannot be
ignored for any mechanism.  I'm not optimistic about the likely
deployement of SIEVE (or its utility).  However, its prospects are
incomparably better than any proprietary offering, particularly from
Verisign.  It is not only that experienced and thinking people are
rightfully skeptical of proprietary solutions.  SIEVE could be useful
to the first user of the first implementation, while any authentcation
mechanism is useless until a significant fraction of the 500,000,000
Internet users sign up (and I think useless against spam even if that
were to happen).

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jim Youll <[email-masked]>
Date: Fri, 25 Apr 2003 23:08:59 -0400

>arguments that it is representative instead of mere anectdotes.

So, 89 isn't a very big number but...

when you back out the *redundancy* (most of those 1,000,000s a day
are like most of the others) what's really there? Granted there may be
some things that cannot be measured without knowing the true volume,
but surely useful information can be derived.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 25 Apr 2003 22:06:51 -0600 (MDT)

> From: Jim Youll <[email-masked]>

> >of a few thousand messages collected over months or years. ...

> but surely useful information can be derived.

Anecdotes contain useful information.  They can tell you that something
is happening.  What they cannot tell you is most of what
http://www.verisign.com/resources/wp/spam/no_spam.pdf seems to conclude
on page 2 and 3 (or 4 and 5 as counted by Ghostscript).  89 examples
can tell you that some spam comes from Korea and so forth.  Without
a lot of supporting evidence about the sampling, even 890,000 collected
over 60 hours cannot say whether 0.35%, 3.5%, or 35% of spam in general
is "mostly Korean, Chinese, and Japanese."

The same applies to every spam corpus that that has been mentioned in
this mailing list.  Despite its apparent skew from what I see as normal
spam (e.g. far too many virus/worms), those 89 messages are better
than some of the much larger collections, because more is known about
the nature of the target address(es?).

This should be about engineering.  That suggests that while it is
useful to know that some spam is, quantification is required.  Honest
quanitifcation of spam characteristics cannot be supported by tiny or
even large ad hoc collections.  I don't know where to start to build
a representative sample of spam except by collecting a significant
fraction of the total.  That would amount to 100,000,000 spam/day.
Even that tactic would have the major problem of collecting only spam
that your sampling mechanisms recognize as spam.  If your machinery
assumes that all mail that carries a certificate is not spam, then
you might conclude certificates solve the spam problem even if Ralsky
had purchased a certificate, chip, or whatever and was pumping out
1,000,000,000 messages/day.

 ...

Note that contrary that document, it generally makes no sense to talk
about valid BCC fields in incoming legitimate mail.  See page 37 of
RFC 2822.  I wouldn't be surprised if SpamAssassin treats a BCC
header as evidence of evil, because I can't recall ever seeing one
except in spam.  More important and also contrary to that document,
RFC 822 and RFC 2822 do *NOT* require that every incoming message name
the receipient in any SMTP header.  Most legitimate mailing list
messags are cases in point.

What discourages me most about this mailing list are self-described
expert statements such as "the RFC822 message standard requires every
message to have a valid To: CC: or BCC: field identifying the recipient,
making adjustment where necessary to account for messages relayed
through mailing lists."  There are obvious reasons why RFC 822 and
RFC 2822 do not require mailing list exploders to anything of the sort.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 26 Apr 2003 10:29:24 -0400

Vernon Schryver <[email-masked]> wrote:
> similar to "pull" for email.

  Mostly because there is no server-server "pull" for SMTP.  SMTP is
"push", and the problem is that spam is pushed down peoples throats.

>  If the NNTP client-server or reading mechanism is involves a "pull
> model", then so does email because of IMAP and probably POP.

  Which aren't SMTP.

  The spam problem is solely one with the SMTP protocool.  No one
claims that IMAP or POP have a major (or even minor) role in
originating spam.  If they were, we have a simple solution: stop
asking for messages from that imap/pop server.  All of the spam from
that server will instantly be gone, and will *never* come back.

>  Besides, the "pulling" of NNTP had nothing to do with controlling
> netnews spam.

  It gives the "pulling" server more control over the traffic it
accepts.  Too much spam in alt.sex?  Stop asking for it.  That can be
done with NNTP, IMAP, and POP, as they permit the "pull" host to not
ask for traffic, and that traffic stops.  It can't be done with SMTP.

  As I said in the first week this list started, a large part of the
spam problem is the design of the SMTP protocol.  It is *designed* to
permit anonymous originators, lying about message authors, redirection
of traffic to anyone, and traffic amplification.  No other network
protocol has all of these "features".  As a result, no other protocol
has the continuing problem that SMTP has.

  False analogies of SMTP to NNTP, IMAP, or POP aren't helpful.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 26 Apr 2003 10:40:01 -0400

"Alan DeKok" <[email-masked]> wrote:
>   Mostly because there is no server-server "pull" for SMTP.

  To be pedantic, ETRN allows servers to pull mail, but the majority
of email still flows through the original "push" mechanism.

  Alan DeKok.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 26 Apr 2003 09:47:19 -0600 (MDT)

> From: "Alan DeKok" <[email-masked]>

> > model", then so does email because of IMAP and probably POP.

That's irrelevant to my point that contrary to the other person's
claims, NNTP does not have a "pull model," at least not in the sense
meant here for mail, and that non-existent pull model is not responsible
for the control of netnews spam.

> 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.

>                                                           That can be

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.  The error is
saying that turning off traffic as in "stop asking for it" is a useful
control on netnews or email spam.  It is true that shutting down
netnews or email stops spam, but that is not a useful control.

A newsreader can fetch headers or even entire articles, and then apply
filters, but so can a POP or IMAP client and so can an SMTP server.

> has the continuing problem that SMTP has.

That's all true, and as I've been pointing out for many years, those
are all necessary and desirable characteristics of SMTP.  It is trivial
to turn off any or all of those troublesome characteristics of SMTP.
The reason none of those who proposes to "fixing" SMTP to not have
those characteristics bother to take the trivial steps to turn them
off (e.g. require SMTP-AUTH, S/MIME, PGP, and/or SMTP-TLS with recognized
certificates or keys) is that those problematic features are necessary
to receive mail from strangers.  They are part of any messaging protocol
that supports the receipt of messages from strangers.  You cannot
identify real strangers, which is to say you cannot meaningfully
authenticate them.  (Some of the other troublesome characteristics are
somewhat distinct.  For example, without "traffic amplification" this
mailing list could not exist.)

>   False analogies of SMTP to NNTP, IMAP, or POP aren't helpful.

That was my main point.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 26 Apr 2003 17:54:40 -0400

> 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.

> 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.

> 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.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 26 Apr 2003 17:28:30 -0600 (MDT)

> live with a broken protocol which is designed to be easily abused?

Again, it is not the protocol that is "broken" and "easily abused,"
but the design goal or problem statement.  If you really think that
SMTP is hopeless as protocol, then you should certainly quit because
this mailing list is not about tossing the design goal of public
mailboxes.  The rationalization for this mailing list is that there
are things that can to deal with spam without giving up on public
mailboxes.  That rationalization is justified by the many mailboxes
that receive less than 1% of the spam sent in their direction and
fewer than 1 spam/day.

> number (2) appears to allow multiple RCPT TO: with one DATA, and MTA's

The relatively new notion of SMTP command pipelining is not required
for multiple Rcpt_To commands in a single SMTP session.  Command
pipelining is about not waiting for responses to some commands in the
envelope until all of them have been sent.  Multiple Rcpt_To commands
have been a valuable optimization for MTAs hosting large mailing lists
for approximately forever.

The "spam gain" obtained by using multiple Rcpt_To commands and an
open relay is much less valuable on the modern Internet.  A case study
is the artauction/art-server/artserver/etc. spammer that apparently
uses much of a T3 to send millions of 5-8 KByte messages, one SMTP
session per spam target.  He has been at it for a long time.

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 27 Apr 2003 02:35:33 -0400

> are requested on an individual basis.

Sorry, no.  Standard/normal server-to-server NNTP feeds are PUSH 
(ihave/sendme protocol).  There are some feeds using reader pull methods 
(ie: "suck" or "slurp" tools), but they're grossly inefficient, and are 
generally quite small.

Client-to-server is indeed PULL.

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 27 Apr 2003 10:11:05 -0400

Vernon Schryver <[email-masked]> wrote:
> but the design goal or problem statement.

  So the SMTP protocol is designed with to have features that permit
it to be easily abused.  SMTP servers are often implemented poorly,
which further enables abuse.  So our design is broken, but the
protocol is OK.  Hmm...

> If you really think that SMTP is hopeless as protocol, then you
> should certainly quit because this mailing list is not about tossing
> the design goal of public mailboxes.

  I fail to see how SMTP=="public mailboxes".  SMTP permits public
mailboxes, but public mailboxes don't require SMTP.  Is there no other
possible method of delivering mail?  Do we lack sufficient imagination
to see how a protocol other than SMTP may yeild public mailboxes?

  Maybe SMTP is perfect the way it is.  Maybe we can tweak the
implementations and configurations of SMTP servers to eliminate the
spam problem.  But I still don't understand why there is huge
opposition to even discussing solutions other than SMTP.

  I would like to discuss how we would design a protocol and
implementation requirements for it which would be resistant to spam.
Maybe we'll discover that SMTP satisfies all of the requirements.  But
when anyone mentions non-SMTP solutions, a number of people stick
their fingers in their ears and shout "la-la-la".  This confuses me.

  Maybe the list should be re-named to "asrg, but only within the
context of SMTP, and without changes to SMTP".

> open relay is much less valuable on the modern Internet.

  Or local delivery?  Where one spam message gets delivered to many
local users.  This was a significant percentage of the spam traffic at
my domain, the last time I checked.

  The "valuable optimization for MTAs hosting large mailing lists" is
a feature which directly contributes to the spam problem.

  We could say similar things for IPSec: It's expensive for commodity
hardware to do 1,000's of simultaneous sessions on a VPN gateway.  So
we make a "valuable optimization", and fall back to ROT13.  Presto!
Cheap IPSec hardware, that runs quickly!

  Sometimes the best thing to do is the expensive thing to do.  But if
our requirements for "public mailbox" systems include "valuable
optimizations" that permit abuse, then we've failed even before we've
started.

> A case study is the artauction/art-server/artserver/etc. spammer
> that apparently uses much of a T3 to send millions of 5-8 KByte
> messages, one SMTP session per spam target.  He has been at it for a
> long time.

  "anecdotal evidence".

  Alan DeKok.