Re: [sieve] On "reject" and :fcc

NED+mta-filters@mauve.mrochek.com Wed, 18 January 2017 15:37 UTC

Return-Path: <NED+mta-filters@mauve.mrochek.com>
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C24E129461 for <sieve@ietfa.amsl.com>; Wed, 18 Jan 2017 07:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.101
X-Spam-Level:
X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 x3S_npOKAJ45 for <sieve@ietfa.amsl.com>; Wed, 18 Jan 2017 07:37:09 -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 31EBE126D73 for <sieve@ietf.org>; Wed, 18 Jan 2017 07:37:09 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9TLG5CIGG000UZL@mauve.mrochek.com> for sieve@ietf.org; Wed, 18 Jan 2017 07:35:16 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Wed, 18 Jan 2017 07:35:12 -0800 (PST)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01Q9TLG2VN0W00004H@mauve.mrochek.com>
Date: Wed, 18 Jan 2017 07:23:46 -0800 (PST)
In-reply-to: "Your message dated Wed, 18 Jan 2017 07:07:38 -0500" <a7bd7023-3b0f-e987-1d7a-bb03a83c8665@andrew.cmu.edu>
References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> <01Q9SPQ6F0W000004H@mauve.mrochek.com> <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> <a7bd7023-3b0f-e987-1d7a-bb03a83c8665@andrew.cmu.edu>
To: Ken Murchison <murch@andrew.cmu.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sieve/GoCvb8uk8IpXqfusaB8uuQ1cyM0>
Cc: sieve@ietf.org
Subject: Re: [sieve] On "reject" and :fcc
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sieve/>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 15:37:10 -0000

> As it turns out, the point with soon be moot w.r.t. Cyrus.  I realized
> last night that I never implemented ereject, and when I do, Cyrus will
> reject at the LMTP level and therefore no DSN or MDN.

Yeah, I was going to mention that but forgot. This demonstrates a much more
fundamental problem with this whole idea of, "I want copies of all the messages
'the system' sends on my behalf." If a message is rejected due to use policy
encoded in sieve or wherever, it's always best to do that using a 5yz code over
protocol, which obviously provides no fcc capabilities.

This is also true if the reject occurs prior to delivery and the response is
sent over SMTP. So unless you say that the use of :fcc requires local
generation of the DSN - in the process making your system generate more
blowback spam that it would otherwise - you end up in a situation where the
user only receives copies of the subset of messages that happened to require
local DSN generation for some other reason.

And that's a pretty significant violation of the least astonishment principle.

I suppose you could do a hack where you generate your own version of DSN you
assume the SMTP client is going to create and stuff that in the user's folder.
But really, isn't this whole thing getting a little silly?

				Ned