Subject: [Asrg] Requirements for anti-spam systems-Draft 1

From: Paul Judge <[email-masked]>
Date: Wed, 19 Mar 2003 14:13:15 -0500

This is a draft of high-level requirements for anti-spam systems. This list
was started by Keith Moore. This draft incorporates feedback from
Balachander Krishnamurthy, Gary Feldman, Troy Rollo, Damon Sauer, Paul
Judge, and Hadmut Danisch.

1.	must minimize unwanted messages to some acceptable level
2.	must not affect delivery(latency, integrity, cost, reliability) of
wanted messages to a point that would effect the normal use of email
3.	must be easy to use 
4.	must be easy to deploy, incrementally
	a.	must provide incentives to deploy for those doing the
deployment
5.	must not depend on universal deployment to be effective
6.	must not reduce privacy
7.	must have minimal administration and implementation overhead
8.	must have minimal computational and bandwidth overhead
9.    must consider the threat and be robust in the face of such threats
	-(potential new work item: a spam threat model)
	some properties of the threat:
		- adversary knows details of anti-spam systems
		- adversary is intelligent and well-funded
10. should consider how legal issues affect, support, or constrain the
technical solution
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 19 Mar 2003 09:34:20 -0500

Paul Judge <[email-masked]> wrote:
> This is a draft of high-level requirements for anti-spam systems.
...

  I would add:

7a  Must allow individual administrators to control the anti-spam
    system in their network.

  While this may sound trivially obvious, many people I've talked to
believe that all solutions should be based solely on the recipients
consent.  By this, they appear to be saying:

 1) everyone else in the network should implement the consent of the
    recipient.

 2) the administrator of the network used by the originator of the
    email cannot implement consent OTHER than that of the recipient.

  Issue #1 doesn't scale to a network with millions of recipients and
millions of sendewrs.

  Issue #2 means that the administrator of a sending network cannot
decide (say) to filter outgoing port 25 for dial-up users.

  While I agree that such filtering is non-optimal, it *is* a valid
configuration of the administrators network, and should not be
prevented.

  Alan DeKok.

---

From: Frank de Lange <[email-masked]>
Date: Wed, 19 Mar 2003 20:54:52 +0100

>10. should consider how legal issues affect, support, or constrain the
(sent previously as reply to Hadmut's mail. most points in that reply 
are mostly covered but...)

11.   must not violate RFC2026 (no proprietary solutions, no IP 
restrictions)

Partly covered by point 10, but important so...

Frank

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Mar 2003 14:59:51 -0500

> decide (say) to filter outgoing port 25 for dial-up users.

Issue #2 also means that the administrator of a receiving network cannot 
enforce policy.  Think corporations and employment agreements.

Also, in general, consider distributed spam filtering techniques, like 
DCC et. al.  Centralized/administrator update/control are critical to 
their operation.  Sure, in some circumstances, a user should be able to 
turn them off or whitelist, but...

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 19 Mar 2003 09:57:26 -0500

> enforce policy.  Think corporations and employment agreements.

  I would then say to NOT add my comment as 7a), but instead a new
entry:

n+1) Every network element must be permitted to administer their own
     anti-spam policy, irrespective of anyone elses policy or consent.

  Some people will object strenuously to this statement, for various
reasons.  But the reality is that this is already happening today.
It's called dropping packets when the link gets full.

  The network is not reliable.  The network does NOT enforce your
wishes to communicate with others.  It's best-effort, and your data
may not make it through.  We already accept this behaviour, and I
believe that we should make such acceptance explicit for anti-spam
solutions.

  Alan DeKok.

---

From: [email-masked]
Date: Wed, 19 Mar 2003 15:06:48 -0500

> decide (say) to filter outgoing port 25 for dial-up users.

This can also be important in corporate environments, although there
it's usually an easier job to deploy port filters (and since the users
are employees, it's easier to smack them upside the head - you usually
can't do that to an idiot customer.. ;)

---

From: Frank de Lange <[email-masked]>
Date: Wed, 19 Mar 2003 21:26:42 +0100

>believe that we should make such acceptance explicit for anti-spam
Is it really necessary to add this? IETF does not dictate how people 
control their resources after all. There are already all kinds of 
restrictions on who can access what in what manner and from where. I 
believe this will sort itself out, if some ISP (or mail service 
provider, or ...) were to impose too onerous terms and conditions users 
would just move to another ISP.

//Frank

---

From: <[email-masked]>
Date: Wed, 19 Mar 2003 15:53:21 -0500

I'm a little confused so I'll ask whether you agree with the following.

