RE: IESG Statement on Spam Control on IETF Mailing Lists

"Hallam-Baker, Phillip" <pbaker@verisign.com> Mon, 14 April 2008 20:42 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0620428C346; Mon, 14 Apr 2008 13:42:37 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CD728C310 for <ietf@core3.amsl.com>; Mon, 14 Apr 2008 13:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bPcVty8vAkD for <ietf@core3.amsl.com>; Mon, 14 Apr 2008 13:42:34 -0700 (PDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 3C30F28C2FC for <ietf@ietf.org>; Mon, 14 Apr 2008 13:42:34 -0700 (PDT)
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m3EKh5eS023883; Mon, 14 Apr 2008 13:43:05 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 13:43:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: IESG Statement on Spam Control on IETF Mailing Lists
Date: Mon, 14 Apr 2008 13:43:14 -0700
Message-ID: <2788466ED3E31C418E9ACC5C316615572EF8F8@mou1wnexmb09.vcorp.ad.vrsn.com>
In-Reply-To: <200804141724.m3EHOxsR027745@pigeon.verisign.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IESG Statement on Spam Control on IETF Mailing Lists
Thread-Index: AcieVH7WnI5ey5N/Tnm3bGvHakzi/QAGljgw
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Russ Housley <housley@vigilsec.com>
X-OriginalArrivalTime: 14 Apr 2008 20:43:05.0093 (UTC) FILETIME=[239AC350:01C89E70]
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

The problem here is that what might appear to be a reasonable approach
and what can be proven to be a verifiable approach at reasonable cost
are not necessarily the same. 

I would rather anticipate the problem rather than wait for an issue.

It is not just the message archives that are relevant, the membership
lists are also very relevant, as are the mail server logs. It is also
questions of procedure, does the mail server corrupt DKIM headers &ct?
it is also about notice, does the list provide appropriate NOTE WELL
advice on subscribing to the list and on regular intervals thereafter?
Easy to set up if all the lists are set up in one place, impossible if
they are all over the place.

It seems to me that we have reached the point where it is rather easier
to ensure standards are met by bringing the process in house rather than
asking third party list maintainers about their practices.

I would suggest doing this gradually by making in house maintenance a
requirement for all new lists as they are created. 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com] 
> Sent: Monday, April 14, 2008 10:25 AM
> To: Hallam-Baker, Phillip
> Cc: ietf@ietf.org; iesg@ietf.org
> Subject: RE: IESG Statement on Spam Control on IETF Mailing Lists 
> 
> Phill:
> 
> When IETF lists are housed somewhere other than ietf.org, 
> they are supposed to include an archive recipient so that 
> there is an archive available at ietf.org (perhaps in 
> addition to the one kept at the place where the list is housed).
> 
> Russ
> 
> 
> 
> At 01:02 PM 4/14/2008, Hallam-Baker, Phillip wrote:
> >I would suggest that the IESG also think about hosting all 
> IETF lists 
> >in house in the future.
> >
> >The main reason for this is legal, a list that is maintained by the 
> >IETF is much more satisfactory in a patent dispute than one run by a 
> >third party. Last thing we want is to have patent trolls dragging a 
> >third party list maintainer into a dispute while they try to 
> argue that 
> >the list somehow does not count.
> >
> >And yes, I am aware that the 'law', might be on our side here. The 
> >problem is that it can cost a ridiculous amount of money to have a 
> >court decide the most obvious and basic question you might imagine.
> >
> >
> > > -----Original Message-----
> > > From: ietf-bounces@ietf.org 
> [mailto:ietf-bounces@ietf.org] On Behalf 
> > > Of IESG Secretary
> > > Sent: Monday, April 14, 2008 8:40 AM
> > > To: IETF Announcement list
> > > Cc: iesg@ietf.org; ietf@ietf.org
> > > Subject: IESG Statement on Spam Control on IETF Mailing Lists
> > >
> > > The following principles apply to spam control on IETF 
> mailing lists:
> > >
> > > * IETF mailing lists MUST provide spam control.
> > > * Such spam control SHOULD track accepted practices used on the 
> > > Internet.
> > > * IETF mailing lists MUST provide a mechanism for legitimate 
> > > technical participants to bypass moderation, 
> challenge-response, or 
> > > other techniques that would interfere with a prompt 
> technical debate 
> > > on the mailing list without requiring such participants 
> to receive 
> > > list traffic.
> > > * IETF mailing lists MUST provide a mechanism for legitimate 
> > > technical participants to determine if an attempt to post was 
> > > dropped as apparent spam.
> > > * The Internet draft editor, RFC editor, IESG secretary, 
> IETF chair 
> > > and IANA MUST be able to post to IETF mailing lists.
> > > The relevant identity information for these roles will be 
> added to 
> > > any white-list mechanism used by an IETF mailing list.
> > > * There MUST be a mechanism to complain that a message was 
> > > inappropriately blocked.
> > >
> > > The realization of these principles is expected to change 
> over time.
> > > List moderators, working group chairs and area directors are 
> > > expected to interpret these principles reasonably and within the 
> > > context of IETF policy and philosophy.
> > >
> > > This supercedes a previous IESG statement on this topic:
> > > http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
> > > That statement contains justification and implementation 
> advice that 
> > > may be helpful to anyone applying these principles.
> > >
> > > A separate IESG statement applies to moderation of IETF 
> mailing lists:
> > > http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt
> > >
> > > _______________________________________________
> > > IETF mailing list
> > > IETF@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ietf
> > >
> 
> 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf