Subject: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt

From: "Danny Angus" <[email-masked]>
Date: Thu, 18 Jan 2007 11:44:45 +0000

At:
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt

You will find a document which outlines an idea I've had for a while.
Please give me your comments on this list.

The thrust of the document is that while we don't know what the silver
bullet solution for spam is we do know some of the characteristics
which we expect it to exhibit.

We also know that very many ideas are presented on this list which
fail to meet one or more of those criteria, this draft is intended to
provide a reference which outlines those criteria, and could be used
as a partial statement of requirements for a technique to solve the
problem of spam.

Obviously this is just my own 2c at the moment, so let me know what
your opinions are and I'll modify, abandon or replace this as
necessary.

FYI the abstract reads:

"The Internet Research Task Force Anti-Spam Research Group (ASRG) is
   frequently presented with proposals for techniques for managing spam
   from authors who wish to elicit an expert critique of their
   proposals.  In many cases proposals fall foul of issues and risks
   which are well known and understood by members of the ASRG.  This
   Internet Draft is intended to enumerate and explain a number of the
   more important of the criteria which tend to be applied.  This
   document will then serve as a normative checklist for anyone wishing
   to present a technique to the ASRG."

d.

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

---

From: "Danny Angus" <[email-masked]>
Date: Thu, 18 Jan 2007 13:31:56 +0000

I've put an html version at

http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html

---

From: John Levine <[email-masked]>
Date: 18 Jan 2007 16:10:35 -0000

Thank you for moving ahead with this.

I've been sitting on it way too long supposed to make comments.  I
agree that taxonomies to help categorize anti-spam techniques and
their success or lack thereof are a good direction for us.

---

From: "Walter Dnes" <[email-masked]>
Date: Thu, 18 Jan 2007 20:47:02 -0500

On Thu, Jan 18, 2007 at 11:44:45AM +0000, Danny Angus wrote
> At: http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt

  Item number 0) Avoid using "the S word"
1,$s/spam/unwanted email/

  Rationale: If you set up a technical definition of spam, some lawyer
or wannabee-lawyer *WILL* find a loophole in it.  And there are some
legal jurisdictions that have defined spam, and allowed explicit
exemptions.  The result will be a constant battle of technicalities.
And calling someone's email "spam" can result in lawsuits by "legitimate
bidnizzmen".  Simply saying that you don't want certain email, without
calling its senders "spammers", is less of a legal risk.  In other
words, "because I said so" should be sufficient reason for a person to
reject email for their inbox.  My inbox, my rules.

  Item number 1) Assume that senders of unwanted email may be hostile,
unethical, sleazy lawbreakers who will resort to all means at their
disposal to get their unwanted email delivered to their target.  If your
proposed solution will not work in such an environment, forget about it.

-- 
Walter Dnes <[email-masked]> In linux /sbin/init is Job #1

---

From: "David Nicol" <[email-masked]>
Date: Fri, 19 Jan 2007 00:07:27 -0600

On 1/18/07, Walter Dnes <[email-masked]> wrote:
> My inbox, my rules.

also known as "per-recipient configuration"

---

From: "Danny Angus" <[email-masked]>
Date: Fri, 19 Jan 2007 09:47:27 +0000

David,

On 1/18/07, David Nicol <[email-masked]> wrote:
> okay you got it.

Its appreciated

> Before looking at it:
> One hopes that the criteria therein will be a superset of the issues
> enumerated on the "how to tell if you are an anti-spam kook" page
> http://www.rhyolite.com/anti-spam/you-might-be.html
>
> After looking at it:
> right off (1.1.1), we're at
> http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-4

That's a fair point. I don't think the difference is hugely
significant. But I'm not convinced that "bulk" is really a necessary
constraint. OTOH I know we've had this discussion before and I have
*no* intention of starting it again, god forbid, so I'm prepared to
remove "spam" as the headline and replace it with Unwanted Mail
throughout the document, of which "unsolicited bulk mail" is certainly
part. This also addresses Walter's point about the S word being
pejorative but "i said so" being the recipients right.

