Re: [Extra] Status of draft-ietf-extra-sieve-fcc

Ken Murchison <murch@fastmail.com> Sun, 13 January 2019 15:42 UTC

Return-Path: <murch@fastmail.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 18A2D1288BD for <extra@ietfa.amsl.com>; Sun, 13 Jan 2019 07:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=Otn4nkLv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yHoQY1ok
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 L5RYknjrpZdy for <extra@ietfa.amsl.com>; Sun, 13 Jan 2019 07:42:32 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8B812870E for <extra@ietf.org>; Sun, 13 Jan 2019 07:42:32 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B132621B74; Sun, 13 Jan 2019 10:42:31 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 13 Jan 2019 10:42:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=SFvmS/nZ01Ki49q8yR6qwYGavZp QSpStOMpa/jRQUp8=; b=Otn4nkLvWbCg/c9Zbj22aMUwNWY27o/4VaDb4iuNLAJ aO+PqNVt0s8KHphjqI5n8BamGQaP0OJTw0fnj2UEbBZ/0xtYsGAtQWJxx3hyORvB KgwtfcdXSp8gG3wVlyey77jIjb2YJtgsg/ygMX5M6gyGvddvbCbAfWhY12TE7b6T QlkbA1JksvAcjC11Bc8zDuxMLu3SpqQd9gCbMFlOceamzniSuIz2TGRP9dJObVd9 4A3o0avJexCkkx8xkFeRHfVbFeY3JqTe6TtL88Qp286Xj4iDF1Z+lghXwk4q7d+k +A74PylqcI+zGEGqNe6+bmukNGpGiXwo/khzNZAcROg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SFvmS/ nZ01Ki49q8yR6qwYGavZpQSpStOMpa/jRQUp8=; b=yHoQY1okWaJ9wWdajExTTV Tp5QfHtUqWqdMZJMyPEZzRwTbCkQRWQgcH+R9DdbABT+vk4sarJn/Z3rdGD/vBKe gs/YtVlIzZtWHDD06rio0ShSLXTWeJ1bGwRkl3nxDeD7m0iY5AC7Bpjo+R5vImrC 5AwHkNfatDC2toW32c3GvrOb1p+0pG1ZBSsRwUIQRbVjOcGQxDEeQGWIhi3jGFSB GsOLFYqTEKq5ySEK0E18Fg4okE5eOl2rvQjxXek/4dbPBoPO3Og32+SKyH4KC/G/ o0lx/VslINS7/mBqm6j/KL9LBUm4vqhN4WXKjqyWBGBW1U6vUIHSRhFWrGu4gjrg ==
X-ME-Sender: <xms:Z1w7XI-G3AroZntEbfOuIRvKnB3DtNvwxwXAsAsH8YlRrYIcx2T-xQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeelgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhohfkff gfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehm uhhrtghhsehfrghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm necuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Z1w7XIdIaLfy3UN4T9OJFmXmIWBnN9N-Mr3ceztGOyI5NC8ourk2xA> <xmx:Z1w7XBGnZSFfCyD86k3z8ox96JiTmQJyvTjs5DmBGZ1ndtfVcxJGag> <xmx:Z1w7XGfpnljTrJ35MjIhzInqel8vw195DXpgQGIAU03QVVbYmk05tg> <xmx:Z1w7XEnFOJY7CqS7JHnLmqm0j95JwmLCWcQ24_46njmnzE6plgxJiw>
Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id D2536E407B; Sun, 13 Jan 2019 10:42:30 -0500 (EST)
To: Ned Freed <ned.freed@mrochek.com>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, extra <extra@ietf.org>
References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com> <01R1YEK77JMI00004L@mauve.mrochek.com>
From: Ken Murchison <murch@fastmail.com>
Organization: FastMail US LLC
Message-ID: <dd49ff64-0e95-ba5a-afe1-c24062c7d243@fastmail.com>
Date: Sun, 13 Jan 2019 10:42:31 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <01R1YEK77JMI00004L@mauve.mrochek.com>
Content-Type: multipart/mixed; boundary="------------CA826A9F454300319ACF4911"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/FI6BD952P4ApWEMihF2gooFciC0>
Subject: Re: [Extra] Status of draft-ietf-extra-sieve-fcc
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: Sun, 13 Jan 2019 15:42:34 -0000

On 1/13/19 10:22 AM, Ned Freed wrote:
>> On 1/10/19 11:40 AM, Alexey Melnikov wrote:
>> > Hi,
>> >
>> > Based on IESG review, I think the document should have some text about
>> > the following security/privacy considerations:
>> >
>> > 1) Possible information disclosure from generated messages which are
>> > filed to shared folders (as opposed to private folders). I.e. non
>> > intended parties might discover that a Sieve script owner is on
>> > holidays, owner's location, etc.
>> >
>> > 2) FCC can put owner over quota, causing denial of service.
>
>
>> How would this cause DoS?  If the FCC would put the user over quota,
>> presumably this would be treated as a run-time error, and the incoming
>> message would be be stored by an implicit keep.  Or are you just saying
>> that the FCC itself is what would be denied?
>
> It's not the effect of a single fcc, but rather that fcc can be used 
> to create
> an additional stream of messages, the cumulative effect of which would 
> be to
> put the user at or over quota.


Ahh, yes!  I hadn't thought about that.


> As for the handling of situations where the fcc can't be delivered, we're
> talking about notifications here, and we've learned the hard way that
> generating more traffic as as result of a notification delivery 
> failure is a
> REALLY bad idea. As such, I would expect an fcc delivery failure to be
> silently ignored. That's certainly how my implementation works.


Should we add text to this effect?


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC