Subject: [Extra] Mirja Kühlewind's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 07 Jan 2019 05:15:31 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-extra-sieve-fcc-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have a minor comment on this sentence:

"If the specified
   mailbox doesn't exist, the implementation MUST file the message into
   the user's main mailbox (e.g.  IMAP "INBOX")."

Beside the conflict Ekr mentioned, I'm wondering why this is a MUST. I guess
the other option would be to not copy it anywhere (and file an error message to
the user). I'm not an expert on mail at all but as a user I would find it
confusing to find such messages in my INBOX. However, if there is a good reason
that it must be ensured that such a message is stored, I guess that's the only
viable default option.

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Jan 2019 09:08:11 -0800 (PST)

> Beside the conflict Ekr mentioned, I'm wondering why this is a MUST.

An argument can be made for a SHOULD. But some compliance language is in order
here.

> I guess
> the user).

First, let's be clear on who the "user" is here. The entities involved are (a)
the original message sender, (b) the original message recipient/sieve owner,
and (c) the recipient of the newly generated message we're making a copy of.

(a) and (c) may be the same (in the case of vacation) or different (in the
case of notify).

Reporting this sort of problem to the original message sender in all cases is
not only nonsensical, it's a privacy violation - the original sender has no
business seeing the notifications their message caused to be sent. So (a) is
out.

(c) is also nonsensical - the person receiving the notification neither knows
nor should be aware of additional copies made by the notification sender.

That leaves (b) - and given this is an :fcc the only place we are
sure to have for this error message to go is the sieve owner's mailbox.

That means an error report is going to take the form of another email message.
So we're talking about someone  receiving a message (in their INBOX) reporting
a problem delivering a notification message regarding yet another message to
some folder.

Dunno about you, but that certainly confuses me. And not to seem immodest, but
if it confuses me, I think it will confuse most people a lot more than
simply recieving the notification in the wrong place.

This is actually just a specific case of the more general rule that it's a bad
idea to have notifications generate notifications. We require the messages
generated by vacation and notify to have an empty MAIL FROM, meaning failure to
deliver those messages will not generate an error. I don't see a good argument
for deviating from this practive in this case.

> I'm not an expert on mail at all but as a user I would find it

Since the only other option is for this notification copy to silently
disappear, and presumably the person who wrote the Sieve clearly wants to keep
a record of the notifications they have sent, I think this needs to at least be
a SHOULD.

Beyond that, we require the same fallback to INBOX behavior  for Sieve
fileinto, and IME it hasn't been confusing. (And yes, it does happen.)

So there is precedent for this being a MUST. OTOH, we're talking about
notifications, and there is also precedent for dropping them on the floor.

Bottom line is I prefer a MUST but a SHOULD would be acceptable.

				Ned