[Top] [All Lists]

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

2017-01-17 18:21:28
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 
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 
sent on their behalf.

When a Sieve ereject/reject occurs prior to delivery, and circumstances 
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 
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 Gondwana

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>