Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Cyrus Daboo <cyrus at daboo.name>]

Hi Matthew,

--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <matthew at elvey.com> 
wrote:

> Lisa D reported being told: "There is strong WG consensus behind [-07]".
> Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS:
> Can you each please confirm that you stated that there is strong WG
> consensus behind [-07]?

Yes, I can confirm that and firmly believe that the overall consensus of 
the WG is to publish the -07 draft. I don't believe there is a need to 
re-poll the WG on this, but if the IESG would be more comfortable doing so 
given your comments I am happy to do so. Also, if other WG participants 
wish to speak up in support of one position or another right now, they are 
certainly free to do so.

The history of this effort is quite clear in my opinion. The WG decided to 
enhance the existing 3028 reject command to allow use of "reject" behavior 
at SMTP/LMTP protocol time. At the moment I believe your main point is that 
you want the spec to mandate that ereject MUST only result in SMTP/LTMP 
protocol rejection and indeed that all implementations must support 
protocol level rejection. On the several occasions you have brought this 
issue to the WG mailing list it has been explained in detail that there are 
plenty of key use cases where only doing SMTP protocol rejection is notFrom ietf-bounces at ietf.org  Thu Sep 11 07:38:53 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BB1893A6B47;
	Thu, 11 Sep 2008 07:38:53 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 75FB33A6A10;
	Thu, 11 Sep 2008 07:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.995
X-Spam-Level: 
X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5
	tests=[AWL=-0.396, 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 42iKuJKrQRtH; Thu, 11 Sep 2008 07:38:48 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177])
	by core3.amsl.com (Postfix) with ESMTP id 514153A6B47;
	Thu, 11 Sep 2008 07:38:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by daboo.name (Postfix) with ESMTP id D2B24CA3DAA;
	Thu, 11 Sep 2008 10:38:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1])
	by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Rz4uIKQXf6bj; Thu, 11 Sep 2008 10:38:45 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44])
	by daboo.name (Postfix) with ESMTP id EB907CA3DA3;
	Thu, 11 Sep 2008 10:38:42 -0400 (EDT)
Date: Thu, 11 Sep 2008 10:38:40 -0400
From: Cyrus Daboo <cyrus at daboo.name>
To: Matthew Elvey <matthew at elvey.com>, ietf at ietf.org, ietf-mta-filters at imc.org,
	Alexey Melnikov <alexey.melnikov at isode.com>, iesg at ietf.org,
	Aaron Stone <aaron at serendipity.cx>
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call:
	draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering:
	Reject and Extended Reject Extensions) to Proposed Standard
Message-ID: <9DDB4F5E3C407069ECDF5DEC at caldav.corp.apple.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Hi Matthew,

--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <matthew at elvey.com> 
wrote:

> Lisa D reported being told: "There is strong WG consensus behind [-07]".
> Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS:
> Can you each please confirm that you stated that there is strong WG
> consensus behind [-07]?

Yes, I can confirm that and firmly believe that the overall consensus of 
the WG is to publish the -07 draft. I don't believe there is a need to 
re-poll the WG on this, but if the IESG would be more comfortable doing so 
given your comments I am happy to do so. Also, if other WG participants 
wish to speak up in support of one position or another right now, they are 
certainly free to do so.

The history of this effort is quite clear in my opinion. The WG decided to 
enhance the existing 3028 reject command to allow use of "reject" behavior 
at SMTP/LMTP protocol time. At the moment I believe your main point is that 
you want the spec to mandate that ereject MUST only result in SMTP/LTMP 
protocol rejection and indeed that all implementations must support 
protocol level rejection. On the several occasions you have brought this 
issue to the WG mailing list it has been explained in detail that there are 
plenty of key use cases where only doing SMTP protocol rejection is not 
possib 
possible (e.g. in the very common case where there are multiple recipients 
of the message and one recipient's script erejects, whilst another does 
not).

I think the current wording in the -07 spec is perfectly clear that 
implementations must make every effort to do protocol level rejection 
whenever possible. For example, the first section of 2.1.1 states:

    Sieve implementations that are able to reject messages at the SMTP/
    LMTP level MUST do so and SHOULD use the 550 response code.

Also, section 2.1 states:

    The ereject action MUST NOT be available in environments that do not
    support protocol level rejection

I think those are pretty strong statements about the use of ereject and 
protocol level rejections. I don't see why or how these need to be changed.

Unfortunately, claiming that the current specification results in a 
"spam-friendly RFC" is going to anger a lot of people who have spent a lot 
of time trying to address spam issues as best as possible. It totally 
misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you 
have very strong opinions on this, but I fear such comments are not going 
to result in forward progress.

If you feel that the IETF needs to publish a document stating that all 
email systems MUST support protocol level rejections (which I think is what 
you want to require of all implementors), then I suggest that you publish a 
new I-D to do just that and garner support for moving that forward in the 
IETF. At this point I consider WG consensus to be for publishing -07 - 
albeit with the various comments from IETF last call appropriately 
addressed by the authors.

-- 
Cyrus Daboo

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


le (e.g. in the very common case where there are multiple recipients 
of the message and one recipient's script erejects, whilst another does 
not).

I think the current wording in the -07 spec is perfectly clear that 
implementations must make every effort to do protocol level rejection 
whenever possible. For example, the first section of 2.1.1 states:

    Sieve implementations that are able to reject messages at the SMTP/
    LMTP level MUST do so and SHOULD use the 550 response code.

Also, section 2.1 states:

    The ereject action MUST NOT be available in environments that do not
    support protocol level rejection

I think those are pretty strong statements about the use of ereject and 
protocol level rejections. I don't see why or how these need to be changed.

Unfortunately, claiming that the current specification results in a 
"spam-friendly RFC" is going to anger a lot of people who have spent a lot 
of time trying to address spam issues as best as possible. It totally 
misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you 
have very strong opinions on this, but I fear such comments are not going 
to result in forward progress.

If you feel that the IETF needs to publish a document stating that all 
email systems MUST support protocol level rejections (which I think is what 
you want to require of all implementors), then I suggest that you publish a 
new I-D to do just that and garner support for moving that forward in the 
IETF. At this point I consider WG consensus to be for publishing -07 - 
albeit with the various comments from IETF last call appropriately 
addressed by the authors.

-- 
Cyrus Daboo

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf