Sieve Extension: File Carbon Copy (FCC)
draft-ietf-extra-sieve-fcc-09

Note: This ballot was opened for revision 08 and is now closed.

(Ben Campbell) (was Discuss) Yes

Comment (2019-01-11 for -08)
I am clearing my DISCUSS, since conversation seems to be going in the right direction. I've included the DISCUSS text below for documentation purposes.

<old-discuss>
The security considerations say that this extension adds no new considerations not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not sure that that is true. 

It seems like the ability to insert a copy of message into a mailbox might have security and/or privacy considerations. This seems analogous to the "fileinto" action. I looked for security considerations for that in RFC 5228. All I found was a statement that "fileinfo" can be dangerous, but no elaboration on the nature of the danger or how it might be mitigated. So while I agree that fcc would have similar considerations as "fileinfo", I'm not sure those considerations have been adequately documented.  (I expect people will point me to something I missed, or where some other analogous feature is documented, in which case I will clear.)

</old-discuss>


§1, last paragraph (nit): Should "each action" be "each new action"?

§3.2, construction for FCC-OPTS: There is no extension point among the options, which would seem to require any new options update this RFC. Would it be reasonable to add one?

Alexey Melnikov Yes

Adam Roach Yes

Comment (2019-01-09 for -08)
Thanks for the work everyone did on this document. The mechanism seems quite
useful. I have some minor suggestions that you may want to consider
incorporating.

I support Ben's discuss.

---------------------------------------------------------------------------

§1:

>  This extension defines a new optional tagged argument ":fcc" to
>  action commands which generate additional messages to allow a copy of

Nit: "...commands that generate..."

---------------------------------------------------------------------------

§3:

>  alters the behavior of action commands which generate additional

Nit: "...commands that generate..."

---------------------------------------------------------------------------

§3.2:

>  FCC         = ":fcc" string *FCC-OPTS
>                  ; per Section 2.6.2 of RFC5228,
>                  ; the tagged arguments in FCC may appear in any order


This threw me for a bit of a loop when I got to the example in section 5, and I
had to go carefully read RFC 5228 to figure out what was going on. I think this
would be much clearer and more accurate if the rule were described as:

>  FCC         = *FCC-OPTS ":fcc" string *FCC-OPTS

---------------------------------------------------------------------------

General:

I'm a little concerned about the fact that this extension is generating a
new message and attempting to store it into a potentially quota-controlled
user folder. This would seem to be a run-time error, about which RFC 5228
says:

>  When an error happens, implementations MUST notify the user that an
>  error occurred and which actions (if any) were taken, and do an
>  implicit keep.

This probably isn't the right behavior for FCC. I think a sentence or two of
guidance about what happens when an FCC action would put the destination
mailbox over quota are in order, particularly since they'll be different than
the guidance in the base SIEVE spec.

I might just be confused here -- corrections to any incorrect notions I've
expressed would be appreciated.

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2019-01-09 for -08)
I support Ben's Discuss.  I also have some other comments.

Section 1

   Each action that generates additional messages will need to specify
   how it interfacts with :fcc.  [...]

Do we need to Update: 5228 so that authors of such future actions are aware
of this requirement?

                         The syntax and semantics of the mailbox
   argument MUST match those of the mailbox argument to the "fileinto"
   action specified in Section 4.1 of [RFC5228].  If the specified
   mailbox doesn't exist, the implementation MUST file the message into
   the user's main mailbox (e.g.  IMAP "INBOX").

It's unclear that the "syntax and semantics MUST match" needs the 2119
MUST; it could just be "are defined to match".  (Except they don't, since
we add on the extra condition that a nonexistant mailbox name be delivered
to the no-longer-implementation-defined INBOX folder instead of the other
MAY options for fileinto.)

Section 3.1

                  Tagged arguments in future extensions to the
   "fileinto" action should describe their interaction with ":fcc", if
   any.

This is not a very strong statement.  What would an implementor be expected
to do upon encountering such future extensions that do not describe
interaction with :fcc?  (This requirement may also be a candidate for an
Updates: relationship with 5228.)

Section 3.1.2

Perhaps note that implementations are permitted but not required to create
the mailbox (if needed) without this extension.

Section 3.1.3

It's a bit odd to update the behavior of another document that's still an
I-D (vs. specifying the behavior in question in that document).

Section 5

   Usage:   vacation [FCC]
                     [":days" number | ":seconds" number]
                     [":subject" string]
                     [":from" string]
                     [":addresses" string-list]
                     [":mime"]
                     [":handle" string]
                     <reason: string>

This is presumably just my having skimmed RFC 5228 too quickly, but why is
this [FCC] instead of [":fcc" string]" or similar?
(Same for the notify action in Section 6.)

Section 7

Do we want to have a list of currently defined actions that are not
compatible with the "fcc" extension, to avoid any confusion by future
readers as to what was defined at the time of this writing?

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2019-01-07 for -08)
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.

(Terry Manderson) No Objection

(Eric Rescorla) No Objection

Comment (2019-01-06 for -08)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3898



IMPORTANT
S 3.
>      copy of the generated message into the mailbox provided in the
>      subsequent argument.  The syntax and semantics of the mailbox
>      argument MUST match those of the mailbox argument to the "fileinto"
>      action specified in Section 4.1 of [RFC5228].  If the specified
>      mailbox doesn't exist, the implementation MUST file the message into
>      the user's main mailbox (e.g.  IMAP "INBOX").

This seems to sort of conflict with S 3.1.1. I assume that the logic
is: if (!exists && :create) { try_to_create() }; if (!exists) {
file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't
celar.

COMMENTS
S 1.
>   
>      The capability string associated with this extension is "fcc".
>   
>      Each action that generates additional messages will need to specify
>      how it interfacts with :fcc.  This document specifies the interaction
>      of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions.

Are these the only such actions?

Alvaro Retana No Objection

Martin Vigoureux No Objection