Re: [sieve] proposal: align header with address
Aaron Stone <aaron@serendipity.cx> Wed, 24 March 2010 22:16 UTC
Return-Path: <aaron@serendipity.cx>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413483A6810 for <sieve@core3.amsl.com>; Wed, 24 Mar 2010 15:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.087
X-Spam-Level: **
X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, 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 wF6SdI8FLo21 for <sieve@core3.amsl.com>; Wed, 24 Mar 2010 15:16:04 -0700 (PDT)
Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id C4B383A683C for <sieve@ietf.org>; Wed, 24 Mar 2010 15:16:02 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id 4191611012F for <sieve@ietf.org>; Wed, 24 Mar 2010 15:25:22 -0700 (PDT)
Received: by pvh1 with SMTP id 1so3893807pvh.31 for <sieve@ietf.org>; Wed, 24 Mar 2010 15:16:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.58.7 with SMTP id g7mr1630689rva.37.1269468982147; Wed, 24 Mar 2010 15:16:22 -0700 (PDT)
In-Reply-To: <01NL4QZ1TAIC004042@mauve.mrochek.com>
References: <4BA9D770.40002@gulbrandsen.priv.no> <1629dc8c1003240821y5275d6cakb1ece5f28c8afd59@mail.gmail.com> <01NL4QZ1TAIC004042@mauve.mrochek.com>
From: Aaron Stone <aaron@serendipity.cx>
Date: Wed, 24 Mar 2010 15:16:02 -0700
Message-ID: <1629dc8c1003241516w409c21f9x15fc378c3abe9d3d@mail.gmail.com>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: sieve@ietf.org
Subject: Re: [sieve] proposal: align header with address
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2010 22:16:09 -0000
On Wed, Mar 24, 2010 at 2:58 PM, Ned Freed <ned.freed@mrochek.com> wrote: >> On Wed, Mar 24, 2010 at 2:12 AM, Arnt Gulbrandsen >> <arnt@gulbrandsen.priv.no> wrote: >> > Hi, >> > >> > an introduction first, as rationale. >> > >> > Several years ago I proofread parts of book which, among other things, >> > explained how to write sieve scripts. The authors used the header test >> > throughout. Prose like this: >> > >> > To test whether an address is addressed to fred@example.org, you write >> > >> > if header "to" :is "fred@example.org" { >> > fileinto "roles/fred"; >> > } >> > >> > I explained that 'if address' was the right test. They didn't believe that >> > header was wrong, and showed me examples proving its correctness, eventually >> > switching to from :is to :contains (mishandling alfred@). >> > >> > Not sure what the printed book said. >> > >> > People do misuse header in that way quite often. I've corrected the error in >> > internet-drafts several times, and recently (a few months ago) I saw a >> > misused 'if header' in a published RFC. >> > >> > When even the sieve WG members misuse a test, it's time to adapt the test to >> > human reality. >> > >> > So here's my proposal: >> > >> > 1. In the next iteration of base Sieve RFC, either allow or recommend >> > testing address fields as though 'if address' were specified, even if 'if >> > header' is specified. > >> Based on a the heuristic of seeing an @ sign? > > I have to say I think this is a *really* bad idea. While I am sympathetic to > the issue here, there are plenty of cases where I want to test an address field > using header and not address. Obvious one: Syntactically invalid fields that > address cannot parse. > >> > 2. Publish this an erratum now. > > Even stronger objection. THis is in no way, shape, or form an error in the > specificaiton, and it is a serious abuse of the errata process to make a > fundamental change to Sieve semantics. > >> [Simplistic question to elicit details:] >> When and how do 'if address' and 'if header :contains' differ? > >> Perhaps this table is what we publish as the erratum, explaining that >> yes, it will sometimes work, but here's how it's going to break. > > A discussion of thise issues strikes me as an excellent thing to put in a > "uses of Sieve " document. That's the way to attack this issue, not by > mucking up the clean semantics we currently have. I personally don't like Arnt's proposal of making header behave as address. I do like the idea of posting a clarification that yes, they are different, and really, we mean it, as an erratum if that's a reasonable use of errata. Aaron
- [sieve] proposal: align header with address Arnt Gulbrandsen
- Re: [sieve] proposal: align header with address Aaron Stone
- Re: [sieve] proposal: align header with address Arnt Gulbrandsen
- Re: [sieve] proposal: align header with address NED+mta-filters
- Re: [sieve] proposal: align header with address Aaron Stone
- Re: [sieve] proposal: align header with address Arnt Gulbrandsen