Subject: RE: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 20 Apr 2003 11:40:11 -0700

> >   The main disadvantage is that I'm not going to talk to 
> someone using
> >a C/R system, because it means increasing *my* workload, to lower
> >*their* spam problem.  This is fundamentally evil, in my opinion.
> 
> So don't talk to them. The point is that C/R stops people who 
> dont want to 
> talk to the reciever. You don't care, therfore C/R works. If 
> you had any 
> sort of desire to speak to the person, you would answer the 
> challenge and be 
> done with it.

No, C/R fails when measured by the only reasonable yardstick, 
are wanted messages lost?

There are plenty of cases where I have less interest in sending
a message than the recipient has of receipt. For example when
I was sending courtesy copies of posts to "Prof" Bernstein it
was because I was attacking a position he was making and he had
the right of notice.

I would not advise consultants to use this type of technique.
I don't think that many of my clients would have responded to
the challenge in the days I did that sort of thing. Most RFPs
are sent in bulk to thirty odd people at a time. If someone
has a challenge response system the obvious conclusion is they
are too busy to take on further work, and why in any case should
the secretary care?

		Phill

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 20 Apr 2003 19:08:18 -0700

> > Need more proof?
> > 	IPSEC - Has failed in its design niche, currently losing
> > 		ground to SSL based VPNs which work better through
> > 		NAT
> > 	DNSSEC - Still a theory
> > 	IPv6 - Still a theory
> 
> Hmm. I use IPSec-based VPN every day, and it works fine via my cheap 
> NAT box without my having to do any reconfiguration at all. 
> I've never 
> seen an SSL-based VPN system.

Neither did I until I went to RSA last week and saw them on ten 
different stands with analysts from Gartner et. al. predicting they 
will soon dominate.

Incidentally the reason your IPSEC VPN works through NAT is because
your NAT box is doing special handling for the IPSEC protocol. I had
to replace my NAT box to get the IPSEC VPN to work, the handling code
required is pretty ugly. This could all be avoided, however at the
time the voice of the IAB was 'IPSEC is unfriendly to NAT, some do not
consider this to be an undesirable state of affairs' - sniggers from
the IPSEC working group listening.

> I've also not seen any use of PKI, bar certificates on web sites for 
> SSL.

Perhaps you havent used a DOCSIS II cable modem, or a WAP phone or
a recent Intel chipset... Hint, PKI is rather better if you do not
see it.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 20 Apr 2003 19:22:35 -0700

Vernon is completely right here.

The one modification I would make is to say that there are a few occasions
in which you can get the effect of having single-ended adoption even with a
double ended scheme.

One way this can be done is by piggybacking code for the double ended scheme
in the single ended scheme. For example using content filters that use
authentication as one input to the filtering decision process.

Another case where this can be done is if there are a few well travelled
sites such that if they adopt a double ended scheme unilateraly, even with
no immediate advantage it means that those connecting to them do see an
advantage from adoption at their end.

		Phill

