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

On Jan 4, 2018, at 10:17 AM, Ned Freed <ned.freed@mrochek.com> wrote:

>>> On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote:
>>> 
>>> Hi,
>>> 
>>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana
>>> <brong@fastmailteam.com> wrote:>> *There is an open question for this one:*
>>>> 
>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/
>>>> 
>>>> Ned Freed objected to supporting :fcc for the REJECT action because
>>>> it allows the sieve server to "lie" about whether it's keeping a copy
>>>> of the message.  There was debate about whether we should stop people
>>>> lying at this level, especially since a mail flow could take a copy
>>>> of every single email before it reached sieve.>
> 
> That's true but beside the point. Making service-level copies of messages is
> one thing, giving users a direct way to conveniently say "I didn't get this
> message" when they actually did is quite another.

Perhaps, but, after all, reject already provides that facility.  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.  The users who first come to my mind are survivors of domestic violence and/or sexual assault.  Google surely had in mind stalking and harassment when it provided Google Voice a mechanism to lie about whether or not someone had placed a call to a user's valid phone number.  Granted, backscatter, MDN, DSN, etc., of course, aren't even peripheral considerations in rolling out something like that for phone calls.  But, again, we're only talking about :fcc; reject's ship has already sailed.

I acknowledge your point that "delivery failed" is conspicuous by virtue of the fact that it is missing from RFC 8098.  And I can't say that this gives me no pause of any kind.  But it still seems to me, when you look at both the technical and very real human considerations, that this effort is more trouble than it's worth—I'm having a hard time believing adding :fcc to reject is substantially going to increase reject's (mis)use.  So this strikes me as something that, in effect, merely serves as a lecture to users who may lie, but 1) are not necessarily sanguine or happy about lying, and 2) may actually have the need to lie.  That is a scenario that is not implausible at all.  It is a privacy issue.  I don't want to *encourage* users to lie, but, on the other hand, I don't think the technical arguments are strong enough for the IETF to dictate that a language does or does not deal with such problems.  That should really be entrusted to users and administrators.  Some things, in the end, have to be entrusted to the community.

Thanks,
Stan

>>> I haven't been able to watch any video of the meeting yet, but would
>>> it be fair to say the main points of this debate were laid out in this
>>> thread on the Sieve mailing list earlier this year?>
>>> https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html
> 
> I would have thought so, but since the point that service-level
> copying of messages made above is still deemed relevant, apparently not.
> 
>> I don't know if this was ever resolved.  I prefer the user to be allowed
>> to lie, Ned objects to that.
> 
> Very strongly.
> 
>> I don't actually care that much though, so
>> I'm happy to say no :fcc on REJECT.  It's not like I would actually use
>> it because sieve REJECT is bad anyway, it creates backscatter.
> 
> Not if it's properly implemented around delivery time and at the SMTP level.
> (LMTP level is too late.) Perhap this is the key point - it's one thing to
> cause a DSN to be sent saying "this message was never delivered" when in fact
> it was. It's quite another to send a MDN saying "I threw this message away."
> 
> The latter carries no implication the message wasn't read and the content
> possibly retained by the user in some way. The former does carry such an
> implication.
> 
> And sure enough, if you check RFC 8098 you'll find that the disposition types
> allowed in an MDN are "displayed", "deleted", "dispatched", and "processed". 
> (If the sieve reject action uses an MDN it's required to set the type to
> "deleted".) "delivery failed" is conspicuous by it's absence.
> 
>> So Ken - I'm happy to go ahead with "not supported on reject".
> 
> The alternative is to require an MDN be used in this case. Which of course
> creates a possible source of backscatter.
> 
>> The other open issue was separate capability string.  I don't think
>> that's necessary, and nobody else seems to have commented on it.
> 
> Certainly not if :fcc only applies to vacation. However, if it applies
> to reject in a way that forces that extension to behave in a way some
> people find undesirable, things get a little more tricky.
> 
>> I've created one task for each:
> 
>> https://github.com/ietfextra/tracking/issues/14
>> https://github.com/ietfextra/tracking/issues/15
> 
> Can you apply :fcc to a notify action that generates an email message? If
> not why not?
> 
> And for that matter, can you apply :fcc to a notify action that generates some
> other kind of notification that could be mapped to an email?
> 
>            Ned
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra