Re: [sieve] On "reject" and :fcc Tue, 17 January 2017 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85F57129516 for <>; Tue, 17 Jan 2017 15:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.101
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lTQeuBQo6N72 for <>; Tue, 17 Jan 2017 15:17:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C530129444 for <>; Tue, 17 Jan 2017 15:17:14 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Tue, 17 Jan 2017 15:12:11 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for; Tue, 17 Jan 2017 15:12:09 -0800 (PST)
Message-id: <>
Date: Tue, 17 Jan 2017 15:04:23 -0800 (PST)
In-reply-to: "Your message dated Wed, 18 Jan 2017 09:17:39 +1100" <>
References: <>
To: Bron Gondwana <>
Archived-At: <>
Subject: Re: [sieve] On "reject" and :fcc
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIEVE Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jan 2017 23:17:15 -0000

> I wasn't on the list until just now, but it's one of my users who requested :fcc or similar.

> > > A vendor that uses Cyrus IMAP has some customers that would like to have
> > > copies of outgoing Sieve-generated messages (e.g. reject, vacation)
> > > stored in their Sent mailbox.  We could obviously do this with a user
> > > configurable option, but I was thinking of extending Sieve to support a
> > > :fcc <mailbox> option on reject, vacation and any new actions where it
> > > might apply.  The option could also leverage
> > > draft-bosch-sieve-special-use to do something like :fcc "\\Sent"

> > I see no problem for notify or vacation, but there's a serious semantics issue
> > with reject - when you reject a message you are saying, "I didn't receive" this
> > message". If you implement an action where you do in fact receive the message,
> > albeit as a part of a DSN, you're essentially lying about what you did.
> >
> > Accurate information about who actually received what is especially important
> > in environments with compliance archiving requirements. I don't look forward to
> > explaining how a reject ended up being a keep.
> >
> > 				Ned

> So don't lie if you don't want to lie.

No, you don't lie because you care about user experience, not violating
the least astonishment principle, etc.

> I see things the other way around, if you want to
> reject something then you want to reject it, but you might also want to keep a copy
> of every email that's been sent out of the system on your behalf.

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.

> If your environment has compliance archiving requirements, then don't let users do
> that.  If you're not allowed to keep copies of reject emails, then don't keep a copy of
> them.

> It's quite possible to set up an environment where every email going out of the organisation
> gets archived completely independent of the sieve engine, in which case you'd still be keeping
> copies of outbound rejects.  Not even allowing this in sieve doesn't change the fact that people
> might want to lie and not everybody has compliance archiving requirements.

You're now conflating all sorts of different things: Informing users of
rejections as opposed to revealing message content, outgoing rejections, which
have absolutely nothing to do with the matter at hand, and retaining messages
at the system level, which again has nothing to do with what's being
proposed here.

The issue here is simple: The :fcc mechanism on reject provides a way for your
*users* to lie to other *users* and say that they haven't received a message
when in fact they have. If you don't see how this can become extremely
problematic, I'm afraid there's no point in further discussion.