IETF Logo Mail Archive

Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today]

Ken Murchison <murch@fastmail.com> Thu, 04 January 2018 15:58 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 0893E127867 for <extra@ietfa.amsl.com>; Thu, 4 Jan 2018 07:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=O2ow0saf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U2BB2vFW
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 Tj71XUUWue8o for <extra@ietfa.amsl.com>; Thu, 4 Jan 2018 07:58:12 -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 1015412704A for <extra@ietf.org>; Thu, 4 Jan 2018 07:58:12 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7766C20AEA; Thu, 4 Jan 2018 10:58:11 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 04 Jan 2018 10:58:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=z0b5QyaZe5MnWddsaF49ArpxqE+8k MIr49HdBeSsBOM=; b=O2ow0safjcBDw8mufZt9xsVTwGPiYL24wZGYHHyEejk+z AcRLbN76+auEM/QMeaT02VIv69kzyik4NVBAGqDbXUbTNgPUAE3eQHS6pysUayGW b3ZdgMWS8c//bTBFprX1p50TcpkacnEt5x6IjvGFiJr1h3AxTlQ+RuY2o6wMfOMQ PmPNAK/Tc3FYYsJGO3IWbJFXIuf1NbwTio7jU+kCXZ2SaN+qHbmoc6DESIJckp9J MfGXL2xIesg0sIN95gXxmyxbBeoBs+Gsvg4n4e8n6o1uJiKpb3NZwBq4z7zRnqY8 BlstifMdV7FToudaoVt373mYWAO24xDb65VVJ/MLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=z0b5Qy aZe5MnWddsaF49ArpxqE+8kMIr49HdBeSsBOM=; b=U2BB2vFWFPL47710nunwZ/ tD42CtnEsc2uz5uNVmJpdxvqKMrPmLgvbHchr51JV9Pu2e1HJg7e3viNd0iFQ+On TrbAk9n+JCcaWRQuH9kdQSR6ZWrk9KZw58CxSNEkW0OzQosvQZyktPQBntnWSVwm Z2Cln6P6V0ubptMmo5PmJ1hPJNi/08nK2hnnZZklB8gmz1O4g0gguy5GoBkmDhEh LHW5AyMf/5QeGS1Z/Pg3rE5yeWGcLV7xhiSX5W0p/JGbM6hFytGgC1TC4GnB7q5V OchcYuqCR1y7qnmIbF7jQofs+lnERwcEakDCDgrg81UKTjjbvO1lbzYp3ygYzRdw ==
X-ME-Sender: <xms:E09OWmHlk2F3oyi46l8P3lmbjLKH8aaj49hpYcwkUi7sJp1iAOcGSA>
Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 1726E7E183; Thu, 4 Jan 2018 10:58:11 -0500 (EST)
To: Ned Freed <ned.freed@mrochek.com>, Bron Gondwana <brong@fastmailteam.com>
Cc: extra@ietf.org
References: <1510734636.1704307.1173072248.27572238@webmail.messagingengine.com> <C0D8D552-4B1C-49D9-8CCC-E6F57F225C1A@glyphein.mailforce.net> <1515028094.3135331.1223576440.053F86DC@webmail.messagingengine.com> <01QNFXVO7LVS000051@mauve.mrochek.com>
From: Ken Murchison <murch@fastmail.com>
Message-ID: <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com>
Date: Thu, 04 Jan 2018 10:58:10 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <01QNFXVO7LVS000051@mauve.mrochek.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/OP4ocbcL9IWSNl3kIOetTjxDznE>
Subject: Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today]
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 04 Jan 2018 15:58:14 -0000


On 01/04/2018 10:17 AM, Ned Freed wrote:
>>
>>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana
>>> <brong@fastmailteam.com> wrote:>> *There is an open question for this one:*
>>>
>> So Ken - I'm happy to go ahead with "not supported on reject".
> The alternative is to require an MDN be used in this case. Which of course
> creates a possible source of backscatter.

My current plan is to disallow :fcc with reject, unless someone feels 
this needs more discussion.


>> The other open issue was separate capability string.  I don't think
>> that's necessary, and nobody else seems to have commented on it.
> Certainly not if :fcc only applies to vacation. However, if it applies
> to reject in a way that forces that extension to behave in a way some
> people find undesirable, things get a little more tricky.

Agreed.  If we exclude :fcc use with reject, are we comfortable having 
just one capability that covers :fcc use with both vacation and notify?


> Can you apply :fcc to a notify action that generates an email message? If
> not why not?
>
> And for that matter, can you apply :fcc to a notify action that generates some
> other kind of notification that could be mapped to an email?

I had planned on adding text specifically mentioning that :fcc could be 
used with email notifications.

I'm open to allowing it to be used with any notification action.  My 
initial thought would be to state that the mapping of the non-email 
notification content to an RFC5322 formatted message is implementation 
specific.  Do we feel the need to define strict mappings for all known 
notification methods?

-- 
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd

v2.23.0 | Report a Bug | By Email