Why Unwanted Mail? Because I think that the value of any solution is
in the removal
of mail which which we know will be unwanted *before* it reaches its
destination, the sooner the better to the point where preventing it
from being sent at all is the ultimate. The trick (or implementation
detail, left as an exercise for the reader...) is to identify it as
unwanted before it gets there. Whether or not it is solicited, bulk or
one off, doesn't really change the economics in which resources can
surely be put to better use than than the transportation or processing
of mail which isn't going to be read.
WDYT?

>
> (2.3.7) on multi-hop transport
> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor31
> seems most debatable; specifically, a model of origniating administrative
> domain, all-to-all, receiving administrative domain seems more realistic

Whilst I think you're right I shied away from designing any kind of
solution, or from making any random assumption about what anyone might
want to actually do (If only I could work out how to get someone to
pay me to do that!)  in the interests of impartiality.
I also wanted to weed out proposals that don't permit even local hops.

> (2.3.5) avoid centralized solutions
> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor29
> this, also a SHOULD NOT, seems like it would be difficult.  Centralization
> of things like reputation server registration seems inescapable, just like
> central administration of top-level DNS.

I wanted to make this a MUST NOT, but I thought that I was probably
being too harsh. I think there are problems that can come with
centralised resources or central control and want to discourage people
from specifying them without clear justification. That and because it
will discourage people who think they can set themselves up as the
operator to gain influence or money.

>
> (2.3.3) Don't re-invent identity and trust models
> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor27
> this section could be made stronger by listing the invented ones
> that are not to be re-invented.  I am not aware of a working multi-faceted
> reputation server infrastructure, for instance, beyond the profusion of RBLs.

Yeah, reading that section through again now I'm sober ;-) it seems a
bit harsh, "don't re-invent" implies that you can invent something,
because you can't re-invent something which hasn't been invented at
all, but the text seems to claim that everything we'll ever need has
already been invented. It's not my place to say so. Perhaps listing
the inventions which needn't be re-invented would add clarity. It
might also reveal my ignorance, so feel free to list stuff.

> All in all, after reading the document, it seems to me a nice draft

Thank you.

>and
> would be coupled well with a BCP document enumerating existing
> solutions that answer various parts, or an index of BCPs, or even have
> links to the BCPs embedded in it.

I refined it by evaluating current practices & products, and past
proposals (good and bad) against the conditions and fiddled it to fit
my subjective opinion of them, and what I understood to be the
consensus of this list. So I think this would be a possibility, and
not too controversial either.  OTOH It would risk becoming out of date
very quickly if the people responsible for products which were listed
as wholly or partially non-compliant decided that compliance was
important for them, so someone would have to take ownership of either
maintaining a list or publishing a regular summary of current good
practice.

>
> Towards a centralized IP-based reputation service:
>
> If the end result becomes some kind of TOS enforcement standard; that would
> be cool;

Cool certainly but perhaps some way off yet.

d.

---

From: "Danny Angus" <[email-masked]>
Date: Sat, 20 Jan 2007 20:47:12 +0000

On 1/19/07, David Nicol <[email-masked]> wrote:

> So what's to motivate the operators then?  Operating a reputatble
> reputation server service will require ongoing effort.

Let me try to be clearer about this. I'm not stopping anyone from
charging to people for any of the services they might choose to offer
as part of the implementation of any technique. This para is about
discouraging people from making proposals which enshrine a *single*
*central* register, and that is because I think it would confer too
much power, and might be proposed simply as a licence for the proposer
to print money, never mind the practical constraints of setting it up
and operating it.

IMHO, and it *is* only my opinion, is that it should be possible and
would be desirable to establish a technique which allowed multiple
providers to co-exist, and those providers' services could either be
used singly or combined without a mandated central authority.

 I said "SHOULD NOT", not "MUST NOT" because I accept that there may
well be some proposed techniques which can make a valid and compelling
case for a central authority. I can't think of one though.

> Set up standards
> for interoperability of reputation services and commercial reputation
> services could appear, the reputation of the commercial services will
> get determined in all the usual reputation determination sources --
> free press, word of mouth, etc.

Fine yes, my thoughts exactly, yes. An open market place for services.
The document intends to discourage the mandating of a single operator,
and disallow the _mandating_ of commercial services. It doesn't
_demand_ the provision of free services or the existence of
competition. It does, however, attempt to permit them.
I'd like to see proposals permit competition, collaboration and the
co-existence of free and commercial services, this reflects the nature
of the modern internet and current practice in the domain of spam.

