Re: [Extra] Sieve REJECT and :fcc [was Re: Meeting minutes and notes from today]

[Stan Kalisch <[e-mail]>]

> On Jan 4, 2018, at 4:33 PM, Arnt Gulbrandsen <[e-mail]> wrote:
> 
> Stan Kalisch writes:
>> Perhaps, but, after all, reject already provides that facility.

I should have been more precise and said "can accommodate" that facility.  As RFC 5429 says:

"Making "reject" compatible with actions that cause mail delivery violates the RFC 5321 [SMTP] principle that a message is either delivered or bounced back to the sender.  So bouncing a message back (rejecting) and delivering it will make the sender believe that the message was not delivered.

"However, there are existing laws requiring certain organizations to archive all received messages, even the rejected ones.  Also, it can be quite useful to save copies of rejected messages for later analysis."

>> But that's not the central point of my argument in favor of allowing reject to invoke :fcc.
>> 
>> Some users have arguably (at least, certainly morally) legitimate reasons to lie about the delivery of mail.
> 
> You can also argue that software has a duty to serve its user.
> 
> If the user wants to send mail claiming that 2+2=7 on Tuesdays, that the check is in the mail, or that he/she hadn't received that other mail, that's the user's business. The software's duty is to serve its master.
> 
> (But as I said in another message, sieve may serve two masters, and even if the software will loyally lie in the name of one master, that doesn't mean one of the masters should be able to force the software to lie in the name of the other.)

And as reject already minimally allows a user to do that (lie about the reason a message was rejected), this sounds to me like something that should be left to the discretion of an administrator.  For some systems, the administrator is going to want to give primacy to the user's privacy; for others, the administrator is going to desire to give primacy to accountability to some entity or organization.  To me, this seems like a fair trade-off.  I do concede that's not entirely consistent with RFC 5429's language about archiving leaving the decision up to the "implementation" and that that's something that has to be considered.


Thanks,
Stan