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

[Ned Freed <[e-mail]>]

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

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