d.

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 22 Jan 2007 08:29:34 -0500 (EST)

> Please give me your comments on this list.

Comments:

1.1.1 I would resist making the definition of spam so receipient 
dependent. If every receipient gets to make his/her own definition, then 
it tends to prevent cooperative solutions from looking satisfactory, and 
the the purpose of the IETF is to facilitate cooperative solutions. For 
example, if spam has no objective definition, then each user must maintain 
their own DNSBL, or list of spamassassin regular expressions. I would have 
thought the purpose of this group was to suggest ways for MTA operators to 
cooperate to reduce spam - individual solutions don't require the IETF.

There are also the cases to consider of ISPs who ignore messages to abuse 
- does that make the messages spam?  I think we should stick with 
"unsolicited commercial email" as a workable spam definition.

2.2.1 Why the prohibition on the use of non-SMTP protocols? Many 
legitimate spam reduction techniques use DNS (DNSBLs, DKIM, SPF, etc). 
While all these techniques have disadvantages, the primary problems do not 
arise for the use of an alternate protocol for communication of anti-spam 
information. Or perhaps the section means only that the mail itself should 
not use another protocol. Then it should say so. I hear so many complaints 
about the overloading of DNS with other tasks, perhaps I am reading them 
into this section. Would adding another keyword to the SMTP protocol be 
allowed?

2.3.1 is worthy of being singled out, however, since so many propsoed 
solutions fail to allow strangers to communicate, and that is pretty much 
the chief objection to the majority of proposed techniques.

There is a surprising omissions - No mention of the superiority of 
rejection during the SMTP processing over discarding or delivering to a 
spam folder. Or did I miss it somewhere?

I worry that the point of the draft is to outlaw all spam reduction 
techniques other than individually created and controlled content 
analysis. At the very least users need to be able to cooperate or to 
purchase anti-spam services from unrelated organizations, and without 
common definitions and inexpensive communication of results, this will be 
made unnecessarily difficult.

Would the author list some common techniques are say if they meet these
standards, and if not, where they fail?

Daniel Feenberg

---

From: "David Nicol" <[email-masked]>
Date: Mon, 22 Jan 2007 11:02:22 -0600

> "unsolicited commercial email" as a workable spam definition.

the upside of using a very general definition is that it necessitates
a many-sizes-
to-fit-everyone system of solutions.

> I hear so many complaints
> about the overloading of DNS with other tasks

in my opinion, DNS is perfect when you want a distributable cached database
of information that does not change that often.  Name to number mappings
fit this, of course, but so do a lot of other kinds of information.  I have seen
suggestions dismissed as "requiring a trick DNS server" as if that requirement
is some kind of unvaultable bar, which it is not.  In the event that other
data sets get served over DNS infrastructure with some popularity, some system
administrators may need to revise their capacity planning documents for
faster upgrading of local dns caching hardware.  This is not a big deal either.
In terms of (1) efficient network use and (2) in-place infrastructure,
DNS is very good,
and I see no reason not to use it when appropriate.

> spam folder. Or did I miss it somewhere?

I think that kind of detail is deliberately left out of the document which
is designed to live at a high level immune from implementation details.

> made unnecessarily difficult.

I read the document as a call for better (distributed) interoperable reputation
services, possibly violating Zooko's triangle; ergo the document passes the
"everyone who looks at it sees something different" test for "work of art."

> Would the author list some common techniques are [and] say if they meet
> these standards, and if not, where they fail?
>
> Daniel Feenberg

My growing suspicion is that the end result of this committee is going to
be current practices enumeration and reccomendations, with a bottom line
of "it isn't broken."

David Nicol

---

From: [email-masked] (Justin Mason)
Date: Mon, 22 Jan 2007 18:51:26 +0000

>to-fit-everyone system of solutions.

For what it's worth, we in SpamAssassin use "unsolicited bulk email" as
our definition  -- religious spam, for example, is still spam in our book.

Defining spam as "email the user does not want" means that you cannot
safely filter spam, except with a user-trained classifier (Bayesian-style
probabilistic classification for example).  It's too
subjective, and would outlaw DNSBL usage, as far as I can tell...

