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

[Bron Gondwana <[e-mail]>]

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

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
  [e-mail]