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

[Ned Freed <[e-mail]>]

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

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

> I guess
> the other option would be to not copy it anywhere (and file an error message to
> 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
> 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.

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