Re: On "reject" and :fcc

On Wed, 18 Jan 2017, at 10:04, Ned Freed wrote:
> > 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.

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.


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

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 protected]

_______________________________________________
sieve mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sieve