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

> 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

smime.p7s
Description: S/MIME cryptographic signature