>be current practices enumeration and reccomendations, with a bottom line

--j.

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Jan 2007 20:05:27 +0000

>subjective, and would outlaw DNSBL usage, as far as I can tell...

The unwanted email can be unwanted according to a site-wide policy, too,
a bit like the concept of the corporate legal person.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY: NORTHERLY 6 OR 7, BACKING WESTERLY LATER. ROUGH OR VERY ROUGH.
WINTRY SHOWERS. GOOD.

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 22 Jan 2007 17:41:00 -0500 (EST)

> to-fit-everyone system of solutions.

I had a further thought. Defining spam only as unwanted mail will be a 
problem for anti-spam activities operating spam traps. By definition the 
mail received in a spam trap is "wanted" - the purpose of the trap is to 
learn about the sources of unsolicited commercial email, and incoming mail 
helps it achieve that purpose. The fact that it is wanted by the trap 
doesn't make it not spam, spam is unsolicited, not necessarily unwanted.

But if the sender can claim that the mail in the trap doesn't meet agreed 
industry definitions of spam, then the sender can use the RFC to challange 
the use of those messages as evidence of spamming. Furthermore, since the 
spammer can hardly be expected to know the mental state of the receipient, 
it effectively relieves him of any responsibility for spamming at all.

While I realize that legal challanges to spamming have been isolated, that 
is no reason to put such an obstacle in their path. For this and other 
reasons, I think it very mischevious to change to a personalized 
definition of spam in a document proposed for offical status.

Dan Feenberg

...

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 22 Jan 2007 17:51:29 -0500 (EST)

> our definition  -- religious spam, for example, is still spam in our book.

I'll accept that as an improvement over "unsolicited commercial email".

Daniel Feenberg

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Jan 2007 22:59:29 +0000

Daniel Feenberg <[email-masked]> wrote:
>helps it achieve that purpose.

Actually, what you want is no email to hit the spam trap, because
that would indicate that the spammers have stopped. Also, spam is not
necessarily commercial so don't call it "UCE" unless the C stands for
"criminal".

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: NORTHWESTERLY 5 INCREASING 6 TO GALE 8. MODERATE OR ROUGH INCREASING
VERY ROUGH. SHOWERS. GOOD.

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 22 Jan 2007 18:23:56 -0500 (EST)

Daniel Feenberg <[email-masked]> wrote:

> I had a further thought. Defining spam only as unwanted mail will be
> a problem for anti-spam activities operating spam traps. By
> definition the mail received in a spam trap is "wanted" - the
> purpose of the trap is to learn about the sources of unsolicited
> commercial email, and incoming mail helps it achieve that purpose.

No, it isn't.  I don't want any mail to be sent to
<randomgarbage@mydomain>.  It gets sent there despite my wishes, so
I'm forced to take the effort to blackhole the senders.  I'd be
happier if no such mail were ever sent.

In any case, somebody else claiming that _I_ want something would be
invited to demonstrate to a court just how well his telepathy works.

But I agree with using "unsolicited" as the key characteristic.
Solicitation is based on externally-overservable actions.

Seth

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 22 Jan 2007 20:28:24 -0500

> is designed to live at a high level immune from implementation details.

Avoiding blowback is not a mere implementation detail.  Yes, it can be
inferred by the remarks about "not impacting others", but given the
problem that it does represent in practise suggests that something more
explicit needs to be said.  At least to the point of "don't bounce spam
and viruses".

---

From: "David Nicol" <[email-masked]>
Date: Mon, 22 Jan 2007 23:30:08 -0600

On 1/22/07, Chris Lewis <[email-masked]> wrote:
> "don't bounce spam and viruses".

okay; here's for the BCP compendium:  Rejecting is acceptable.  Filing
is acceptable.
Bouncing is unacceptable.  Right?

---

From: Bill Cole <[email-masked]>
Date: Tue, 23 Jan 2007 00:53:20 -0500

>Bouncing is unacceptable.  Right?

Not quite.

Bouncing because you've decided that mail fits a class where most 
mail has a bogus sender (i.e. spam and viruses) is unacceptable.

