Subject: proposed new spam policy

From: Steve Bellovin <[email-masked]>
Date: Sat, 07 Feb 2004 18:41:21 -0500

This is the proposed new mailing list anti-spam policy.  Comments 
requested...

--------

	Guidance for spam-control on IETF mailing lists

This note provides guidance on balancing the need to limit spam
with preserving openness of IETF mailing lists.  To preserve the
utility of mailing lists, some form of spam control MUST be used.
Uncontrolled lists are a denial of service attack on list members;
besides, complaints about the spam that arrives has been known to
shut down such lists.

Manual filtering is acceptable, if the approver is able to respond
to postings promptly.

The two extremes of mailing list operation run from a completely
open list in which no submissions are rejected to moderated lists
where a human reviewer must explicitely approve each submission.
Neither approach is desirable in most cases.  The more typical
approach is to allow some types of messages to be distributed with
no human check, while remaining messages are either rejected
outright, or sent to a human reviewer for rejection or approval.

Because of the massive increase in the spam rate in recent months,
many sites have been forced to resort to automated filtering of
various types.  Under certain conditions, such automated filters
MAY be used for IETF mailing lists.  Note, though, the difference
between spam control and moderation.  If there is any reasonable
doubt about whether or not a message is spam, it almost certainly
is not.  Moderation is governed by a separate policy,
http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt.

If an automated spam detector is used, it should take several
factors into account.  These include, in decreasing order of
importance:

	a) whether or not the purported sender is a subscriber to
	the mailing list.  This alone SHOULD NOT be relied upon as
	evidence that a message isn't spam, given the prevalence
	of "joe jobs" (spam that impersonates real users) and
	spam-sending worms.  Note that the following addresses MUST
	always be considered to be subscribers for this purpose:

                [email-masked]
                [email-masked]
                [email-masked]
                [email-masked]
                [email-masked]

        b) the likelihood that the message is spam, based on textual
        evidence, Bayesian filters, and the like.  Note the danger
	here of false positives;

        c) past behavior by that particular sending IP address;

        d) appearance of the sending IP address in assorted
        blacklists.  This last should be used with great caution,
        given the high rate of false positives.

A good spam detection mechanism will weight the various factors
and react accordingly.  A message from a known subscriber with the
word "mortgage" is probably not spam; a message from a non-subscriber
on a generic mail-hosting service that starts "I am Mariam Abacha"
and talks about hidden bank accounts almost certainly is; email from
a non-subscriber with the word "mortgage" may or may not be, and
should be examined more closely.

Mail containing executable content (Unix shell scripts, Windows
.exe files, and the like) or virus-infected attachments SHOULD be
discarded immediately, regardless of other positive or negative
indications.  Mail containing other types of attachments -- HTML,
Powerpoint, etc. -- is often inappropriate; posters are cautioned
to use their own judgment for each such email.  There is a tradeoff
here -- large, bulky files are often best handled by sending their
URLs instead; on the other hand, such practices mean that there
will be no easily-accessible archival record of their contents.
(Configuration of mailers to send HTML alone SHOULD NOT be done.)

In other cases, it MUST be possible for the sender of a legitimate
message to determine if it is has been dropped as apparent spam.
This can be done in several ways; all of these have their advantages
and disadvantages.

        a) Provide a Web-accessible archive of postings rejected
        in the past few days.  Few, if any, current mailing list
        packages currently do this, though some spam filters can
        easily be configured to do so.  This alternative is
	RECOMMENDED.

        b) Provide an up-to-date archive of accepted postings.
        Unfortunately, while this can show dropped messages, it
        doesn't help if the email is merely delayed, nor does it
        say why a message was dropped.  This MAY be used.

        c) Have the receiving MTA scan the message and send a
        500-class rejection to the DATA command.  This can lead to
        mailer timeouts and retransmissions.  This MAY be used, but
	(b) is a better alternative.

        d) Email back a rejection message.  In the event of forged
        spam -- and there's a lot of it -- this can lead to denial
        of service attacks on the purported sender.  This SHOULD
        NOT be done.

    Implicit in options (a) and (b) is that posting to an IETF mailing
    list is not guaranteed to be a reliable process -- it is up to the
    sender to verify that a message actually appears on the mailing
    list. This is not to mean that mailing lists are inherently
    unreliable, just that the burden for verification that postings
    are being delivered falls on the sender, not on the mailing list
    maintainer. Folks who post to lists they are not subscribed to
    need to pay particular attention.

If any spam filtering is done, there MUST be a bypass path by which
someone can complain that a message was inappropriately blocked.
The usual appeal chain -- WG chairs, ADs, etc., per RFC 2026 --
applies.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 7 Feb 2004 19:04:50 -0700

I think the point would come across more succinctly by starting with:

       1. This is a policy about mailing lists which use
        heuristic methods for automated message rejection to
        reduce the amount of spam delivered to list subscribers
        and to protect the subscribers from specific types
        of dangerous content.
        (I read the policy three times before reaching this
        conclusion; there seemed to be several other, related
        possibilities at first).

        2. The guiding policy has these goals:
           a. Protect subscribers from disrupted communication due to
                the burden of spam.
           b. Protect subscribers from dangerous content.
           c. Minimize the rejection of legitimate messages and
              allow the list to function without undue burden
              on the administrator.
           d. Protect the senders by giving them the information
              and methods they need for contacting the list
              administrator to request an override of an automated
              rejection.

I think the policy should also state some sort of goals for the
the time it takes to get a response to an override request, the
specificity of the rejection information given to the sender,
and the (in)appropriateness of extending the heuristics to cover
material that is neither spam nor dangerous.

