Re: IESG Statement on Spam Control on IETF Mailing Lists
Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 14 April 2008 20:59 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 8538928C2E4; Mon, 14 Apr 2008 13:59:49 -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 560FE3A6A83 for <ietf@core3.amsl.com>; Mon, 14 Apr 2008 13:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 j84YODa4O-A4 for <ietf@core3.amsl.com>; Mon, 14 Apr 2008 13:59:47 -0700 (PDT)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by core3.amsl.com (Postfix) with ESMTP id 1B11028C2E4 for <ietf@ietf.org>; Mon, 14 Apr 2008 13:59:46 -0700 (PDT)
Received: by wr-out-0506.google.com with SMTP id 50so967463wra.13 for <ietf@ietf.org>; Mon, 14 Apr 2008 14:00:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=JV0YNNdTSBuNVgvVx7rKu1GUBxyOwWh0dsj0xwEk4FY=; b=NPy9FlNt9zDTCeJWphD4aIWoiHkK1GJ4UR2T0wVLHCfK0/BjYfKpd4QbqbmVGtiFm62NERI8XBHkq/Q2wsB2IANHPVrDZV95BgRGTi8j9wCagQGZ3NqV4pEv//evdXYI54Y5qvS5t4doFaeIJv+HSAELeHFRolIav2aKu+rL5xQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XeIa7yz8lfSe/l+AvfFYrdzJlJoby0KcGPJnXJMv4uhu5trrsy6nN8ySs+P9p9J5L0/KWWgdSgfVlPuTzokbe/1euktAGzrTq0cLFLRr6h5c+3JRUXZ66JFjijG7dSxZ7vdlsv+BHH2Cw0FdXwttXDYAbAuv9Nl4aCOdmBKahK8=
Received: by 10.140.187.10 with SMTP id k10mr3760478rvf.86.1208206817096; Mon, 14 Apr 2008 14:00:17 -0700 (PDT)
Received: from ?10.1.1.4? ( [203.173.144.37]) by mx.google.com with ESMTPS id l31sm10969299rvb.2.2008.04.14.14.00.10 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Apr 2008 14:00:13 -0700 (PDT)
Message-ID: <4803C5D7.7020900@gmail.com>
Date: Tue, 15 Apr 2008 09:00:07 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Henrik Levkowetz <henrik@levkowetz.com>
Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists
References: <20080414153938.0A5153A6D4D@core3.amsl.com> <4803BDB1.4030005@levkowetz.com>
In-Reply-To: <4803BDB1.4030005@levkowetz.com>
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
+1 to Henrik's comments. I don't think the two MUSTs that he comments on are algorithmically possible. Brian On 2008-04-15 08:25, Henrik Levkowetz wrote: > Hi, > > On 2008-04-14 17:39 IESG Secretary said the following: >> 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. > > Umm -- I think I understand what this *intends* to say, but I'm not sure. > > What I'm reading it as actually saying, though, is that a poster who > thinks he is a legitimate technical participant is to be provided means of > *bypassing* moderation. > > A means of bypassing challenge-response could be to send a mail to one > of the list admins to forward to the list, but since moderation is (at > least normally) provided by the list admins, and essentially any human > who receives a message and is asked to forward it to the list will have > to judge whether the message is relevant and appropriate, which constitutes > moderation as I understand it, the statement above seems to imply that > there has to be some way, untouched by a human making any kind of evaluation, > to force a message to be posted to a list??? > > It would be rather helpful for an explanation or rationale to be provided > for a statement such as the above, which to me reads as a very categorical > statement that no kind of challenge-response, moderation, or other > reasonable guard against spam can be put in place without extraordinary > efforts at providing means to *force* a circumvention of the same. > > I'm pretty sure that the third bullet above isn't intended to almost > completely nullify the first bullet, but I'm actually not sure how to > set up anything but painstaking manual inspection of every spam in order > to adhere to the third bullet as written. None of the mechanisms currently > available, including TMDA, spam-assassin, and blocking of posts from > non-subscribers followed by manual inspection seems to fulfil this as > I read it, which leaves me at a loss. > >> * IETF mailing lists MUST provide a mechanism for legitimate technical >> participants to determine if an attempt to post was dropped as apparent >> spam. > > Again, an umm... I'm not sure I'm aware of an available technical solution > which out-of-the-box will ensure this is followed, without at the same time > resulting in a deluge of back-scatter. If there was a SHOULD here, I could > imagine working over a bit of time at setting up Mailman to drop-and-archive, > but currently the solution which comes to mind is to reject, which (I believe) > potentially will result in backscatter and more work and/or junk for the list > admin. > > Overall, I'm slightly surprised at how categorical several of the statements > above are, without providing rationale and background information which would > have made it possible to fully understand them. It seems as if they are > presented as decrees from on-high which have to be followed even if they > aren't understood to be sensible or implementable... > >> * 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 > > > Henrik > _______________________________________________ > 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
- IESG Statement on Spam Control on IETF Mailing Li… IESG Secretary
- RE: IESG Statement on Spam Control on IETF Mailin… Hallam-Baker, Phillip
- Re: IESG Statement on Spam Control on IETF Mailin… Daniel Brown
- RE: IESG Statement on Spam Control on IETF Mailin… Russ Housley
- Re: IESG Statement on Spam Control on IETF Mailin… Eliot Lear
- Re: [dkim unverified] Re: IESG Statement on Spam … Michael Thomas
- Re: IESG Statement on Spam Control on IETF Mailin… Frank Ellermann
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- RE: IESG Statement on Spam Control on IETF Mailin… Hallam-Baker, Phillip
- Re: IESG Statement on Spam Control on IETF Mailin… Brian E Carpenter
- Re: IESG Statement on Spam Control on IETF Mailin… Brian E Carpenter
- Re: IESG Statement on Spam Control on IETF Mailin… Ned Freed
- Re: IESG Statement on Spam Control on IETF Mailin… Brian E Carpenter
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- Re: IESG Statement on Spam Control on IETF Mailin… Dave Crocker
- Re: IESG Statement on Spam Control on IETF Mailin… Ned Freed
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- Re: IESG Statement on Spam Control on IETF Mailin… Ned Freed
- Re: IESG Statement on Spam Control on IETF Mailin… Randy Presuhn
- Re: IESG Statement on Spam Control on IETF Mailin… Ned Freed
- Re: IESG Statement on Spam Control on IETF Mailin… John Levine
- Re: IESG Statement on Spam Control on IETF Mailin… Ned Freed
- Re: IESG Statement on Spam Control on IETF Mailin… Rich Kulawiec
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- Re: IESG Statement on Spam Control on IETF Mailin… Tim Chown
- Re: IESG Statement on Spam Control on IETF Mailin… Tom.Petch
- Re: IESG Statement on Spam Control on IETF Mailin… Tom.Petch
- Re: IESG Statement on Spam Control on IETF Mailin… James Galvin
- Re: IESG Statement on Spam Control on IETF Mailin… TS Glassey
- Re: IESG Statement on Spam Control on IETF Mailin… James Galvin
- Re: IESG Statement on Spam Control on IETF Mailin… James Galvin
- Re: IESG Statement on Spam Control on IETF Mailin… James Galvin
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- Re: IESG Statement on Spam Control on IETF Mailin… Frank Ellermann
- RE: IESG Statement on Spam Control on IETF Mailin… Hallam-Baker, Phillip
- Re: IESG Statement on Spam Control on IETF Mailin… Cullen Jennings
- Re: IESG Statement on Spam Control on IETF Mailin… Henrik Levkowetz
- Re: IESG Statement on Spam Control on IETF Mailin… James Galvin
- Re: IESG Statement on Spam Control on IETF Mailin… Frank Ellermann