> -----Original Message-----
> From: Vernon Schryver [mailto:[email-masked]]
> Sent: Sunday, April 20, 2003 9:49 PM
> To: [email-masked]
> Subject: Re: [Asrg] Spam Control Complexity -- scaling, adoption,
> diversit y and scenarios
> 
> 
> > From: Dave Crocker <[email-masked]>
> 
> > ...
> > HBP> Content filtering requires only single ended adoption.
> >
> > And it is not subject to network standardization.  ...
> 
> I suspect that is more true than false, but more than half of the spam
> control systems now in at least real trial use (stopping millions of
> spam/day) involve aspects that could be subject to network 
> standardization.
> All of the following filter at only one end, but push lots of bits
> through the Internet in support of that filtering:
>   - Postini
>   - Brightmail
>   - MAPS's RBL using BGP feed
>   - DNS blacklists including MAPS's RBL+, SBL, and SPEWS
>   - Razor/Pyzor
>   - DCC
> (in no particular order.  no endorsements implied.  omissions 
> unintentional)
> 
> SpamAssassin can also be viewed as moving data around the net 
> in support
> of its content filtering in the form of updates to the 
> default scoring.
> 
> Of all of those, only SpamAssassin sounds like a good candidate for
> network standardization, but I think it is a candidate.  The others
> have protocols that would be hard to displace.
> 
> The only spam solutions that I can think of that might be called
> "double ended" are
>    - authentication
>    - sender-pays (money, CPU cycles, or anything else)
>    - challenge/response
> 
> 
> Vernon Schryver    [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 21 Apr 2003 08:57:01 -0700

> This is an IRTF group.  It is presumably, therefore, intended to focus
> on activities that are likely to be reasonable candidates for format
> and/or protocol standardization.

Not at all. The objective of this research group is to stop spam.

There is no commitment whatsoever to mechanism. If we discover that
the best way to fight spam is to burn incense in front of a small
pyramid shaped altar we publish that in the appropriate forums and
close up shop.

A null result is a perfectly valid conclusion from a research 
group, in this case a null result might be that the problem is 
best solved by means entirely outside the ambit of the IETF.

I suspect however that even if it is found that filtering is
the one and only solution that there will be optimizations on
filtering that can be deployed that make filtering work better.
In particular some form of intrinsic mechanism that allows the
email client better control over filter parameters is needed.
Inband signaling by mail is tedious.

There are also many improvements to SMTP and other protocols that
can improve the situation. In many cases these improvements have
already been specified and what is required is deployment.

Clearly there is a general expectation that protocol changes are
likely to be proposed. Otherwise there would be no point at all
in putting up with the overhead that the IETF creates. The main 
reason for choosing this forum over another such as OASIS is that 
the IETF has in the past had influence over the development of 
SMTP, POP etc. If everyone thought the answer lay in better APIs
for mail the IETF is the last place I would go - and come to that
there is no way the IESG would let a project like that start
(remember GSSAPI?)

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Apr 2003 14:51:26 -0700

> You keep raising the IETF reference. I keep pointing out how
> inappropriate and unproductive your raising it is. And then you claim
> that *I* am hiding behind it???

Unlike you I can differentiate members of the class from the class 
itself. As in "Some Republican Presidents are corrupt - example 
Richard Nixon, cannot be extended to 'All Republican Presidents
are corrupt - counterexample Lincoln'.

> Oh, by the way. Perhaps you have missed the organizational affiliation
> of the IRTF? If you detest this particular community so much that you
> must constantly remind us of your displeasure, how can you be
> productive?

Yeah, yeah, we noticed as you might have seen if you read posts
rather than just responded to them.

Again, tourists have always been a liability in the IETF, and 
tourists with the idea they are the expert being the biggest
liability of all. So far you have done nothing but preach and pick
fights with anyone who challenges your holly writ.

> 1. In response to my citing the classic core/edge distinction, along
> with some example of its implication, you posted:
> 
> HBP> It is empirically easier to deploy changes at servers 
> than in mail clients.

And I stand by that observation, having spent much of the past
few years being involved in the area and having knowledge of
what is happening in the industry.

It is a fact that a new client deployment will take three years
minimum. I have spent a great deal of time on that issue trying
to deploy PKI for the US federal government. Those are the client
product cycles these days. If you want to dispute that, feel free.

On the other hand as I stated previously I have had meetings 
with the main ISPs, in particular the JamSpam consortium. They 
are very interested in deploying server based measures. The 
timescale there being six to twelve months.

I cannot go into greater detail on the matter for reasons that
should be obvious. An empirical fact need not rest on public
data, I have given you the information that is public.

I have seen no evidence presented by yourself for the classical 
argument. I know that argument, I know many of the people who 
originated it and the context in which it was proposed. It is
not very applicable to SMTP because SMTP is simply not an end 
to end protocol as the IETF has chosen to deploy it. There are
a lot of intermediaries in the transactions.

The problem would be very much easier if we did have a purer
realization of the classical model. But that classical model
arose in part from observation of the complexity introduced by
this sort of stuff.
> So please provide some guidance about the proper way to ask you for
> substantiation to claims you make. 

Again, the antiquarian basis you claim for the assertion you make
does not make proof any less necessary. You are the one who made
a blanket assertion and refuse to answer counter-examples.

Having had a classical education I seem to remember a lot of 
practices of that time that I would not recommend to the group.
I cannot see how examination of sheep entrails is going to
be relevant to spam, pig maybe, sheep no.

		Phill

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 22 Apr 2003 18:59:41 -0400

The key element it seems is that certain specific technologies benefit from 
different deployment techniques.  It is true that so-called "IETF dogma" has 
been to attempt deployment at the edges primarily, but I think that is a result 
of the interoperability requirements for proposed technologies and not whether 
edge v. core deployment is 'better'.  In fact I don't think either is per se 
better.  It all depends on the effectiveness of the approach.

-e

On Sunday, April 20, 2003 2:15 PM, Hallam-Baker, Phillip 
[SMTP:[email-masked]] wrote:
> > No doubt you have empirical data to substantiate your empirical
> > assertion.
>
> Fifteen years of trying to deploy PKI through the edge model.
>
> My experience is that deployment of new client features takes
> five years or more - even in communities with a need for the
> features.
>
> > So, please cite some major enhancement to an Internet-scale,
> > Internet-diversity, existing service, that could have been done either
> > in an edge fashion or a core fashion, that went quickly (or at all)
> > through core deployment, rather than edge.
>
> I am not aware of any Internet service the IETF has succeffully
> deployed while I have been involved with it. Not one thing.
>
> The Web was successful before the IETF was involved and largely
> in spite of IETF dogma.
>
> Need more proof?
> The IETF has failed to deploy any of the three major must do
> projects from ten years ago. I conclude that it is time to ditch
> the dogma.
>
> > My own counter-example will be multi-media mail, which failed
> > to deploy
> > through a core approach in spite of 2 or three eager efforts over a 10
> > year period, while MIME became useful within the first year of its
> > release.
>
> Well duh! Multimedia mail does kinda require a multi-media client.
>
> It also requires terminals capable of multimedia display. It is no
> accident the Web appeared when it did. Back in 1990 it was still
> common to have a VT125 as your means of internet access. Graphical
> terminals were rare and expensive.
>
>
> > "doubled ended" sounds like a dandy term.  what does it mean?
>
> Must be deployed by both the sending and receving party before
> there is any benefit.
>
> > if it means "at both ends" then i would be quite interested
> > to hear how
> > any enhancement that involves interoperability can be useful
> > if deployed
> > to only one component.
>
> Content filtering requires only single ended adoption.
>
> Some of the authentication mechanisms discussed authenticate
> replies using single ended techniques.
>
> In a strange way, so do the Web, the key being you don't care
> are much about the particular people you are communicating with.
>
> 		Phill

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 22 Apr 2003 21:31:12 -0400

I would like a copy of your draft.  Thanks.

-e

On Tuesday, April 22, 2003 3:22 PM, Hallam-Baker, Phillip 
[SMTP:[email-masked]] wrote:
8<...>8
>
> > Presumably you are offering to produce the draft of that "FAQ"? It
> > sounds like it might be useful.
>
> Actually as several who have been in this group some time know
> I have already circulated one draft of such a scoping paper. I
> am currently getting approval for the second.
>
>
> 		Phill

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 22 Apr 2003 19:43:38 -0400

On Sunday, April 20, 2003 9:49 PM, Vernon Schryver 
[SMTP:[email-masked]] wrote:
> spam/day) involve aspects that could be subject to network standardization.
> (in no particular order.  no endorsements implied.  omissions unintentional)

At least some aspect of their successful operation imputes some use of 
standardized networking, however IMHO they only require end-to-end standardi  
zation of application semantics, etc. for functionality.  Albeit, there too one 
may conclude that is some type of network standardization (I agree with your 
first statement, more true than false - I would say much more true.).

> SpamAssassin can also be viewed as moving data around the net in support
> of its content filtering in the form of updates to the default scoring.
>

I think C/R is sub-ordinate to sender-pays in your example list as the sender 
must 'pay' with time to respond to the challenge, do you mean whitelisting?

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 22 Apr 2003 21:25:41 -0400

I agree that would be useful.

-e

On Tuesday, April 22, 2003 2:56 PM, Dave Crocker [SMTP:[email-masked]] wrote:
8<...>8
> 
> HBP> What is needed at this stage is a FAQ which states the problems
> ...
> HBP> I would like to propose that each proposal for a spam solution
> HBP> that already appears on the list be required to start what 
> HBP> solutions it proposes to the problems identified in the FAQ.
> 
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>