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

[Ned Freed <[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.

I'm not. The situation after delivery is entirely different. Once something
is delivered to a user's mailbox the transport system is no longer involved.

Everything about MDNs is discretionary: generation, content, everything.  Users
and their agents are free to say or do whatever they want. They can send a
"deleted" MDN and keep the message, or send a "dispatched" MDN when in fact
they simply deleted the message.
 
> Users can in fact lie about the reason a message triggers, say, a MDN.

Absolutely. This is expected to be the case. Of course senders can elect to
trust a sender, but if they do this is an arrangement that lies outside the
service architecture the mail system provides.

The transport infrastructure is a different story. We all have to trust it,
and there are enough issues with that already; we should not be adding more.

> Given that Sieve was designed to act on messages upon delivery,

Sorry, that's incorrect. Sieve was designed to operate at some point
around the time of delivery. There are implementations that operate
before, during, or after delivery.

In the specific case of reject, a user agent needs to use MDNs since the
time for the generation of DSNs is past. Something operating at the SMTP
server level should use SMTP status codes if at all possible - and the
specification goes to considerable trouble to make that possible.

This is further complicated by there being two verbs (reject/ereject),
which further complicates matters.

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

FWIW, our implementation operates at the SMTP server level and uses SMTP
status codes whenever possible. 

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

First, such usage is NOT RECOMMENDED, meaning it should only be done if there's
a really good reason. Second, as the RFC points out, doing this at the SMTP
level is a direct violation of RFC 5321. Call me a stickler if you like, but I
don't think that's a good thing.

Third, it seems clear that the presence of all this text in the RFC is in a
misguided attempt to try and make sieve actions like keep and fileinto somewhat
compatible with legal intercept applications. Unfortunately the entire cant of
Sieve is such that this is basically a fool's journey in user-space sieves, and
as I have pointed out previously, system sieves are beyond the scope of what's
covered in the RFCs.

>  and that reject essentially carries a minimal ability to
> lie about why a message's disposition has ended up the way it has.

This is a result of the range of places where Sieve can be applied. What's
appropriate prior to delivery is different from what's appropriate after
delivery.

				Ned