Subject: RE: Proposed new spam policy

From: [email-masked]
Date: Wed, 12 Oct 2005 18:23:17 -0400

Bill,

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

Need to define "promptly".  Spam on my WG lists (and I suspect
most others) has reached the level that responding to every
questionable message that shows up is no longer feasible.  Mailman
allows messages from list members and the important IETF addresses
through, saves the rest (notifying each sender immediately), and
bugs me every morning about the backlog.  I deal with the
resulting mess (at least 95% spam) once a day.  It needs to
be the case that dealing with questionable posts once a day on
workdays is acceptable, otherwise spam notifications become a
denial of service attack on WG chairs.

Do we really want to publish the "MUST be considered subscribers"
addresses.  Sooner or later, some spammer is going to figure out
that forging one of them as the From: address gets email through
to all IETF lists, but I don't see why we should make this easier.

Thanks,
--David (IMSS, IPS, and RDDP chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bill Fenner
> Sent: Wednesday, October 12, 2005 4:01 PM
> To: [email-masked]
> Subject: Proposed new spam policy
> 
> Following up on a long-lost TODO item: I took Steve Bellovin's  
> proposed updated spam policy that he circulated in February 2004 on  
> this list and added a few updates based on the discussion that  
> followed.  I'd like to see what people think of this version; if  
> there are no cries of "It'll never work" I'll bring it to the IESG  
> telechat to be approved to replace http://www.ietf.org/IESG/ 
> STATEMENTS/mail-submit-policy.txt .
> 
> Thanks,
>    Bill
> 
> 
>              Guidance for spam control on IETF mailing lists
> 
> 
> 1.
> 
>     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.
> 
>     We focus on the most common method of spam control: 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.
> 
>     This note 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.
> 
>     e.  Require that messages from legitimate senders that are not
>         members of the list to be accepted.
> 
>     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 explicitly 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.
> 
>     Manual filtering is acceptable, if the approver is able to  
> respond to
>     postings promptly.  However, because of the massive 
> increase in the
>     spam rate, 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].  Note also that it is not
>         accepable to simply drop messages from non-subscribers.
> 
>     b.  The likelihood that the message is spam, based on textual
>         evidence, statistical 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, whether a mailing list subscriber or not, 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.  One tool written with this problem in mind is 
> available at
>         <http://www.hactrn.net/hacks/spamtools/spamindex.pl>.  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.
>     Information about the bypass path SHOULD be available in the same
>     place as other mailing list information - i.e., subscription  
> address,
>     mailing list owner, archive location.  Such a complaint SHOULD be
>     responded to within 2 business days.  The usual appeal chain -- WG
>     chairs, ADs, etc., per RFC 2026 -- applies.
> 
> 
> Author's Address
> 
>     Bill Fenner (for the IESG)
>     AT&T Labs - Research
>     75 Willow Rd.
>     Menlo Park, CA  94025
>     USA
> 
>     Email: [email-masked]
> 
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 12 Oct 2005 18:35:04 -0400

> denial of service attack on WG chairs.

I have several (non-IETF) lists that I've managed in exactly this way for 
years.  This certainly seems like a reasonable approach to me.  We've 
recently started automatically discarding messages with high spam scores, 
in order to reduce the moderator workload (these lists would still meet the 
proposed IETF policy, because there is a public archive).  We see almost no 
problem with "joe-job" attacks - messages from subscribed addresses are 
virtually all legitimate.

> to all IETF lists, but I don't see why we should make this easier.

Nothing says you have to accept all posts from subscribers.  But yes, I do 
think we need a canonical list of special addresses that need to be able to 
post to any IETF WG list.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA