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

Ned Freed <ned.freed@mrochek.com> Mon, 07 January 2019 18:27 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BE412785F; Mon, 7 Jan 2019 10:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgmmRlpeNk96; Mon, 7 Jan 2019 10:27:04 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3841112426E; Mon, 7 Jan 2019 10:27:04 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1Q6T4PHGW00DH2Z@mauve.mrochek.com>; Mon, 7 Jan 2019 10:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546885319; bh=iS9Z5TbpEkWfqy61iT1oZ4t/ys8hpD7E9pNDwkQuCjQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=R4wCYFpLzE/JguUCNO+aA+DoMYqXJvVU1GKwm0sm6FSSRThZZNHbr7msjrvVsB6ag zVBZssZpkmSvwvhxJRLxsHZ64X93/0LAxJZRMwc32lwKZAWU5wv9WxkUXyTCuimKnn Gh/8LaM4Y3hDbJH/bvuHgC8T1zptWjmEBrjYqoRo=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Mon, 7 Jan 2019 10:21:54 -0800 (PST)
Cc: The IESG <iesg@ietf.org>, extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org
Message-id: <01R1Q6T33BRA00004L@mauve.mrochek.com>
Date: Mon, 07 Jan 2019 09:08:11 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 07 Jan 2019 05:15:31 -0800" <154686693163.23232.15216204981970430299.idtracker@ietfa.amsl.com>
References: <154686693163.23232.15216204981970430299.idtracker@ietfa.amsl.com>
To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Xe9AXqvc2CcOP3ibdtnaWOj2yzk>
Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-sieve-fcc-08=3A_=28with_COMMENT=29?=
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 18:27:06 -0000

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