Re: IESG Statement on Spam Control on IETF Mailing Lists

James Galvin <galvin+ietf@elistx.com> Tue, 15 April 2008 15:09 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 4FC823A6D27; Tue, 15 Apr 2008 08:09:34 -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 B1E6328C134 for <ietf@core3.amsl.com>; Tue, 15 Apr 2008 08:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 hBJqyY99YobA for <ietf@core3.amsl.com>; Tue, 15 Apr 2008 08:09:31 -0700 (PDT)
Received: from ee01.elistx.com (ee01.elistx.com [67.155.182.182]) by core3.amsl.com (Postfix) with ESMTP id 861413A6F0A for <ietf@ietf.org>; Tue, 15 Apr 2008 08:09:31 -0700 (PDT)
Received: from CONVERSION-DAEMON.elistx.com by elistx.com (PMDF V6.3-2x2 #31546) id <0JZD00N01GPR5A@elistx.com> for ietf@ietf.org; Tue, 15 Apr 2008 11:08:15 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by elistx.com (PMDF V6.3-2x2 #31546) with ESMTP id <0JZD0078FGPQ3B@elistx.com>; Tue, 15 Apr 2008 11:08:15 -0400 (EDT)
Date: Tue, 15 Apr 2008 11:09:49 -0400
From: James Galvin <galvin+ietf@elistx.com>
Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists
In-reply-to: <4803C5D7.7020900@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>
Message-id: <087EED9ED62B7E6590D15F77@[192.168.1.2]>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.7 (Win32)
Content-disposition: inline
References: <20080414153938.0A5153A6D4D@core3.amsl.com> <4803BDB1.4030005@levkowetz.com> <4803C5D7.7020900@gmail.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

I'm not sure I agree.  I do agree with Henrik's comments to the 
extent that I think we need to be clear.  Obviously there's some 
ambiguity and we should clear that up.

My interpretation of the two statements is that they are 
complementary, not conflicting.  I would say that the third bullet 
is a response to the first bullet "running amok".  In other words,
if you're going to have SPAM control, you have to deal with the 
problem of false negatives.  It seems to me that all the third 
bullet is trying to say is that when individuals find themselves 
subject to a "denial-of-service" because of a false negative report 
from the SPAM control, there has to be a way for them to get 
through.

I don't know if that's what was intended.  If it was then that 
needs to be made clear.  This could be helped by explicitly 
suggesting a way around, which is to forward the message to a 
Chair, list moderator (easily visible on the Mailman listinfo page 
for the list), Area Director, or perhaps even to the Secretariat 
for forwarding to one of these people if the person is having 
trouble even getting to them.

If that's not what was intended then I agree completely with Henrik.

Jim



-- On Tuesday, April 15, 2008 9:00 AM +1200 Brian E Carpenter 
<brian.e.carpenter@gmail.com> wrote regarding Re: IESG Statement on 
Spam Control on IETF Mailing Lists --

> +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


_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf