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

[Stan Kalisch <[e-mail]>]

On Jan 7, 2018, at 8:42 AM, Ned Freed <[e-mail]> wrote:

>>> 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.
> 
> I object even more strongly to this justification for adding such a feature.
> 
> There are at least two problems here: We haven't even attempted to work through
> all the security implications of trying to hide delivery of email. (Rejection
> after delivery is another matter entirely, but we're not talking about that
> here.)

Actually, I'm talking about both.

Users can in fact lie about the reason a message triggers, say, a MDN.

> There are all sorts of ways information can leak and getting this wrong in
> matters of life and death is completely unacceptable.

I am not denying this and couldn't agree more.

> (You might start by
> thinking about the handling of multi-recipient cases and how you intend to
> maintain the privacy of bcc recipients while maintaining a consistent
> appearance of the DSNs you send back versus the ones you provide via :fcc.)
> 
> Additionally, even if we do all the work to specify this properly, do you think
> implementors will get it right? Past experiences says the chances of that are
> essentially nil.

My reaction to that is that implementors getting a spec right is *always* a concern of mine.

With regard to the issue of DSNs, I'll concede I'm not aware of what all Sieve implementations do and was somewhat surprised by the text about them in RFC 5429.  (This isn't a criticism; I know that people sometimes do experiments that specs have to attempt to address.)  I do know if I were to write an implementation that integrated DSNs, I would tiptoe toward it for many of the same reasons you describe.

Given that Sieve was designed to act on messages upon delivery, if enough implementors here in the WG aren't interested in the idea of even pursuing anything linking Sieve to DSNs, then it's not of the greatest concern to me if the MDN for :fcc on reject is made mandatory.

> And a badly implemented system of this sort could cause
> exactly the harm it was trying to prevent.

Of course.

> More generally, the business of mail interception for legal/law enforcment
> purposes should not be delegated to - let's face it - an obscure feature on an
> obscure extension.
> It's too important for that, and too important to get right.
> 
>> 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.
> 
> This would be more or less equivalent to an MSP providing the means to say
> "this is not a valid address" instead  of saying "you're not allowed to send to
> this address". Which Sieve reject provides, modulo the ability to use a
> 5.1.1 response versus a 5.7.x response code. (A feature our implementation
> provides for system-level sieves.)
> 
> However, a word of caution about side channel risks is once again in order.
> 5.1.1 no such user responses are typically given to RCPT TO; whereas Sieves
> responses come after the message has been transferred. So it may be  possible
> to tell when such a mechanism is used.
> 
> And let's please not entertain the notion that we can simply ignore
> side-channel attacks here.
> Not to put too fine a point on it, but it seems a
> bunch of Intel engineers thought that way back in the 90s, and look where we
> are now.

No, I think that's apropos.

>> 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 have no idea what this means.

Again, it's about the fact that reject can accommodate the ability to be used with fileinto, etc, and that reject essentially carries a minimal ability to lie about why a message's disposition has ended up the way it has.

>> 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 entru
>> to the community.
> 
> And again, I have no objection whatsoever to reject :fcc generating a "deleted"
> MDN response. But once again you have the side channel situation to consider -
> reject :fcc causing a different response than reject without :fcc also
> leaks information.

I haven't looked at Cyrus code in a while, but, presumably, the implementors behind this draft have considered such things.


Thanks,
Stan