[Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-extra-sieve-fcc-08: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the work on this. I plan to ballot "yes", but have one item I think
needs to be discussed first:

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


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

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