Best effort include attempting to deliver but failing due to congestion.

Worst efforts include deciding a given message must not be delivered and
thwarting your wishes to communicating.

Note that the current open loop email doesn't really scale in the case
of congestion. The problem is in using NAK not ACK but ACK has privacy
implications which makes the problem complicated>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
DeKok
Sent: Wednesday, March 19, 2003 09:57
To: [email-masked]
Subject: Re: [Asrg] Requirements for anti-spam systems-Draft 1 

  Alan DeKok.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 19 Mar 2003 15:53:42 -0500

>8.	must have minimal computational and bandwidth overhead

directly or indirectly.

In other words, a system of throw-away addresses may meet a user's 
needs, but aggravate the ISP bounce problem.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 19 Mar 2003 16:21:11 -0500

> would just move to another ISP.

And the *other* broadband provider in your area is?

This is a serious question - if there's only one provider in your area who
provides service better than dialup-56K, and they insist on shanghai'ing port
25 and filtering the bejeebers out of it, what do you do?

---

From: Frank de Lange <[email-masked]>
Date: Wed, 19 Mar 2003 22:32:42 +0100

>25 and filtering the bejeebers out of it, what do you do?
Actually, there is NO broadband provider in my area... That's one of the 
reasons for building a free wireless network...

It is also one of the reasons do decouple my mail from the ISP I use. 
I've moved ISP's several times because of the reason stated above (as 
well as for others), and have received mail in one of several ways. Not 
ideal, but the only way to keep control. And that is quite important to 
me, *I* want to be in control of my mail. Not my ISP, not the operator 
of some blacklist (one of my reasons for not using those), not the 
government. Not even the IETF :-)

Frank

---

From: <[email-masked]>
Date: Wed, 19 Mar 2003 16:50:08 -0500

NAKs are a classic way of amplifying bounce problems. I've stopped
sending bounce messages from my mail system for that reason. As I've
mentioned there should be an ACK but there isn't.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kee
Hinckley
Sent: Wednesday, March 19, 2003 15:54
To: Paul Judge
Cc: 'Asrg ([email-masked])'
Subject: Re: [Asrg] Requirements for anti-spam systems-Draft 1

directly or indirectly.

I'm not sure which upsets me more: that people are so unwilling to
accept
responsibility for their own actions, or that they are so eager to
regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Justin Mason)
Date: Wed, 19 Mar 2003 15:48:32 -0800

> wanted messages to a point that would effect the normal use of email

I would suggest that a broken-out list of what "normal" uses of email are,
would be helpful here.

For example, difficult cases include

  a. a small-scale, non-commercial mailing list, operating with confirmed
     opt-in subscriptions.  (not too hard, but pay-to-send solutions
     could be problematic in such a use-case)

  b. a user BCC'ing someone they've never met before (can look a lot like
     spam to a naive content-based spam filter)

  c. a user sending a mail via one ISP's SMTP server, with the rfc-822
     "From" address set to another account on another ISP (quite
     pathological, but it happens)

A few of the solutions already proposed may cause trouble for, or have
difficulty with, some of the potential use cases, so it'd be worthwhile
having a reference list of what the ASRG considers "normal".

For example, personally I would be happy with a solution that deals with
spam but breaks the c. case, since IMO it's a hack, and the old adage
about omelettes and eggs springs to mind. ;)

--j.

---

From: David Finnie <[email-masked]>
Date: Thu, 20 Mar 2003 11:20:22 +1100

Paul,

I'm very new to the list and have been astounded (a little daunted) by
the volume of traffic.

Thank you for re-publishing this requirements list. I think it's
imperative that we all focus on nailing that down as a means of
formalising a positive step towards a solution (or group of
solutions).

While the mail archive is a useful tool, it is also BIG. Using it to
determine exactly what the currently-agreed-upon requirements list is
is a difficult task.

Can I suggest that we take formalisation a step further by having, on
a web site (http://www.irtf.org/charters/asrg.html for instance) a
definitive list of requirements currently agreed upon. We can then
debate modifications to the list, and when agreed upon, update the
list.

The same approach could be used for possible solutions. With a name of
the solution, short description, status (e.g. In Debate, Rejected,
Accepted), and a list of pros and cons.

I think that to do this we would need some formalised approach to how
we agree on things. We obviously have a bunch of enthusiastic &
intelligent contributors to this list. I'd hate for any energy (or
reading time) being wasted on repeating and rehashing old subjects,
and for talking about off-topic items.

Would people find this approach useful ? Comments, suggestions welcome.

David Finnie