-- 
Bill Cole                                  
[email-masked]

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 23 Jan 2007 00:56:04 -0500

> Bouncing is unacceptable.  Right?

You're going to have to define what "filing" means, and perhaps realize
that whatever "filing" is isn't mutually exclusive with bounce or
reject.  I would suggest that silent blackholing (or even quarantining)
isn't acceptable, because there's no means of discovering false
positives (except out of band - eg: the phone).

I'd also suggest that letting the email through with a "spam tag", or
sticking in "junk folders", or the like is poor in general - because in
reality, the recipients don't look.

My personal opinion is that the "gold standard" is reject + quarantine +
per-recipient-configurable quarantine notification.  Because that's what
we do ;-)

For the purposes of the BCP, tho, that's way beyond the level of detail
I think you're intending - it's changed it into a different question
with a far broader scope.

First and foremost, this simple message is the one you need to impart:

"thou MUST NOT bounce".

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 23 Jan 2007 01:02:17 -0500

> First and foremost, this simple message is the one you need to impart:

When considering Bill's variation (which I actually prefer, but...), one
must realize that you may be wanting to do bounces for things that
aren't considered "spam or viruses".

Eg: this is technically equivalent to, say, an autoresponder.

It would be a mistake, for example, to exclude filtering on an
autoresponder address.  Indeed, the filtering should be a lot more
aggressive and/or use other techniques to avoid responding to things
that don't "look right".

---

From: "Danny Angus" <[email-masked]>
Date: Tue, 23 Jan 2007 10:27:10 +0000

On 1/22/07, David Nicol <[email-masked]> wrote:
> possibly violating Zooko's triangle

How so?

> be current practices enumeration and reccomendations, with a bottom line

That's pretty close, but I think it undervalues the excercise.
What I hoped to achieve by outlining characteristics which the
techniques that have survived share (not all techniques display all
characteristics), and by identifying which characteristics the ones
which have died out violate was to catalogue a set of requirements
which we believe represent the requirements for a complete solution to
the problem.
Involved in this analysis is an analysis of the entities, which has
highlighted one big problem, which is that the ASRG *still* can't
agree a definition for spam, and an alignment of those definitions
against definitions in the corpus of RFC's which we call "email".

In spite of the fact that we may review current practice and arrive at
"it isn't broken." I believe we may also arrive at these conclusions:-
"it isn't complete", "it is understood", "some aspects are well
advanced" and "The scope is clear". If we're lucky we might also get
"we know what the gaps are", and if we're smart "we know how to fill
them".

d.

---

From: "Danny Angus" <[email-masked]>
Date: Tue, 23 Jan 2007 10:27:45 +0000

Sorry, this one missed the list..

---------- Forwarded message ----------
From: Danny Angus <[email-masked]>
Date: Jan 22, 2007 2:47 PM
Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt
To: Daniel Feenberg <[email-masked]>

> cooperate to reduce spam - individual solutions don't require the IETF.

I understand what you're saying, but there are two things I considered
relevant, the first is that two individuals might have vastly
different opinions on the desirability of any piece of mail.
The second one is that if any individual can express their desire not
to receive an identifiable class of mail for *any* reason, propagating
that criteria into the transport system has the potential for
reclaiming bandwith.

> - does that make the messages spam?

It makes it "unwanted" and therefore it need not be sent which would
potentially save resources.

>I think we should stick with

I'm happy to try to revise this from that perspective, but I'm not
sure how artificial it will look, the only definition which was
obviously implied by the rest of the analysis was "unwanted", it may
look a bit artificial if the definition is changed. I'll give it a go
and maybe present a couple of alternatives.

> 2.2.1 Why the prohibition on the use of non-SMTP protocols?
...
> Or perhaps the section means only that the mail itself should
> not use another protocol.

Yes more or less, I actually meant that the process of delivering or
not-delivering mail should not require any communication by the sender
using anything other than the technology required for email. We've
seen suggestions involve logging into web-sites to verify your right
to send etc.

>Then it should say so. I hear so many complaints

Absolutely.

...

> spam folder. Or did I miss it somewhere?

I think so, that whole premis of 2.1 is that the cost of operating
should fall with the introduction of the technique. Experience
suggests that it would be preferable to abandon processing as soon as
possible, but I didn't want to make judgements about how best the cost
saving might be achieved, as to do so would be to pre-judge based on
an assumption.

