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

NED+mta-filters@mauve.mrochek.com Wed, 18 January 2017 00:12 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 DBCAD129408 for <sieve@ietfa.amsl.com>; Tue, 17 Jan 2017 16:12:29 -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 pkMrZkYczr1q for <sieve@ietfa.amsl.com>; Tue, 17 Jan 2017 16:12:29 -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 E337D127A90 for <sieve@ietf.org>; Tue, 17 Jan 2017 16:12:28 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9SP1T06Z4000JVS@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 16:07:26 -0800 (PST)
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 <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 16:07:23 -0800 (PST)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01Q9SP1R5AP200004H@mauve.mrochek.com>
Date: Tue, 17 Jan 2017 15:43:47 -0800 (PST)
In-reply-to: "Your message dated Wed, 18 Jan 2017 10:29:08 +1100" <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com>
References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com>
To: Bron Gondwana <brong@fastmail.fm>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sieve/9PbVwUIEbmexp-1F8TiljvFzWJ0>
Cc: sieve@ietf.org, Ned Freed <ned.freed@mrochek.com>
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 00:12:30 -0000

> > Then keep a record of the rejection for the user, as opposed to keeping a copy
> > of the message that was rejected. Indeed, if you're going to keep track
> > of all rejections you have to allow for this in order to deal with
> > rejections that occur before the message transferred.

> OK, I see where the misunderstanding has come from. What I'm proposing is
> keeping a copy of the rejection. Basically the user wants a copy of every email
> sent on their behalf.

When a Sieve ereject/reject occurs prior to delivery, and circumstances require
the use of a message as opposed to an SMTP status code, use of a DSN is
required. RFC 5429, section 2.1.2:

   In this case, the server MUST accept the message and generate DSNs for
   all recipients that are refusing it. 

And DSNs are effectively required to contain at least a portion of
the rejected message. (There's an exception for DSNs generated by
gateways to foreign mail systems, but it clearly doesn't apply here.)

Like it or not, these DSNs are "messages sent on [the users] behalf", and
they absolutely do contain part or all of the rejected message.

> So as discovered above, we're talking past each other. I just want to keep a
> copy of the rejection that was sent out by sieve on the user's behalf.

And such messages can and often do contain part or all of the original
message, creating exactly the issue I've been talking about.

				Ned