Subject: Privicons and redaction
From: Alessandro Vesely <[email-masked]>
To: Ulrich Koenig <[email-masked]>, Jan Schallaboeck <[email-masked]>
Cc: RFC822 <[email-masked]>
Date: Fri, 09 Dec 2011 13:18:22 +0100
List-Id: <ietf-822.imc.org>

In abuse reporting, an established albeit discouraged practice
consists of redacting reported messages.  In a nutshell, users may
have the ability to signal some received messages as being abusive.
Their mailbox providers should then wrap those messages according to
abuse reporting format (ARF, RFC 5965) and send them back to the
senders if they had subscribed to the relevant feedback loop.  See
http://en.wikipedia.org/wiki/Feedback_loop_%28email%29

Redaction conceals the recipient, rather than the sender.  In this
case, authors should markup the parts of the messages that contain
sensible data, in case the recipients report those messages as spam,
possibly inadvertently.  A document describing how to carry out
redaction is now in LC, so it can hardly mention privicons.  However,
privicons could consider this possible use.  The redaction doc is at
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/

For casual readers, privicons are defined here:
http://tools.ietf.org/html/draft-koenig-privicons

Date: Mon, 5 Dec 2011 12:54:06 -0800
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
CC: Ulrich Koenig <[email-masked]>, Jan Schallaboeck <[email-masked]>
Subject: draft-koenig-privicons-03.txt
Sender: [email-masked]

My comments on "Privacy Preferences for E-Mail Messages"

> 1.  Introduction
> 
> 1.1.  Overview
   .
   .
   .
>    This document proposes a syntax (Section 2) and semantics (Section 3)
>    allowing a Sending User of an e-mail message to express his or her
>    preference for how the e-mail message content should be handled by
>    the Receiving Users.  For this purpose, semantics of sets of
>    different character combinations ("Privicons") are described.  These
>    can syntactically be integrated either in the first-line of the body,
>    in the subject line and/or in a dedicated header of any e-mail
>    message.  The Privicons icon set has six different icons.  They will
>    be machine-readable.

It would be more correct to use the term "header field" rather 
than "header" here and in the rest of the document.
   .
   .
   .

> 1.3.  Terminology and Conventions
   .
   .
   .
>    o  The terms "Sending User" and "Receiving User" are related to a
>       user using the User Agent either sending or receiving an e-mail
>       message.  A Sending User is a user that sends an e-mail message to
>       a Receiving User.  A Receiving User is a user that receives an
>       e-mail message from a Sending User.

The definition of Sending User needs to be clarified: is it the 
email-address from the Sender: header field? Or one or more of 
the email-address from the From: header field?
   .
   .
   .
> 2.  Syntax
   .
   .
   .
>    o  MUST contain a header (Section 2.4) with Privacy Preferences,

This "MUST" seems to conflict with the MAY later in this spec.
   .
   .
   .
> 2.1.  Definitions
> 
>    element1 | element2  Elements separated by a bar ("|") are
>       alternatives, e.g., "yes | no" will accept yes or no.
> 
>    "literal"  Quotation marks surround literal text.  Unless stated
>       otherwise, the text is case-insensitive.
> 
>    whitespace  " "
> 
>    whatever  Some arbitrary text.
> 
>    date  Will be substituted by a "full-date", [RFC3339].
> 
>    privicon  =
>       ("[X]"|"[/]"|"[=]"|"[=0]"|"[=I]"|"[=date]"|"[-]"|"[o]"|"[>]") -
>       the Privicon token.  It contains all valid Privicons, the Privicon
>       icon set.
> 
>    I  I will be substituted by an integer number >= 0.
> 
>    description  Contains the description of the Privicon as defined in
>       Semantics (Section 3).
> 
>    subject  Is the e-mail message subject field, see [RFC5322].
> 
>    CRLF  Is the carriage return/line feed pair written in this document
>       as "CRLF".  A line is a series of characters that is delimited
>       with the two characters carriage-return and line-feed; that is,
>       the carriage return (CR) character (ASCII value 13) followed
>       immediately by the line feed (LF) character (ASCII value 10), as
>       described in section2.1 in [RFC5322]

These definitions need to be formatted to more clearly 
distinguish the term from its definition. Perhaps like the 
"privicon" definition.

> 2.2.  First-Line(s) of Message body
> 
>    An indication of the Privacy Preference can be given in the first
>    line of the body of an e-mail message.

The definition of "first line" is not at all clear except for a 
TEXT/PLAIN body.

In the case of a TEXT/HTML body, the intent seems to be that the 
first line is the topmost "line" visible to the Receiving User. 
However, since the "first line" privicon is the determining 
specification in the case of disagreements and the MUA is 
expected to "enforce" this, the MUA must be able to *find* the 
privicon. This could be difficult for the MUA with sophisticated 
HTML code.