> analysis.

Not at all, many existing techniques stack up quite well against this,
dnsbl's, DK, spf etc etc would all be partial techniques which could
affect an overall reduction.
I hope that there is scope for choice as to the application of
criteria and the point at which they are applied.

> At the very least users need to be able to cooperate or to

Agreed, but in that case you are really delegating your right to make
the decision by outsourcing it like you might outsource any other
aspect.

> standards, and if not, where they fail?

I will do, but I don't have as much time as I'd like so it may be a day or two.

Thanks for your comments.

d.

---

From: "Walter Dnes" <[email-masked]>
Date: Tue, 23 Jan 2007 17:21:19 -0500

On Mon, Jan 22, 2007 at 06:51:26PM +0000, Justin Mason wrote

> safely filter spam, except with a user-trained classifier
> (Bayesian-style probabilistic classification for example).

  No, you're missing the point entirely, although it may be partially my
fault for not making it clear enough.  Here's a Venn diagram.
     ______
    / ____ \
   / /    \ \
  | | spam | | <<== Unwanted email
   \ \____/ /
    \______/

  "spam" is a slang word, which is often used to describe *A SUBSET OF*
unwanted email.  Some legal jurisdictions have legislation that defines
spam very narrowly.  If you insist on blocking "spam", you *WILL* end up
spending a lot of time and money in court cases where...

  1) the spammer insists that his spam is "not-spam" because of some
technicality.  Expect to see lots of legal "is not spam; is so; is not;
is so; is not" being billed at lawyers' regular rates.  And of course,
you can rest assured that the politicians who enact legislation will
make exemptions for solicitations for campaign contributions.  Any
"spam-filters" that block any "not-spam" *WILL* get hit with
cease-and-desist orders

  2) saying that Joe Blow sends spam is equivalant to calling him a
spammer.  Watch the defamation (libel/slander) lawsuits fly.

  However, if you block "unwanted email" rather than "spam"...

  1) spammer says "wahhh, wahhh, wahhh, my 'valuable information' is
'not-spam'" and you can enthusiastically agree.  The the customer still
doesn't want it.  "Because I said so" should be sufficient reason.

  2) By not labelling unwanted email as "spam", you're not labelling the
sender as a spammer.  Spammers can still launch frivolous lawsuits, but
at least don't give them legal ammo.

  To summarize, *DON'T LET THE SPAMMERS PICK THE BATTLEFIELD AND SET THE
RULES*, because they'll obviously stack the deck in their favour.  The
best analogy is dealing with telemarketers, close cousins to email
spammers.  The main rule is to *NEVER* give a reason for saying "No"
other than saying "I don't want it; good-bye".  A competent (I dislike
using the word "good") telemarketer will have been trained to refute
just about every logical argument you can come up with to not buy their
product.  These people are pros; this is their livlihood; they will
argue circles around you.

  Similarly, don't try to define "the S-word" in technical terms.  A
bunch of geeks sitting at their keyboards are no match for a nit-picking
lawyer who was the captain of his class debating team.  It's effectively
a pro se defense against high-powered lawyers, and the results are very
predictable.  Don't engage in a battle you can't win.  Go with...
  - our customer says he doesn't want your emails.  No, we don't know
    why he doesn't want your emails.
  - the customer is always right; end of story.
  Don't give the spammers' lawyers anything to attack.

> It's too subjective, and would outlaw DNSBL usage, as far as I
> can tell...

  Not at all.  It does require separate rules for each customer.  The