I've found that the weak point in many of these systems is (of course)
the override request.  Administrators install the software and
neglect to configure it with their organization's contact information,
or the contact information is wrong.  It's like the bumper stickers
that say "If you don't like my driving go phone yourself" (roughly
translated).

Hilarie

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 08 Feb 2004 08:05:07 -0800

Thanks, Hilarie!

we need to be as clear as we can.
Apart from the point of requiring the "override mechanism" to work -do you 
think the goals and mechanisms described in this spam policy are reasonable 
and implementable?

                   Harald

---

From: "bill" <[email-masked]>
Date: Sun, 8 Feb 2004 10:00:28 -0800

We will trim the to/cc list a bit here...

Harold,

I am interested in policy from the IAB/IESG to allow filtering to
happen.  I am lesss intersted in physically how to do it.  There are
simple mechanisms (such as subscriber only posting) that cut SPAM WAY
WAY down (I am not sure IPoIB has gotten a spam in 3 years - now I am
deleting 30+ a day administratively)

It would be nice to have summaries that list criteria (spam assassin)
and the ability to auto delete certain messages, I liked Steve's start
to a policy - but my understanding is it would have to be turned into an
ID - debated, then become an RFC for it to become "official" policy

Bill

I am training for my first endurance event... and SAVING lives click
here to find out more!
http://www.teamintraining.org/participant/strahm-163543

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Harald Tveit Alvestrand
Sent: Sunday, February 08, 2004 8:05 AM
To: The Purple Streak, Hilarie Orman; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: proposed new spam policy

Thanks, Hilarie!

we need to be as clear as we can.
Apart from the point of requiring the "override mechanism" to work -do
you 
think the goals and mechanisms described in this spam policy are
reasonable 
and implementable?

                   Harald

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 8 Feb 2004 11:25:47 -0700

A reasonable question.  Yes.  In my experience, the false positive
rate on properly set spam filters is acceptably low.  The blacklists,
though, can be quite bad, and they sometimes prevent the sender
from contacting the list maintainer to complain.

Hilarie

Refreshingly, on Sun, 08 Feb 2004 at 08:05:07 -0800 Harald Tveit
Alvestrand sent this missive:

>  Apart from the point of requiring the "override mechanism" to work
>  - do you think the goals and mechanisms described in this spam
>  policy are reasonable  and implementable?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 08 Feb 2004 13:17:38 -0800

> deleting 30+ a day administratively)

Good - we were trying to achieve exactly that (policy not mechanism), while 
still making sure the policy was implementable.

> ID - debated, then become an RFC for it to become "official" policy

not to sound dense, but...... why?

The current spam policy 
(<http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt>, March 2002) 
was the result of the IESG having responded to multiple complaints about 
lists being spammed and participants' emails being lost to filters - 
eventually trying to wrap that advice up into a written document instead of 
handing out opinions after the conflicts had occured.

Now we're faced with a problem we didn't have then (too much work for the 
moderators), so we (the IESG) are suggesting to change it by the same 
process.

Is there any particular benefit you see to going the I-D + RFC route, 
rather than "just" updating the IESG's advice?

                      Harald

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 8 Feb 2004 19:01:39 -0800

I agree with Hilarie about having a short summary (such as hers) at the top.

>         evidence, Bayesian filters, and the like.  Note the danger

Small nit: "Bayesian" is a nonsense word invented by the filtering 
community, few if any who have read any of Bayes work. I propose 
dropping the word (but leave in "filters").

>         easily be configured to do so.  This alternative is

As pointed out, the tools for this are rare so far. I propose that 
the IETF itself host the system for doing this. List admins for WG 
lists would send all bounces to this system, and the system would 
post and cull after a few days for all IETF lists. The implementation 
is not so hard, but having exactly one implementation that can be 
tuned centrally is probably a good thing. This can easily run on a 
$200 computer hosted at the IETF.

--Paul Hoffman, Director
--VPN Consortium

---

From: Derek Atkins <[email-masked]>
Date: Sun, 08 Feb 2004 22:18:50 -0500

> dropping the word (but leave in "filters").

Actually, it's not nonsense at all.  Bayes was a monk who's writings
detail a statistical approach to understanding language.  It's quite
impressive.  Note that "internet" was also considered a nonsense word
twenty years ago, but that didn't stop people from using it until it
finally entered the vernacular.

I'd suggest leaving the word Bayesian in place, but making sure the
text reads that other forms of filtering are just as valid.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 8 Feb 2004 20:58:18 -0700

Derek is incorrect in asserting that Bayes was a monk, but that's
not germane.  Paul is correct in noting that Bayes' work applies to
almost none of the filtering methods used today.  "Heuristic", yes,
"statistical", yes.  But not "Bayesian".

Hilarie

---

From: Rob Austein <[email-masked]>
Date: Sun, 08 Feb 2004 23:04:07 -0500

At Sun, 8 Feb 2004 19:01:39 -0800, Paul Hoffman wrote:
> As pointed out, the tools for this are rare so far.

One such tool, written with this problem in mind:

  http://www.hactrn.net/hacks/spamtools/spamindex.pl

Suggestions for improvement welcome (but keep in mind that this is
supposed to be simple, so giving it the ability to brew my morning
coffee is definitely not part of the plan...).

---

From: Derek Atkins <[email-masked]>
Date: Sun, 08 Feb 2004 23:12:27 -0500

I appologize, you are correct in pointing out my error.  He was a
minister, not a monk.  However, being the father of Probability
Theory (http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Bayes.html)
I would have to argue that the current filtering is actually Bayesian,
predicting the outcome based upon counting previous history.

-derek