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

Ned Freed <ned.freed@mrochek.com> Sun, 13 January 2019 15:35 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 9470312870E for <extra@ietfa.amsl.com>; Sun, 13 Jan 2019 07:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level:
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 9HvYo6vpD0lU for <extra@ietfa.amsl.com>; Sun, 13 Jan 2019 07:35:18 -0800 (PST)
Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 0F5F2124BF6 for <extra@ietf.org>; Sun, 13 Jan 2019 07:35:18 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1YEK9EV9S00F9MX@mauve.mrochek.com> for extra@ietf.org; Sun, 13 Jan 2019 07:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547393412; bh=eyLoIyrQSwsxAfB8a+/DWr0CfzD5S56Lfm62lufieC0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=EnQ2zLDaC4afzpYN47KGbre7sg4bwtp5X7rDbJ/Uf1AtrTNPmFI3rZH6Gu3kY6yrA ub9eJFH8Jxa89B22nY/j4YKgEnUq1OjKFBSFAaCgkERZAT2m03+hFzW2Ap3EqJEcNO 2q0iRjROOB5QFzzPc9ixBQiLfDPc3ZV9tKLNO9Rw=
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 <01R1N39ADWKW00004L@mauve.mrochek.com>; Sun, 13 Jan 2019 07:30:09 -0800 (PST)
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, extra <extra@ietf.org>
Message-id: <01R1YEK77JMI00004L@mauve.mrochek.com>
Date: Sun, 13 Jan 2019 07:22:49 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 13 Jan 2019 10:02:51 -0500" <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com>
References: <3489d633-6c9f-ccf5-8273-7101bf9fa55f@isode.com> <1f9e9303-6634-1e37-841f-f67d2d9c3a22@fastmail.com>
To: Ken Murchison <murch@fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/qM3zDK-Gb-W02EKx_dQ6Hxv3Sco>
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:35:20 -0000

> 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.

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.

				Ned