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
Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Thu, 11 September 2008 08:32 UTC
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 > store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS > USERS by claiming to support the enhanced standard we are writing. > -07 allows an implementation to mislead its users by claiming to > support enhanced functionality when it does no such thing. Why not? My code (I implemented -07 a few weeks ago) advertises support for the standard even if it may or may not provide enhanced functionality. I think that's fine. It does provide in-protocol rejection when possible, and the rules have very pleasant consequences. Most importantly, it's possible to make system configuration changes that affect system's ability to to in-protocol rejection without invalidating anyone's sieve script. > That would simply be dishonest. It's just another RFC about best-effort something something. There are many others already, so most implementers are familiar with the concept. And AFAICT, implementers generally implement a best effort, not behave dishonestly. (I read some more of this monster mail, but IMHO it degenerates into a pure rant around the point where Aaron Stone is first called «the author of -07». Not worth answering.) Arnt
- Last Call: draft-ietf-sieve-refuse-reject (Sieve … The IESG
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Spencer Dawkins
- Strong Opposition due to spam backscatter. Re: La… Matthew Elvey
- Re: Strong Opposition due to spam backscatter. Re… Arnt Gulbrandsen
- Re: Strong Opposition due to spam backscatter. Re… Ned Freed
- Re: Strong Opposition due to spam backscatter. Re… Kristin Hubner
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Alexey Melnikov
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Aaron Stone
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Aaron Stone
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Spencer Dawkins
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Aaron Stone
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Arnt Gulbrandsen
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Aaron Stone
- Re: Last Call: draft-ietf-sieve-refuse-reject (Si… Alexey Melnikov