Re: [Extra] Sieve addheader

Ned Freed <ned.freed@mrochek.com> Wed, 08 April 2020 20:55 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609FD3A1738 for <extra@ietfa.amsl.com>; Wed, 8 Apr 2020 13:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9sh53Zf18OW for <extra@ietfa.amsl.com>; Wed, 8 Apr 2020 13:55:39 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4183A16EA for <extra@ietf.org>; Wed, 8 Apr 2020 13:55:39 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJGT9NAZCG005WAN@mauve.mrochek.com> for extra@ietf.org; Wed, 8 Apr 2020 13:50:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1586379035; bh=0OXPZ6Z749ApZL8yHN/yiznaCMsspBowLTBSr4Nhhvc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=KvqJyC1tXYpLsnFtGjo85oN/ihADdU2DTgZ8NhFRaTcH441q7meAVyRO0CgAD6yND f91iPMch1HfaQmYtCBJUREcoUPfsvvqJd8s5OMeAayEuTm7kx3N2zDDy/Fc+e5ih5N KVrw3x9hUz7nb7uVBiz8IdTFb/lgaqTJBCAkwv/I=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RIHLDFQH34000058@mauve.mrochek.com>; Wed, 8 Apr 2020 13:50:33 -0700 (PDT)
Cc: extra@ietf.org
Message-id: <01RJGT9LNVQA000058@mauve.mrochek.com>
Date: Wed, 08 Apr 2020 13:38:10 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 08 Apr 2020 15:21:27 -0400" <5934b654-b045-d630-e34e-d52dbe469e20@fastmail.com>
References: <5934b654-b045-d630-e34e-d52dbe469e20@fastmail.com>
To: Ken Murchison <murch@fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/YnNcRDl4QKd2UG3qrz3uqe932ng>
Subject: Re: [Extra] Sieve addheader
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 20:55:41 -0000

> All,

> Had an interesting Sieve failure recently.  A user had an addheader
> action similar to this:

> addheader "X-Foo" text:
> bar
> ..
> ;


> My implementation simply (mistakenly?) took the value string as-is and
> appended CRLF when inserting it into the message.  This obviously breaks
> the message because

> "The CRLF before the final period is considered part of the value."

> per Section 2.4.2 of RFC 5228, which when followed by the CRLF that I
> add results in a blank line between the X-Foo header and any subsequent
> header.

> My question is, should implementations strip any trailing CRLF from the
> header value, or reject the script as invalid because the header value
> (with the trailing CRLF) isn't a valid "unstructured" element per
> Section 4 of RFC 5293?

I think either behavior can be justified given what the RFC says, but FWIW we
replace CRLFs with spacess. (We originally just removed them, but found the
result to be suboptimal with some scripts.) There's also the question of UTF-8
-> encoded words, which is tricky because you have to know the syntax to do it
correctly for structured fields.

				Ned