following is not a paid commercial, and I am not receiving in financial
consideration for making these statements<g>...

  - I am a customer of clss.net (Aurora Internet)

  - they have a modified Qmail that generates 550 SMTP-stage rejects
    (i.e. *NOT* a DSN) based on a customer-configurable control file in
    the customer's home directory.  There are separate rule files for
    sub-accounts.  E.g. I point my domain MX at their server.  abuse and
    postmaster are basically unfiltered compared to this address.

  - step 1 is to declare a whitelist of emails that I accept
    unconditionally

  - I don't want email from residential machines on dynamic IP addresses
    sending direct-to-MX.  So I block based on dynamic IP DNSbls, regexp
    filter against rDNS, and obviously block email from machines with no
    rDNS whatsoever.

  - I don't talk to myself.  I don't want email from people who lie in
    their email, by including "waltdnes.org" in the HELO or return-path.
    So I block those emails.

  - I don't want email from certain /8's (RIPE, AFRINIC, LATNIC, and
    most of APNIC (punch holes for Australia and New Zealand using
    zz.countries.nerd.dk)), so I block those /8's.

  - I don't want email from certain countries, so I block them, using
    country-codes in rDNS and return-path

  - I don't want email from addresses that are listed by Spamhaus,
    because I said so.  Therefore I use Spamhaus' DNSbl.

  - etc, etc.

  Executive summary...

  - blocking email, because it meets some technical criteria, is easier
    on the technical side, but introduces legal problems

  - blocking email, because the customer said so, may be harder
    technically, but avoids legal problems

  - any complications on the anti-spam side are outweighed by equivalant
    complications on the spammers' end.  ISPs will have to enable end
    users to configure their own rules, and everybody's filters and
    whitelists will be slightly different.  Imagine how spammers will
    feel knowing that each of several million targets for a spam-run has
    a slightly different defense, that has to be overcome in order to
    deliver the email.

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 23 Jan 2007 18:50:04 -0500 (EST)

>  | | spam | | <<== Unwanted email

All I can say is, you are certainly welcome to block any mail you please, 
and no cooperation from other MTA operators is required, nor is any 
meeting of the IETF. The only purpose for the IETF involvement is to 
coordinate cooperative action. Since the IETF is voluntary, the action 
needs to be of benefit to all participants, and that greatly restricts the 
field of actions practical for widespread implementation. But it doesn't 
in any way restrict what you as an individual can do.

Since your method requires no cooperation from any other MTA operator, it 
doesn't require any endorsement from this group. That is fine - it doesn't 
make your method illegitimate or anything like that. But most users wish 
for a cooperative anti-spam technique, because they reasonably expect it 
will work better, and they reasonably expect many other MTA operators to 
cooperate with them. This has been true in the past - consider the many 
DNSBLs and other activities against spam. When we kept a list of spamming 
IP addresses sending to our MTA, we found after 2 weeks that only 1% of 
the IPs had send more than one message. Our subscription to Spamhaus kills 
about 65% of incoming messages. That is a victory for cooperation and it 
makes us think that more cooperation might be better.

It is true that cooperative actions attract lawsuits, but that is only 
because it isn't practical to sue an individual for refusing mail, but it 
is pratical to sue a corporation for blocking a large number of messages. 
If Spamhaus changes its name to Unwantedmailhaus, I don't expect that will 
affect its legal situation.

Daniel Feenberg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 25 Jan 2007 01:14:07 -0500

>   - step 1 is to declare a whitelist of emails that I accept

The problem being that out of the 60,000 seats here, perhaps less than
10 of them are able to competently configure a set of rules like what
you have.  Many of them don't even have a clear notion of the concept of
"source IP" is, let alone being able to make reasonable choices of, say,
knowing why you'd want to block dynamic IPs or IPs in Korea.

Furthermore, and with complete irony, I'll note that the only reason I
read this thread is that my very own, personally trained, UA bayesian
filtering flung it all in the junk folder! ;-)

>     on the technical side, but introduces legal problems

Not for us.  Furthermore, the risk of it is being overstated, and I
don't think we should be making recommendations based upon what risks we
think other people should be allowed to take.

>     a slightly different defense, that has to be overcome in order to

We're achieving effectiveness rates in excess of 98% with our "one set
of rules" server based defences.  My personal account, which receives
400-600 emails/day, has 100 or more spams/day filtered out by the
central server solution.  I usually go a week or so between spams that
get past those central filters - I see _many_ more FPs with my bayesian
than I see spam getting through.

My personally trained bayesian filtering has an absolutely abysmal track
record.  On the spam aimed at the false positive handling address, which
by design has _no_ filtering, Bayesian has an effectiveness rate of
about 50%.  Yuck.  No amount of personal twiddling, custom rules,
explicit pattern matching in my UA is going to make much difference to that.

