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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Apr 2003 15:43:14 -0700

> reminds me of the infamous "V-chip" and we all know how that one 
> turned out... 

It was deployed and ignored because most people were not that bothered about
the issue. However it did have the effect of preventing TV programs being
dumbed down to the level of what gives least offense.

I don't think anyone is proposing going to congress to force people to use
this technology either producing or receivng.

> is this a plan for no spam, 
> or a plan to make lots of money for verisign? why sugar coat it?

I don't see why those should be considered contradictory goals. I think any
commercial entity that can find a solution is likely to profit from it.

The velocity indicator is only one of the proposals in the paper. However it
is the only one that had not been previously published in any form.

The schemes it competes against would be considerably more costly to the end
user and are also encumbered.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Apr 2003 20:14:28 -0700

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

But in the case of a standardized interface the standardization of
the interface is literally all that exists. So, no SIEVE does not fill
the need raised, but agreement from major vendors to adopt SIEVE or
something like it would. The conclusion could be used to argue in
favour of adopting SIEVE.

As for getting the buy in of major vendors, look at the Web Services
stack. Most of the major vendors have adopted systems I have designed
or played a major role in designing in the past 36 months.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 26 Apr 2003 06:03:55 -0700

The paper clearly states that the study does not attempt to 
be authoritative and the main conclusion is that someone should
do a proper study.

In fact I suspect that the more interesting questions would be
about the way that the spam changes over time, the number of 
distinct items of spam etc.

		Phill

> -----Original Message-----
> From: Jim Youll [mailto:[email-masked]]
> Sent: Saturday, April 26, 2003 8:40 AM
> To: Hallam-Baker, Phillip; Vernon Schryver; [email-masked]
> Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator
> 
> 
> At 20:15 -0700 4/25/03, Hallam-Baker, Phillip wrote:
> >Like 89 is not a big number, but it is a lot bigger than 0.
> 
> But it really depends on the quality of the sample... Intuitively it 
> "feels" like you'd need more than that to really represent the 
> situation, but looking at the sample by itself, there's no way to 
> know.
> 
> Perhaps this is one of those situations where it may be necessary to 
> take a very large sample that helps to determine how big a sample 
> size is really needed, and to judge the quality of those already 
> in-hand.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 27 Apr 2003 06:26:04 -0700

Chris,

	Yes, I know that. The details of the server-server protocol 
are not relevant to the point I make in the paper. Usenet is flood
fill at the server-server level, every node is accepting everything
so which side initiates the polling sequence is irrelevant.

	At the abstract level however mail is inherently a push 
application, the side that initiates the conversation pushes the
message to the end user. Except in very rare circumstances the
protocol is inherently promiscuous, accepting solicitations from
any party.

	Mailing lists however are not inherently a push model, in 
fact they are inherently a pull model, the subscriber does just
that, she subscribes. The communication is instigated by the 
recipient, not the sender.

	The point made in the paper is that you can bypass the
problem of false positives wrt mailing lists by using a protocol
that supports the implicit authentication provided by the
polling being initiated by the subscriber. The chief candidate 
for this would be RSS, although the NNTP client protocol could
be used as an alternative.

	The idea would be to have a 'click here to subscribe' 
button in a browser which when clicked would automatically 
add the channel to the list of subscriptions the user has.

	Sure you could try to promote use of POP or IMAP for the 
same purpose, I don't think that would get very far, the clients
are simply too far from the application.

		Phill

> From: Chris Lewis [mailto:[email-masked]]
> Sent: Sunday, April 27, 2003 2:36 AM
> Cc: [email-masked]
> Subject: Re: [Asrg] A New Plan for No Spam / Velocity Indicator
> 
> 
> Hallam-Baker, Phillip wrote:
> 
> >>  - 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.
> 
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Apr 2003 09:49:17 -0700

> As stated previously I'm willing to leave those aspects to market
> forces.  I'm also willing to sign on to a best-practices publication
> which recommends that the end user be informed, in some detail of what
> is being done in his name for upstream filtering, as well as 
> the option
> to opt-out of such filtering.  However, I suspect that such items are
> uncontroversial.

I think the hard problem that has not been addressed is how to provide
a degree of hard evidence that shows that a party is either in compliance
with a policy or not.

The biggest complaints from the bulk mailers is that whatever they do 
someone can effectively perform a DoS on them with hearsay accusations.
Of couse that is not to say that the accusations are true in all cases,
but in some cases they are simply untrue. There is a huge problem with
asymetric standards of proof.

Another problem is that a lot of folk have folk like Symantec blacklisted 
for sending spam - when their 'associates' are actually selling ripped off
software.

If we can get accountability it is much easier to ger responsibility.
If someone sends an authenticated message that breaks corporate ethics
they can be fired. If the message is repudiable, or more likely the
opt-in element was repudiable then nothing happens, nor should it since
malicious accusations are not uncommon.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Apr 2003 12:04:35 -0700

> Ditto for transits across .forwards, aliases, mailing lists 
> and courtesy
> copies.  There are ways around this, for instance by encoding consent
> tokens into Message-IDs and then looking for them in In-Reply-To and
> References: headers, but this of course breaks for those MUAs 
> that don't
> generate In-Reply-To: or References: headers...

It is the lack of references and reply to headers that is the
problem. message ids are created at the server if the client did
not generate one.

Even outlook can probably be made to generate the right stuff.
The problem with outlook are mostly caused by the old X.400 core
getting in the way of the SMTP support. 

> > 2) Because of forged sender addresses, bounces for spam are 
> often not
> > deliverable, so the spam ends up as double bounces in the 
> postmaster's
> > mailbox.

Or in the case of a hijacked address they end up hitting an 
innocent party.

		Phill