Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT)

[Eric Burger <[e-mail]>]

inline

On Jun 25, 2014, at 11:58 AM, Alissa Cooper <[e-mail]> wrote:

> Hi all,
> 
> Top posting to try to assemble a response to all the recent messages here.
> 
> I took Stephan’s text and some observations from the thread and put this
> text together for Section 6:
> 
> "The list of unique IDs used for duplicate tracking can include
> privacy-sensitive information, such as Message-ID values, content of
> subject lines, and content extracted from message bodies. Implementations
> SHOULD protect that information, by obscuring it through hashing (see the
> note at the end of Section 3.2) and/or by storing it with a level of
> access control equivalent to that of the messages themselves.

SHOULD…. unless what? SHOULD without ‘unless’ = MAY = don’t bother.

> These measures will not prevent an entity that has access to the duplicate
> tracking list from querying whether messages with certain Message-ID
> values were received. As this operation is the essence of the "duplicate"
> test, this cannot be prevented, and may violate the expectations of the
> user. For example, a user who downloads or deletes a message may expect
> that no record of it remains on the server, but that will not be true if
> its Message-ID is persisted on the server in the duplicate tracking list.

Really? Let’s take the case of the US. I think the Lois Lerner affair will make the 12 people who didn’t know that a deleted email is not gone aware that deleted emails are not gone. If we care about that, let’s write a BCP that says a sending system SHOULD delete all copies of sent messages, because the recipient has an expectation that if they delete a message, ALL copies of the message go away.

If we are trying to protect the privacy of a person who has no expectation of privacy, are we protecting anything?

> It's notable, however, that server logs will often store the information
> present on the duplicate tracking list anyway, and probably would expose
> plaintext Message-IDs for a much longer period than this mechanism would.
> Users of email services that intentionally delete such logs with the
> intent of limiting traceability should be made aware that use of the
> duplicate tracking mechanism re-exposes this information for the duration
> of the expiry interval.

That’s nice, but how? I am glad the language does not move us from the protocol police into the implementation police.

> In those situations, a shorter default expiry may
> also be appropriate since users of these services may be willing to trade
> off a more limited retention of the duplicate tracking list information
> against the fact that every duplicate will not necessarily be eliminated
> with a shorter expiry."
> 
> What do you think?

I think Joe Average will have no clue what we are talking about. Joe Average wonders why he gets multiple copies of the same email. Joe Average will be really mystified if he thinks he is getting a service that will stop those duplicates and yet he still gets them. Also, consider the hypothetical user from two paragraphs ago who delusionally thinks that deleting an email makes it go away. They will freak out when it shows up again.

This line of reasoning is why if you really care about such issues, you will not trust your email processing to a service provider. You will do everything at the edge. If you do trust your email processing to a service provider… you trust your email processing to the service provider.

[snip]