---

From: "David Nicol" <[email-masked]>
Date: Thu, 25 Jan 2007 11:30:08 -0600

> explicit pattern matching in my UA is going to make much difference to that.

I wonder if Paul Graham was being underhanded and evil or merely naive when
he claimed that the level of noise allowed to pass through Bayesian
filters would
be acceptable http://www.paulgraham.com/spam.html

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:34:50 -0500

> be acceptable http://www.paulgraham.com/spam.html

I had a long discussion (people bought popcorn to watch the fireworks,
but were disappointed ;-) with another of the 2 or 3 "big name" Bayesian
proselytizers at a big virus conference some years ago.

At the time, I realized one simple truth - the whole thing was based on
ridiculously small sample sizes.  Eg: < 100 emails/day.  I laughingly
suggested I'd aim _my_ load at him (3-4 orders of magnitude higher), at
which point he visibly winced and got rather quiet ;-)

I've also found it rather disconcerting that Graham's (and others)
papers about the possibility of fooling Bayes is rather egregiously
flagrant arm-waving and sleight-of-hand.

In all fairness, the guy I spoke to did say that TBird's Bayes was
rather badly (he almost thought _deliberately_) crippled.  When I reset
Tbird's Bayes training, the filtering actually gets better (except for a
short-lived spike in FPs), but then gets worse over time.  Explain
_that_ ;-)

[I have this possibly naive impression that (some?) Bayes classification
is vulnerable to "flooding" - smearing/smudging the spammyness/
non-spammyness of words into a vast morass of "not very anything",
leading to most computed scores being so close to neutral that Bayes'
conservative score thresholding treats it as "I dunno", and lets it
thru.  Of course, spam with few words (eg: graphical spam) is
particularly hard to deal with via Bayes techniques.]

He was showing interesting results with his Bayes - it even did a decent
job of distinguishing viral binaries from non-virus binaries.  But that
wouldn't work with per-emit munging.  His viral detection appeared to be
largely based on making Bayes "score" variable length binary fragments,
and noticing the commonality of particular code fragments in malware.

But even if it worked as claimed, the vast majority of our users simply
aren't interested in training Bayes (or ANYTHING ELSE) to recognize spam.

"Dear CEO, senior executives, staff and shareholders, we require you to
spend [in some cases VERY expensive] manhours to train/configure your
filters".

To which I'd get the reply "that's _your_ job, you're obviously not
doing it...".

I'd fire _myself_ for incompetence ;-)

They want spam stopped, _period_.  This is as true in the ISP world as
it is in the corporate one.

Out of a population of 60,000-120,000 users, with more than 10 years of
experience, we've had fewer than five people ask to have their filters
turned off.  All of those changed their minds after I told them how many
spams we block for them ;-)

---

From: "Walter Dnes" <[email-masked]>
Date: Thu, 25 Jan 2007 22:52:25 -0500

On Thu, Jan 25, 2007 at 01:14:07AM -0500, Chris Lewis wrote

> "source IP" is, let alone being able to make reasonable choices of, say,

  In the case of a corporation, the end-user is *NOT* the customer; the
corporation (i.e. higher management) is the real customer.  At an ISP, I
outsource the POP and SMTP servers to the ISP, because it's too much
hassle for me to maintain patched, secure, servers, with big UPS,
failover, etc.  I chose to maintain my own mailfilters, with the ISP
maintaining the physical servers.  If 90% of customers choose to
outsource unwanted-email-blocking, that's their right.

> knowing why you'd want to block dynamic IPs or IPs in Korea.

  Because the computer guru in the next cubicle at work told me.<g>

> filtering flung it all in the junk folder! ;-)

  Bayesian filters belong in the junk folder.

> My personally trained bayesian filtering has an absolutely abysmal
> track record.  On the spam aimed at the false positive handling
> address, which by design has _no_ filtering, Bayesian has an
> effectiveness rate of about 50%.  Yuck.  No amount of personal
> twiddling, custom rules, explicit pattern matching in my UA is going
> to make much difference to that.

  You seem to be mis-reading my message.  Nowhere did I praise Bayesian
filters.  I was talking about different users with different whitelists,
adding different DNSbls, blocking different countries and IP address
ranges.