Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)

Ben Campbell <> Thu, 10 January 2019 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99654130EFE; Thu, 10 Jan 2019 06:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LhoR9rnTzb6N; Thu, 10 Jan 2019 06:56:47 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 047C3130ED9; Thu, 10 Jan 2019 06:56:46 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x0AEuHj2043690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 08:56:18 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1547132179; bh=LwypdW+0t1i0EuD8AogPJBK7Zycc3idbnphESYkZMRE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jblGQnGRzO+dhu17zJ0j5gCJIzio8mpIIeLbYsTviIaS6bwWK0bAYXbkp1/tSea4O KWvfVFW3K/8b9OFXOp1H5cwYfNzdPOU3MWky4Sp8I1fsbRjhGgyo8mHKx3FtRwHSbb DQ/yyIOLWxXCZF9yi6VeoSFIGR4lwxmBJf6eybss=
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_84178FEF-D57A-43CF-BFAB-9FCAFC281495"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 10 Jan 2019 08:56:16 -0600
In-Reply-To: <>
Cc:,,, The IESG <>,
To: Alexey Melnikov <>
References: <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Jan 2019 14:56:49 -0000

> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <>; wrote:
> Hi Ben,
>> On 9 Jan 2019, at 21:51, Ben Campbell <>; wrote:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> Thanks for the work on this. I plan to ballot "yes", but have one item I think
>> needs to be discussed first:
>> The security considerations say that this extension adds no new considerations
>> not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not
>> sure that that is true.
>> It seems like the ability to insert a copy of message into a mailbox might have
>> security and/or privacy considerations.
> Can you give me an idea of what you have in mind here, other than putting the user (Sieve script owner) over quota?

I can’t say that I know what the security considerations might be; I’m just skeptical that the answer is “no new considerations." The authors of 5228 thought “fileinto” could be dangerous. Do we know why?

> In particular, what are the possible privacy implications?

Could there be issues with, say, shared mailboxes? Or storing cleartext for mail that would be sent encrypted?

I suspect the answers may be more IMAP related than sieve related, but even that might suggest citing something IMAP related.


> Thank you,
> Alexey
>> This seems analogous to the "fileinto"
>> action. I looked for security considerations for that in RFC 5228. All I found
>> was a statement that "fileinfo" can be dangerous, but no elaboration on the
>> nature of the danger or how it might be mitigated. So while I agree that fcc
>> would have similar considerations as "fileinfo", I'm not sure those
>> considerations have been adequately documented.  (I expect people will point me
>> to something I missed, or where some other analogous feature is documented, in
>> which case I will clear.)