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

From: Bron Gondwana <[email-masked]>
Date: Wed, 18 Jan 2017 09:17:39 +1100

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

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.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: [email-masked]
Date: Tue, 17 Jan 2017 15:04:23 -0800 (PST)

> 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

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.

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

				Ned

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 18 Jan 2017 10:29:08 +1100

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

> problematic, I'm afraid there's no point in further discussion.

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.

-- 
  Bron Gondwana
  [email-masked]

---

From: [email-masked]
Date: Tue, 17 Jan 2017 15:43:47 -0800 (PST)

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 18 Jan 2017 11:21:21 +1100

> message, creating exactly the issue I've been talking about.

So we're back to this then.  Do you also object to websites saying "404 not found"
while still logging the fact that you tried to look at a resource?

Sometimes you want to keep the junk that was sent to you while saying to the
sender that nobody got that message.  Making that hard within the standard will
just cause people to work around it by doing things like capturing all mail that
hits the MXes before sieve processes it.  Not providing a facility because it can be
used to lie doesn't change that.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: [email-masked]
Date: Tue, 17 Jan 2017 16:24:12 -0800 (PST)

> So we're back to this then.

This has been the issue from the start.

> Do you also object to websites saying "404 not found"

Nope. But the situations are not remotely comparable. No users involved, just
for starters.

> used to lie doesn't change that.

As I said before, if you really think it's perfectly OK to provide a mechanism
to your users that allows them to instruct the system to lie in an offical
system message about them not having gotten the content of a mail message, then
we have nothing further to talk about.

				Ned

---

From: Sebastian Hagedorn <[email-masked]>
Date: Wed, 18 Jan 2017 10:06:03 +0100

--On 17. Januar 2017 um 16:24:12 -0800 [email-masked] 
wrote:

>> Sometimes you want to keep the junk that was sent to you while saying to
>> the sender that nobody got that message.  Making that hard within the
>> standard will just cause people to work around it by doing things like
>> capturing all mail that hits the MXes before sieve processes it.  Not
>> providing a facility because it can be used to lie doesn't change that.
>
> As I said before, if you really think it's perfectly OK to provide a
> mechanism to your users that allows them to instruct the system to lie in
> an offical system message about them not having gotten the content of a
> mail message, then we have nothing further to talk about.

For the record, I agree with Bron on this. It's up to the users if they 
want to lie.
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 18 Jan 2017 07:07:38 -0500

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.

On 01/18/2017 04:06 AM, Sebastian Hagedorn wrote:
>
> --On 17. Januar 2017 um 16:24:12 -0800 
> [email-masked] wrote:
>
> For the record, I agree with Bron on this. It's up to the users if 
> they want to lie.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: [email-masked]
Date: Wed, 18 Jan 2017 07:23:46 -0800 (PST)

> 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

---

From: [email-masked]
Date: Wed, 18 Jan 2017 07:36:26 -0800 (PST)

> For the record, I agree with Bron on this. It's up to the users if they

I have no problem with users lying to other users. I have a big problem with
them being able to trick the system into lying on their behalf.

				Ned