IETF Logo Mail Archive

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

Ned Freed <ned.freed@mrochek.com> Fri, 05 January 2018 05:58 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 2C61D1270A7 for <extra@ietfa.amsl.com>; Thu, 4 Jan 2018 21:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ju2j9ln9PUWa for <extra@ietfa.amsl.com>; Thu, 4 Jan 2018 21:58:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 DAF83126C2F for <extra@ietf.org>; Thu, 4 Jan 2018 21:58:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNGRP4HFW0001133@mauve.mrochek.com> for extra@ietf.org; Thu, 4 Jan 2018 21:53:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515131594; bh=HJZ5zXa9UMWUTnU/Fzba2uI+NSBEwpmZKvaG+bEI9Iw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ruJ3yzhEyIXL/EOulk1oSBh25seFV6L+OBj4JBRJhEyWYvXg3Tzeqc1UoNwAFMrgy 2F4PJrUVsEbr3TWiIwpunXhIyRJdq04vC610TGzgviCsINISVlDlm5szGcIBmftEWn CwLQdsrrrYEYvids2/FPc9xejAU9O2L+ogWOCmbw=
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 <01QNGRDZCUDC000052@mauve.mrochek.com>; Thu, 04 Jan 2018 21:53:10 -0800 (PST)
Cc: Ned Freed <ned.freed@mrochek.com>, Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
Message-id: <01QNGRP0BAO2000052@mauve.mrochek.com>
Date: Thu, 04 Jan 2018 21:50:35 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 04 Jan 2018 10:58:10 -0500" <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com>
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> <5985d59e-ae0b-030d-cae1-94b63d1e807e@fastmail.com>
To: Ken Murchison <murch@fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/tjYD7j457klWrG8STDb2Di3ESqI>
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: Fri, 05 Jan 2018 05:58:24 -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.

I have no real preference between a mandatory MDN and removing the
capability.

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

Works for me. Vacation and notify are essentially the same code in our
implementation; two capability strings are actually more work.

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

I don't know enough about other methods people have implemented to make
any sort of assessment.

				Ned

v2.23.0 | Report a Bug | By Email