IETF Logo Mail Archive

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

Ned Freed <ned.freed@mrochek.com> Sun, 07 January 2018 13:46 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 C685A1200C5 for <extra@ietfa.amsl.com>; Sun, 7 Jan 2018 05:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 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] 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 iNvhxALBIjTD for <extra@ietfa.amsl.com>; Sun, 7 Jan 2018 05:46:26 -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 8E05712422F for <extra@ietf.org>; Sun, 7 Jan 2018 05:46:26 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNK0MWM8WW001RDD@mauve.mrochek.com> for extra@ietf.org; Sun, 7 Jan 2018 05:41:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1515332475; bh=OlB8k00iXTCJF3zHUvbaOmq3S/QOezxIllzyDoCFQiA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=nojxnGSe10XRbNZlt1+Gw7dNPPDcNGBo5VqBA2SI/br0y+VEf3z4PvLJ3g/BS5RJV Hx2NQRaM09R+Qa40rj4w03crVSXVonKYZRUJQug2BqkyWACW6rG6+DJNWSRPBuxesO xDyWDxOsw78WGQSTSoYxeoWFKZOF0I8xs2upUxtw=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNK0JD8F5C000052@mauve.mrochek.com>; Sun, 07 Jan 2018 05:41:02 -0800 (PST)
Cc: extra@ietf.org
Message-id: <01QNK0MRGMKC000052@mauve.mrochek.com>
Date: Sun, 07 Jan 2018 05:39:34 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 05 Jan 2018 10:40:24 +1100" <1515109224.681625.1224717176.520E1500@webmail.messagingengine.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> <BE46D703-89FF-4250-BFF8-EB194729D4CF@glyphein.mailforce.net> <4ae4f1d5-bf40-483a-ae88-befe01d3adef@gulbrandsen.priv.no> <7C65B98D-6755-4957-A181-CBA08354D11B@glyphein.mailforce.net> <1515109224.681625.1224717176.520E1500@webmail.messagingengine.com>
To: Bron Gondwana <brong@fastmailteam.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/jKkwkz2dRvj6PriJ-c1ancozV3o>
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: Sun, 07 Jan 2018 13:46:28 -0000

> Is everybody OK with having fcc not include reject, and having a
> separate capability (fcc-reject or similar) which administrators can
> decide whether or not to allow - and indeed, software implementations
> the choice whether or not to implement.

Not without the added condition that a MDN MUST be used if :fcc is present.

> That fixes both issues - those who really want the ability to lie can do
> so, but it's clear that they're enabling that facility, and it's also
> possible for both software vendors and administrators to not provide the
> facility in the first place.

My issue is that we have no business messing with the meaning of a 5YZ
code in response to a message transder. That cannot be fixed with capabilities.

				Ned

v2.23.0 | Report a Bug | By Email