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