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