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

[Bron Gondwana <[e-mail]>]

Is everybody OK with having fcc not include reject, and having a
separate capability (fcc-reject or similar) which administrators can
decide whether or not to allow - and indeed, software implementations
the choice whether or not to implement.
That fixes both issues - those who really want the ability to lie can do
so, but it's clear that they're enabling that facility, and it's also
possible for both software vendors and administrators to not provide the
facility in the first place.
Bron.


On Fri, 5 Jan 2018, at 10:34, Stan Kalisch wrote:
> 
>> 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
> 
> _________________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]