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

[Ned Freed <[e-mail]>]

> On Jan 4, 2018, at 10:17 AM, Ned Freed <[e-mail]> wrote:

> >>> On Fri, 17 Nov 2017, at 09:06, Stan Kalisch wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Nov 15, 2017, at 3:30 AM, Bron Gondwana
> >>> <[e-mail]> 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.

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.)

There are all sorts of ways information can leak and getting this wrong in
matters of life and death is completely unacceptable. (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. And a badly implemented system of this sort could cause
exactly the harm it was trying to prevent.

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.

> 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.

> 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.

				Ned