For bodies such as IMAGE/*, AUDIO/*, VIDEO/*, MODEL/*, or 
APPLICATION/* how is the "first line" to be found?

In the case of a MESSAGE/* the first line would be part of the 
embedded message's header and would probably cause a parse error.

In the case of MULTIPART/MIXED the first line would presumably be 
the "first line" of whatever the first embedded part is. And in 
the case of MULTIPART/ALTERNATIVE the first line would have to be 
the "first line" of each embedded version with a method of 
resolving conflicts there, too.

The remaining MULTIPART/* type bodies would have similar issues.

> 
>    The expression MUST be followed by a text giving a short explanation
>    the meaning of the expressions.  It is RECOMMENDED to use the
>    following text, although localization into other languages is also
>    encouraged, albeit not lined out in this document.

The use of MUST here without specifying the required text is 
unenforceable and is better expressed with a SHOULD.
   .
   .
   .
> 2.4.  Header
> 
>    An indication of the Privacy Preference MAY be given in the header of
>    an e-mail message, for this purpose the following field is defined,
>    extending in section 3.6 in [RFC5322] the field definition, thereof.

As mentioned above this MAY conflicts with the MUST earlier in the spec.

> 
>    priviconfield  = "Privicon:" whitespace privicon CRLF

I find the requirement of a single space character following the 
colon to be objectionable, this is not Usenet! There should also 
be provision for a comment or explanatory text following the 
privicon.
   .
   .
   .
> 2.5.  Footer
> 
>    Separated by --
> 
>    The Footer MAY be located within the signature as described in
>    section 4.3 in [RFC3676] .  It contains a paragraph that describes
>    what the Sending User of the e-mail message intended when she chooses
>    the selected Privicon.
> 
>    A clarification MAY be added that a conflict between header and
>    first-line would lead to the first-line to be authoritative.

The preceding paragraph seems out of place.

> 
>    footer  = CRLF "-- " CRLF footertext
> 
>    footertext  = firstLine CRLF description
> 
>    For example:
> 
>       --
> 
>       [X] - Keep private
> 
>       The "Keep secret" Privicon asks the Receiving User to keep the
>       received e-mail message secret.

This example seems to imply that the "firstLine" is the first 
non-blank line, does this also apply to the body "first line"?

> 
>    Note: Footnote may violates [RFC1855] Page4 - do not use more than 4
>    lines signature.
> 
>    The Footnote is just informative not authoritative

By "Footnote" here do you mean "Footer"?
   .
   .
   .
> 3.  Semantics
   .
   .
   .
> 3.1.2.  [/] Don't print
> 
>    The "Don't print" Privicon asks the Receiving User to not print the
>    received e-mail message.

It is not clear what privacy issue is being addressed with the 
"Don't print" privicon. If the Receiving User can more easily 
keep a message private by printing it, locking it in a safe, and 
deleting the electonic copy, why would the Sending User object?

What danger does the Sending User prevent with this option?
   .
   .
   .
> 3.2.  Multiple Privicons
> 
>    Possible:  Y
> 
>    Impossible:  N
> 
>    Does not apply:  X
> 
>    As secondary option, potentially, and if first preference is
>    overruled:

The preceding paragraph is not clear. Do the privicons "OR" 
together or replace the first with the second under some 
conditions?

> 
>                 +-----+-----+-----+-----+-----+-----+-----+
>                 |     | [X] | [/] | [=] | [-] | [o] | [>] |
>                 +-----+-----+-----+-----+-----+-----+-----+
>                 | [X] |  X  |  Y  |  Y  |  N  |  N  |  N  |
>                 | [/] |  Y  |  X  |  Y  |  Y  |  Y  |  Y  |
>                 | [=] |  Y  |  Y  |  X  |  Y  |  Y  |  N  |
>                 | [-] |  N  |  Y  |  Y  |  X  |  Y  |  Y  |
>                 | [o] |  N  |  N  |  Y  |  Y  |  X  |  N  |
>                 | [>] |  N  |  Y  |  N  |  Y  |  N  |  X  |
>                 +-----+-----+-----+-----+-----+-----+-----+
> 
>              Table 1: Matrix of all combinations of Privicons.

This table is not symmetrical, so which is the first privicon and 
which is the second? Otherwise, explain why [/] and [o] cannot be in 
either order.
   .
   .
   .
> 4.  IANA Considerations
> 
>    This document introduces a new field in the e-mail header, as
>    described in the header (Section 2.4) section.

The first use of the word "header" in the preceding paragraph is 
correct, but the second is not!
   .
   .
   .
> Appendix A.  Example e-mail message
> 
>    This is an example Privicon e-mail message (Figure 1).
> 
>      Message-ID: <[email-masked]>
>      Date: Mon, 05 Jul 2010 23:59:00 +0200
>      From: Ulrich Koenig <[email-masked]>
>      To: Jan Schallaboeck <[email-masked]>
>      Subject: [>] last update for Privicons RFC
>      Privicon: [>]
>      Content-Type: text/plain; charset=ISO-8859-15
>      Content-Transfer-Encoding: quoted-printable
>      [>] Please share
> 
>      Hey Jan,
> 
>      please check the IETF Website for our Privicons RFC! ;)
> 
>      best Ulrich
> 
>      --=20
>      [>] Please share
>      The "Please share" Privicon asks the Receiving User to share this
>      e-mail message with everyone she likes.
> 
>           Figure 1: Example of an e-mail message using a Privicon

This example places the (presumably first body line) privicon as 
part of the message header and thus will cause a syntax error and 
likely make the privicon invisible to the Receiving User.
   .
   .
   .
> B.1.  User agent behaviour
> 
>    This section gives developers of e-mail message user agents (MUA) or
>    plug-ins for MUAs instructions how to integrate the Privicons in the
>    client.
> 
>    An MUA implementing this RFC MUST enable the user at any time to
>    overrule the received Privicon.  The user SHOULD also be able to set
>    a default for always overruling in her client.  The rest of the
>    instructions in this section are OPTIONAL.

If the following instructions are OPTIONAL, the use of 12 "MUST"s 
in them is hard to justify.
   .
   .
   .
> B.1.2.  [X] Keep secret
> 
>    The "Keep private" Privicon asks the Receiving User to keep the
>    received e-mail message secret.
> 
> B.1.2.1.  EVENT: Forward/Reply to third Person
> 
>    If the Receiving User wants to forward or reply-to the e-mail message
>    to a third person, that is not the original Sending User, than the
>    Receiving User MUST be informed, that she is going to violate the
>    included Privicon and she MUST confirm that she is willing to do this
>    before the e-mail message is sent.

It seems to me that the list of *all* of the From: addresses, the 
Sender: address, and the To: addresses should be considered as 
non-third party addresses since they presumably are all aware of 
the message already.
   .
   .
   .
> B.1.4.  [=] Delete after reading, I days or on date
> 
> B.1.4.1.  EVENT: Closing Mail
> 
>    If the Receiving User closes the e-mail message, she MUST be
>    informed, that the e-mail message SHOULD be deleted after X days.
> 
>    The user MUST confirm whenever she closes the e-mail message, hat the
>    e-mail message is deleted immediately.

The preceding paragraph is not clear.
   .
   .
   .
> B.1.4.1.1.  Option a) delete after reading
> 
>    The above confirmation MUST ask the user, whether
> 
>    o  ignore, do not decide now, ask me again next time,
> 
>    o  delete or move into a "to be deleted" folder, as indicated in the
>       preferences or
> 
>    o  ask again after a specified period.

Where is the option to tell the MUA "Do NOT delete, and never 
bother me again."?

> 
> B.1.4.1.2.  Option b) delete after X days
> 
>    The above confirmation MUST ask the user, whether
> 
>    o  ignore, do not decide now, ask me again next time,
> 
>    o  delete now,
> 
>    o  delete after X days automatically or
> 
>    o  ask me in X days.

Where is the option to tell the MUA "Do NOT delete, and never 
bother me again."?

> B.1.4.1.3.  Option c) delete on date
> 
>    The above confirmation MUST ask the user, whether
> 
>    o  ignore, do not decide now, ask me again next time,
> 
>    o  delete now,
> 
>    o  delete on date automatically or
> 
>    o  ask me on date.

Where is the option to tell the MUA "Do NOT delete, and never 
bother me again."?

> 
> B.1.5.  [-] No attribution
> 
> B.1.5.1.  EVENT: reply, forward, store
> 
>    If the Receiving User wants to forward or reply to a third person or
>    store the e-mail message, she MUST be informed, that the Sending User
>    doesn't want to be mentioned and MUST confirm that she is willing to
>    overrule the Sending Users wish or remove any occurrence of the
>    Sending User in the e-mail message (Header and Body).  The removal of
>    the Sending User MAY be done by the user agent automatically.

Esactly how can the MUA determine in the *body* that the Sending 
User identity has been removed?
   .
   .
   .
> B.1.6.  [o] Keep internal
> 
>    If the Receiving User has defined what "internal" means to her, the
>    following rules in the "Keep internal" subsection only apply if at
>    least one of the Receiving Users are not part of her internal
>    definition.
> 
>    If the Receiving User wants to forward or reply the e-mail message to
>    a third person, the user MUST be informed that she SHOULD check if
>    the third person is really part of the group that the Sending User
>    intended to be internal and MUST confirm that she really to send this
>    e-mail message.

Should the Sending User and all Receiving Users be considered as 
added to "internal" automatically for the purposed of this reply 
of forward?
   .
   .
   .
> B.3.  Transparency (OPTIONAL)
> 
>    If a Receiving User forwards or replies an e-mail message containing
>    a Privicon to a third person, the original Sending User OPTIONAL get
>    a copy via carbon copy or a blind carbon copy by default.  The
>    Receiving User MUST be able overrule this.  She also SHOULD be able
>    to disable the default sending of a copy in the user preferences.

It may be appropriate to forward the privicons of the original 
message, optionally.

-- 
Bill McQuillan <[email-masked]>