Return-Path: <owner-ietf-mta-filters@mail.imc.org>
X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by core3.amsl.com (Postfix) with ESMTP id 9CC753A68DE
 for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>;
 Thu, 11 Sep 2008 01:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.314, 
 BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 xCB5fbC7e7YO
 for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>;
 Thu, 11 Sep 2008 01:32:23 -0700 (PDT)
Received: from balder-227.proper.com
 (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2])
 by core3.amsl.com (Postfix) with ESMTP id 683483A69C5
 for <sieve-archive-Aet6aiqu@ietf.org>; Thu, 11 Sep 2008 01:32:23 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1])
 by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8B8MAjB062524
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Thu, 11 Sep 2008 01:22:10 -0700 (MST)
 (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost)
 by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8B8MA8Z062523;
 Thu, 11 Sep 2008 01:22:10 -0700 (MST)
 (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to
 owner-ietf-mta-filters@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30])
 by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8B8Lv3u062490
 for <ietf-mta-filters@imc.org>; Thu, 11 Sep 2008 01:22:09 -0700 (MST)
 (envelope-from arnt@gulbrandsen.priv.no)
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1])
 by kalyani.oryx.com (Postfix) with ESMTP id D49854AC59;
 Thu, 11 Sep 2008 10:21:54 +0200 (CEST)
Received: from arnt@oryx.com (client address 195.30.37.40) (HELO
 lochnagar.oryx.com) by kalyani.oryx.com with esmtp id
 1221121314-18031-795 (7 recipients); Thu, 11 Sep 2008 10:21:54 +0200
Message-Id: <wDKd7ZngCu6pB/pwWdgt9g.md5@lochnagar.oryx.com>
Date: Thu, 11 Sep 2008 10:22:00 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf@ietf.org, ietf-mta-filters@imc.org
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
Cc: Cyrus Daboo <cdaboo@apple.com>,
 Alexey Melnikov <alexey.melnikov@isode.com>, asrg@ietf.org, iesg@ietf.org
References: <20080727120256.E26073A68B7@core3.amsl.com>
 <g6i7at$je$1@ger.gmane.org> <01MXNCRX5OM200007A@mauve.mrochek.com>
 <48C8468D.2030804@elvey.com>
In-Reply-To: <48C8468D.2030804@elvey.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Mime-Version: 1.0
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>


Matthew Elvey writes:
> If a system implementing the specs we're working on works on a=20
> store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS=20
> USERS by claiming to support the enhanced standard we are writing.=20
> -07 allows an implementation to mislead its users by claiming to=20
> support enhanced functionality when it does no such thing.

Why not? My code (I implemented -07 a few weeks ago) advertises support=20
for the standard even if it may or may not provide enhanced=20
functionality. I think that's fine. It does provide in-protocol=20
rejection when possible, and the rules have very pleasant consequences.=20
Most importantly, it's possible to make system configuration changes=20
that affect system's ability to to in-protocol rejection without=20
invalidating anyone's sieve script.

> That would simply be dishonest.

It's just another RFC about best-effort something something. There are=20
many others already, so most implementers are familiar with the=20
concept. And AFAICT, implementers generally implement a best effort,=20
not behave dishonestly.

(I read some more of this monster mail, but IMHO it degenerates into a=20
pure rant around the point where Aaron Stone is first called =ABthe=20
author of -07=BB. Not worth answering.)

Arnt