> From: Paul Judge <[email-masked]>
> Content-Type: text/plain
> Sender: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> Precedence: bulk
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
> 	<mailto:[email-masked]?subject=subscribe>
> List-Archive: <https://www1.ietf.org/pipermail/asrg/>
> Date: Wed, 19 Mar 2003 14:13:15 -0500
> 
>

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 20 Mar 2003 00:31:12 +0000

> consent.  
I hope there aren't many people saying stuff as silly as that.

> By this, they appear to be saying:
> 

Really? "should" perhaps, more likely "may", but "must" is out 

>     email cannot implement consent OTHER than that of the recipient.

The way recipient "consent" might interact with organisational /
operational policy hasn't been formally discussed in this group (?). It
should be.

> 
>   Issue #1 doesn't scale to a network with millions of 

indeed. I can't see how it could be *required*.
 
> decide (say) to filter outgoing port 25 for dial-up users.

indeed.

So recipient consent isn't the only consideration.
Who said it was? let's fight them :-)

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 19 Mar 2003 14:43:34 -0500

Frank de Lange <[email-masked]> wrote:
> Is it really necessary to add this?

  I believe so.  A significant number of people I talk to about my
domain come up with such extreme positions, like they're some kind of
religious mantra.

> IETF does not dictate how people control their resources after
> all. There are already all kinds of restrictions on who can access
> what in what manner and from where. I believe this will sort itself
> out, if some ISP (or mail service provider, or ...) were to impose
> too onerous terms and conditions users would just move to another
> ISP.

  While I agree with what you're saying, I also believe that some kind
of push-back on extreme views is necessary.

  Alan DeKok.

---

From: Frank de Lange <[email-masked]>
Date: Thu, 20 Mar 2003 02:19:21 +0100

>of push-back on extreme views is necessary.

Then I think a 'best practice' document on how to manage mail service is
the place to put these recommendations. This is user and systems policy,
not part of mail protocol. Having a cbt on mail service referring to
spam reduction methods would be a good thing in any case...

Frank

---

From: [email-masked]
Date: Thu, 20 Mar 2003 02:45:13 -0500

> about omelettes and eggs springs to mind. ;)

I wouldn't go quite *that* far, personally.  Yes, it's a hack.  But it's a
widely deployed hack.  Solutions that break widely deployed things are a
Bad Idea.

We need to examine things, and ask (a) who will be screwed over by the
proposal and (b) what can be done to alleviate the problem?

(In this case, it's (a) "road warriors" and (b) Port 587).

Fortunately, there's already a solution in hand, we just need to deploy it.
Unfortunately, there *will* be corner cases where we will have to make life
difficult for somebody, and hard choices will have to be made...

---

From: Scott A Crosby <[email-masked]>
Date: 22 Mar 2003 11:55:47 -0600

> Judge, and Hadmut Danisch.

This had better be a wish list; if a solution must satisfy all of
these requirements, I'm packing up and going home.

How abouot elaborating these to give actual ranges for the
requirements. What is 'minimal overhead'? Is it 10 RSA key
computations, or .1 RSA key computations? What objectives are more
important than other objectives. Stopping unwanted email, or burning
more CPU?

Scott

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 22 Mar 2003 13:22:31 -0500

>these requirements, I'm packing up and going home.

That's standard practice for a requirements list.  First you wish 
everything you could possibly want.  Then you start to compromise. 
Ditto on architectures.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Steve Schear <[email-masked]>
Date: Sat, 22 Mar 2003 17:50:57 -0800

At 01:22 PM 3/22/2003 -0500, you wrote:
>everything you could possibly want.  Then you start to compromise. Ditto 
>on architectures.

I find that from a practical stand point this may be backwards.  First, you 
set down in writing and get written buy-in from the parties in authority 
(assuming there are any) what the proposed system/product will NOT DO and 
once set you don't allow this to change for at least the first release 
(assuming there are several release possible or planned).  Doing otherwise 
invites constant feature/mission creep.  After many years of successful and 
unsuccessful project developments I've learned to walk away if I can't get 
this first item resolved.

steve

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 23 Mar 2003 11:38:49 +0000

> (assuming there are any) what the proposed system/product will NOT DO and

Doesn't that make for a rather long list?
1. Doesn't fly to moon.
2. Won't make toast
3. Probibited from kicking cat

etc....

---

From: Steve Schear <[email-masked]>
Date: Sun, 23 Mar 2003 09:34:45 -0800

>3. Probibited from kicking cat

Hehe, yes it could.  Still, its amazing what quick progress can be made 
when prohibitions within the "universe" of reasonable system/product 
features are clearly delineated early.

steve