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

From: "Alissa Cooper" <[email-masked]>
Date: Thu, 19 Jun 2014 17:40:41 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-appsawg-sieve-duplicate-07: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/

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

o Section 3.3: 
"A default expiration time of around 7 days is usually
   appropriate. ... If that limit is exceeded by the ":seconds" argument,
the
   maximum value MUST silently be substituted"

The suggested default seems really long, especially for the example use
case described in Section 1. On the other hand, it seems odd that the
user's choice would be overriden by the preset maximum. This would make
more sense to me if the default expiration were shorter and the user
could override it with a longer :seconds argument if he wanted. What is
the rationale for doing it the opposite way?

o Section 6: 
It seems like this section is missing a discussion of the privacy
considerations associated with enabling the duplicate test. In the case
where the Sieve filter is implemented server side, making use of the
duplicate test means that some record of the receipt of a particular
message will be persisted (for as long as specified by the logic in
Section 3.3) even if the user downloads his messages or deletes a
received message on the server that matches a test string in the
meantime. If I want to filter all messages with duplicate message IDs,
for example, this puts a
requirement on the server to maintain a list of the message IDs of all
messages I’ve received (for the amount of time specified by the timing
parameters). So if a third party wanted to find out that list, it could
go to the operator
of the server and ask for it. This introduces a privacy risk that is not
discussed in the document and is exacerbated by the long default
expiration time mentioned above. Tests that make use of the :header or
:uniqueid arguments are also potentially problematic since the list of
strings to match is kept on the server. It seems like these aspects
should at least be noted in the document for implementers to consider.

o Section 6: 
Sieve scripts that include duplicate tests contain potentially sensitive
information (e.g., subject or body strings). So it seems like the scripts
should be confidentiality protected in transit. I checked with Barry and
he said that there is no RFC that specifies if/when scripts should be
protected in transit, and I understand that this document is probably not
the right place to specify required behavior there, but I'd like to
discuss (more with the ADs than the authors) if there is some plan for
specifying that behavior somewhere. 

o Section 6: 
I think it would make sense to require that the tracked message list be
stored with an equivalent level of protection as the user's messages
themselves. E.g., if message headers and bodies are stored encrypted,
then the duplicate tracking list should be as well. And the duplicate
tracking list should be subject to the same access controls as the
mailbox (perhaps this is obvious but I'm not sure).

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

o Section 3.1:
"When the ":uniqueid" argument is used, such normalization
   concerns are the responsibility of the user."

I don't quite get this. Do we expect users to, e.g., specify that
uniqueid strings should only be compared after conversion to UTF-8? That
would seem to rely on a level of technical sophistication that almost no
users actually have.

o Section 3.2:
"This means that it does not matter whether values are
    obtained from the message ID header, from an arbitrary header
    specified using the ":header" argument or explicitly from the
    ":uniqueid" argument.

I had trouble understanding what "it does not matter" meant in this
sentence. I would suggest:

"This means that the values in the duplicate list should be used for
duplicate testing regardless of whether they were
   obtained from the message ID header, from an arbitrary header
   specified using the ":header" argument or explicitly from the
   ":uniqueid" argument."

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 20 Jun 2014 09:51:07 +0200

Hi Alissa,

> draft-ietf-appsawg-sieve-duplicate-07: Discuss

The default was chosen in Sieve mailing list discussions, but in essence
it is pretty arbitrary. It is mainly based on the period in which a
series of duplicate messages may arrive with a margin of a few more days.

The rationale for a maximum is to prevent users from having the ability
to create duplicate tracking list entries that linger indefinitely.

> mailbox (perhaps this is obvious but I'm not sure).

This is a very interesting point of view. I had not thought of privacy
concerns relating to the duplicate tracking list.

Probably, the main reason we have not considered this is that the
document states the following:

   NOTE: The necessary mechanism to track duplicate messages is very
   similar to the mechanism that is needed for tracking duplicate
   responses for the "vacation" [VACATION <http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-07#ref-VACATION>] action. One way to implement
   the necessary mechanism for the "duplicate" test is therefore to
   store a hash of the tracked unique ID and, if provided, the ":handle"
   argument.

There is no tractable way to reverse a hash into its original string
value, meaning that the entries in the duplicate tracking list would
have very little value for an attacker.

Of course, if implementations choose a different approach that uses
entries that can yield the original string values, there would be a real
concern. I propose adding a sentence or two pointing out that duplicate
tracking list entries should not contain the plain user strings for
privacy reasons, or, alternatively, that the tracked message list be
stored with an equivalent level of protection as the user's messages
themselves.

The same considerations apply to the vacation extension (RFC 5230).

I am not sure what exactly you mean here. The normalization concerns
listed before that sentence all apply to header field content, something
the author of a sieve script cannot control directly. With ":uniqueid"
the script author is directly responsible for the composition of the
unique ID value. As long as the encoding is chosen consistently, the
encoding does not matter for successfully matching it to past values in
the duplicate tracking list. It can also be some sort of binary value if
appropriate; whatever the application demands. The quoted sentence
mainly points to the fact that for some applications it can be useful to
have such normalization for ":uniqueid" as well, e.g. to trim leading
and trailing white space. However, the script author will have to
implement this explicitly, since the duplicate test will not do this
implicitly.

>    specified using the ":header" argument or explicitly from the

Ok, works for me.

Regards,

Stephan.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Jun 2014 06:41:28 -0700

> concerns relating to the duplicate tracking list.

Shouldn't this same concern apply to all meta-data for the users
message?  Folder structure, access records, etc. If it is 'about' the
user or their messages, it should be considered for privacy protection
on a par with the message content.

The counter-force is the need for the system to actually /use/ the data.
 Content might be subject to protection controlled by the user and not
the system, but quite a lot of meta-data has to be used by the system
itself, so the exposure is greater.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jun 2014 10:57:04 -0400

> The same considerations apply to the vacation extension (RFC 5230).

I think a good way to resolve this would be to put something like what
you propose (a sentence or two) into the Security Considerations, to
add that note that this applies to Vacation as well, and to have this
document "update" 5230.  Specifically:

1. Add two paragraphs to 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.  It is
important to protect that information, either by obscuring it through
hashing (see the note at the end of Section 3.2) or by storing it with
a level of access control equivalent to that of the messages
themselves.

The same considerations apply to the Vacation extension [VACATION],
and this updates the Security Considerations of that document (RFC
5230, Section 8) accordingly.

2. Add a paragraph to Section 1:

The Security Considerations section of this document (see Section 6)
updates the Security Considerations for RFC 5230 [VACATION].

3. Add "Updates: 5230" to the document header.

The update to 5230 is optional, but I think it's easy and useful.

> unique ID value.  [etc...]

The problem here, really, is "the user", I think.

What you really want to say, and something I don't think would make
Alissa blink, is this:

NEW
When the ":uniqueid" argument is used, any normalization
needs to be done in the Sieve script itself, as the unique ID
is created.
END

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 20 Jun 2014 20:19:50 +0200

Hi Barry, Alissa,

> a level of access control equivalent to that of the messages

Yes, good text.

> The update to 5230 is optional, but I think it's easy and useful.

It feels a bit odd to update the vacation specification from a document
that has very little to do with it. I have no real issue with that, and
if you say it is OK to do so, I'd be happy to add that. But, still, it
seems a bit awkward and perhaps unexpected for implementers.

> needs to be done in the Sieve script itself, as the unique ID

Yes, that would be OK. Alissa, is this what you meant?

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jun 2014 14:38:25 -0400

> seems a bit awkward and perhaps unexpected for implementers.

Understood.  I think it's fine to do that, as long as it's clear what
the update is, but I do understand why it would seem odd.  Ned, Pete
-- do you have opinions here?

I will point out that we just published an IMAP extension (the update
to CONDSTORE/QRESYNC, RFC 7162) that updated the otherwise unrelated
RFC 2683 by changing a recommendation about maximum line length.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Jun 2014 11:46:44 -0700

> -- do you have opinions here?

Especially for this sort of privacy consideration, I think it's 
unnecessary. We have a long history of documents (still in use) that 
have bad or no advice along these lines (and similarly for security or 
i18n considerations) that we don't try to go back to "update" this way.

> RFC 2683 by changing a recommendation about maximum line length.

I do find changes to protocol processing recommendations somewhat 
different than simply these considerations bits.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jun 2014 14:59:23 -0400

> Especially for this sort of privacy consideration, I think it's unnecessary.
> We have a long history of documents (still in use) that have bad or no
> advice along these lines (and similarly for security or i18n considerations)
> that we don't try to go back to "update" this way.

OK, that's good enough for me.  Alissa, does the added paragraph to
Section 6 work for you as a resolution to this issue?

Barry

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 23 Jun 2014 15:29:32 +0100

Hi Stephan, 

Thanks for your responses. My responses to some issues are below and the
rest are in my other note to Barry.

>series of duplicate messages may arrive with a margin of a few more days.

I find it a bit surprising that receipt of a duplicate multiple days after
the first message is received is that commonplace on today’s Internet. Is
there any data around to back that up?

>to create duplicate tracking list entries that linger indefinitely.

Well, “indefinitely” wouldn’t necessarily be possible, because if the user
specifies nothing then it’s the default, and otherwise he could be
required to specify _something_, correct? But I can appreciate that you
don’t want to impose a long, arbitrary retention requirement. Is the idea
that the maximum would be surfaced to the user if he’s using some GUI to
create a duplicate filter? It just seems odd that the user’s choice would
be silently overridden and he wouldn’t know until duplicate messages start
showing up sooner than expected.

Alissa

>   responses for the "vacation" [VACATION
><http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-07#ref-VACA
>TION>] action. One way to implement

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 23 Jun 2014 15:29:39 +0100

Hi Barry,

Thanks, comments inline.

On 6/20/14, 7:57 AM, "Barry Leiba" <[email-masked]> wrote:

>><http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-07#ref-VAC
>>ATION>] action. One way to implement

I think the last sentence above should be at least a SHOULD. Otherwise the
above text is good.

But, there is another privacy aspect that is not addressed by the text
above and deserves some mention. Suppose I am a law enforcement official
or a private investigator in a divorce lawsuit or some such, and I get a
hold of a list of message IDs from Email Provider X or passive traffic
analysis or wherever. If I go to Email Provider Y and ask whether Jane Doe
has received mail containing any of those IDs, the fact that Email
Provider Y hashed the IDs doesn’t prevent it from producing that
information. Meanwhile, if Jane downloaded or deleted any of those
messages, she might think that he email provider no longer has a record of
them, but that’s not the case.

There aren’t too many good ways to close this expectation gap. For the
case where, say, Jane is an IMAP user and she deletes a message, could
that trigger removal of the ID from the duplicate tracking list? I don’t
know much about Sieve but from the explanation I got from Barry that
didn’t sound likely. The other option is to try to inform the user about
the retention implications of setting up a duplicate filter. I know that
we don’t want to wade into UI considerations, but at the very least I
think highlighting this issue and the potential UI implications for
implementers is important.

>5230, Section 8) accordingly.

Would be nice to fix this but I agree with Pete that doing it from this
document seems odd. Let’s see what text we settle on and maybe we can
think about an errata? Or is it too much for an errata if it ends up
having normative language in it?

>needs to be done in the Sieve script itself, as the unique ID

Yes, this solves my issue.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 23 Jun 2014 10:47:23 -0400

Hi Alissa,

> them, but that’s not the case.

But I think this goes back to what Ned was saying. If an attacker got hold 
of the message-ids then in all likelihood they also have the other headers 
in the message including the recipient email address - which would be 
enough to "prove" delivery - in spite of the fact that Jane might think 
that deleting a message is tantamount to removing any record of it.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 23 Jun 2014 18:07:46 +0200

> there any data around to back that up?

If you exclude mail involving moderated mailing lists, then it's not common 
at all. But with human moderators involved, duplicates arriving on the next 
working day is common enough to be worth supporting.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jun 2014 18:02:16 -0400

> I think the last sentence above should be at least a SHOULD. Otherwise the

I don't really care about 2119 language in that, and I certainly have
no problem with sticking in a SHOULD.

> them, but that’s not the case.

Hm.

If the hashes are salted, it wouldn't be possible to just compare
Message-IDs.  It's probably worth suggesting salting the hashes (with
something unique to each user, such as the username).

On the other hand, if someone had a raw Message-ID and a court order
that said, "Salt and hash this Message-ID and see if it's in Jane
Doe's duplicate list," then, yes, that would work.  And, yes, deleting
messages won't remove them from the duplicate list -- we wouldn't want
it to, because we'd still want a duplicate that arrived after the
deletion to still be considered a duplicate.  Only aging out will
remove an entry.

It's certainly easy to add a paragraph about this angle.  Stephan, you
want to craft something?  I don't think there's any remedy you can put
in, but just calling out the issue is worth a few words.

It's notable, though, that server logs will often have this
information anyway, and probably would expose plaintext Message-IDs
for a much longer period than this will.  I think this would really
only be an issue with an email server that intentionally burns its
logs with the intent of limiting traceability, and that needs to be
made aware that this re-exposes things (including a close estimate of
the timestamp when the message was delivered, by looking at the
aging-out time on the list entry).

> having normative language in it?

Normative or not, it's not errata.  And it's probably not worth
rev-ing the document just for this, either.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 24 Jun 2014 22:36:08 +0200

Hi Barry, Alissa,

> no problem with sticking in a SHOULD.

Works for me too. Summarizing, I intend to add the following text to the
Security Considerations:

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, either by obscuring it
through hashing (see the note at the end of Section 3.2) or by storing
it with a level of access control equivalent to that of the messages
themselves.

> in, but just calling out the issue is worth a few words.

I can add the following sentence to the paragraph above:

However, 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.

Hmm, I am not entirely happy with this wording. Feel free to provide
suggestions.

> aging-out time on the list entry).

Not sure whether I should mention this as well. Let's keep things concise.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 24 Jun 2014 23:01:42 +0200

Hi Alissa,

> there any data around to back that up?

Arnt mentioned one example. I am no expert on this; I couldn't tell you.
If I remember correctly, Alexey Melnikov proposed the default of seven days.

The "vacation" extension specification [RFC5230] mentions retention
periods with similar magnitude (for ":days" argument).

> required to specify _something_, correct?

True, but that something could be e.g. 2**32, which is pretty close to
indefinitely.

> But I can appreciate that you don’t want to impose a long, arbitrary retention requirement. Is the idea that the maximum would be surfaced to the user if he’s using some GUI to
> create a duplicate filter?

My implementation can provide a warning when this situation occurs. In
the case of a GUI this would be returned through ManageSieve with the
WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 .
I am not sure whether other implementations would do this or whether
GUIs actually show these warnings, but at least there is a specification
of this facility.

I could add text that implementations SHOULD issue a warning when a
maximum ":seconds" value is substituted over what the user specified.

> It just seems odd that the user’s choice would

Keep in mind that much of this is modeled after "vacation" [RFC5230] and
"vacation-seconds" [RFC6131]. In those cases the minimum and maximum are
also substituted silently.

Regards,

Stephan.

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jun 2014 15:32:18 -0700 (PDT)

> >>> case described in Section 1.

Am I missing something? The first example is a straightfoward one where
message-id duplicates are filed to a special "Trash/Duplicate" folder. In such
a case basically the longer the retention interval the better things work.
Given the way message-ids are typically generated by most clients it's not like
the longer interval increases the liklihood of a duplicate occurring.
 
If the longer retention period has a downside for the user I am not seeing it.

So whether or not a 7 day retention is problematic really depends on the server
environment. If you're running a server for relatively small number of users,
i.e.., a small to medium sized enterprises, schools, small to medium sized
ISPs, etc. given the high liklihood that not everyone will opt to use this, and
given the power and capabilities of modern server hardware, I seriously doubt
that a 7 day default will cause any problems. An single instance of memcached
can handle an awful lot of entries of this type.

Of course a large ISP/MSP with users numbering in the many millions is going to
face a very different set of tradeoffs. But I have a sneaking suspicion that in
the unfortunately unlikely event that such a concern would bother to offer this
capability, they are capable of picking appropriate defaults, which the
document certainly allows.

And more generaly, it's not the the necessary expertise to size database back
ends of various sorts is hard to come by.

> >>> On the other hand, it seems odd that the
> >>> user's choice would be overriden by the preset maximum.

I don't know if anyone else has pointed this out, but that's not quite how it
works. The user's choice is only overridden if it exceeds the maximum. And
reason for that is simple: All servers need to prevent users from creating
entries that last for absurdly long periods, and in cases where the number
of retained entries is a potential problem, to prevent users from overloading
the system.

> >>> This would make

Again, that's not how it works. There are two values involved: A default
and a maximum. The default is what's used when no value is specified, whereas
is, well, the maximum. And the draft 

I don't really think the text is unclear about the distinction between defaults
and maximums, but if it is then it definitely needs to be changed.

And FWIW, my implementation of this also implements a minimum that is silently
substituted if a user goes under the value. My rationale for having this is
so something sensible is done when users screw up and enter absurdly low
values, then complain when their problem isn't solved. But I don't think
this is sufficiently useful that it belongs in the standard.

> If I remember correctly, Alexey Melnikov proposed the default of seven days.

It's fairly uncommon for there to be significant delays, but that is largely
irrelevant. The point it is does happen, and when it does and duplicates get
through, users who have done to the trouble of setting this up will see them
and complain. And since email is often seen as a cost, not a value-added
service, trading off a bit more hardware - even if it comes to that - for fewer
support calls is not a bad idea.

> periods with similar magnitude (for ":days" argument).

And for similar reasons: Getting multiple vacation replies is fairly
irritating.

> True, but that something could be e.g. 2**32, which is pretty close to

I confess I don't understand this at all.

> > But I can appreciate that you don’t want to impose a long, arbitrary
> > retention requirement. Is the idea that the maximum would be surfaced
> > to the user if he’s using some GUI  create a duplicate filter?

> GUIs actually show these warnings, but at least there is a specification

That's not a bad idea, although I note that nothing says the maximum that's
in effect when the sieve is created is going to be the same as the one
in effect when the sieve is executed.

> maximum ":seconds" value is substituted over what the user specified.

I don't have a problem with that as long as it's specific to managesieve.
There's really no straightforward viable path for reporting warnings at sieve
execution time. (The closest thing we have to that would be the addition of a
header, but the odds of anyone seeing it are so low there's really no point.)
And I don't think this extension is the right place to get into the issue of
hawo to provide warnings from sieve at executiion 

OTOH, I think we may have crossed the line into overdesign here.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 25 Jun 2014 08:53:58 +0200

Hi Ned,

> If the longer retention period has a downside for the user I am not seeing it.

Alissa mentions this in the context of privacy concerns. A longer
retention period means that potentially privacy-sensitive data would be
kept longer. With that point of view, longer retention periods are
undesirable.

> I confess I don't understand this at all.

Alissa means that a truly infinite retention time is not possible;
either a default value is used or the user needs to specify a concrete
value using the ":seconds" argument. However, the ":seconds" argument
can take very large values. If this value is parsed as a 32 bit unsigned
integer, it could be set to 2**32-1, which is a century and a few
decades. I would call that close enough to infinity in this case. That
is why it is wise to enforce a maximum.

> in effect when the sieve is executed.

True.

> header, but the odds of anyone seeing it are so low there's really no point.)

I have a run-time per-user log file for that, but currently users cannot
actually read this.

> hawo to provide warnings from sieve at executiion.

I agree.

Regards,

Stephan.

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 Jun 2014 00:18:46 -0700 (PDT)

> kept longer. With that point of view, longer retention periods are

Since I find the privacy concern as a whole to be unpersuasive, I don't see
it as a concern here.

> is why it is wise to enforce a maximum.

OK.

> I have a run-time per-user log file for that, but currently users cannot

We also write such things to a log - you know, the same one that contains
message transaction metadata like message-ids. A log which in our experience
is always enabled and retained for a lot longer than a week.

				Ned

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Jun 2014 11:58:00 +0100

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.

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.

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

Thanks,
Alissa

On 6/25/14, 8:18 AM, "Ned Freed" <[email-masked]> wrote:

>> >> WARNINGS response code;
>>http://tools.ietf.org/html/rfc5804#section-1.3 .

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Jun 2014 08:19:53 -0400

This is fine with me.  Stephan, if it's OK with you also, please fold
in the changes coming from Alissa's and Kathleen's comments, and post
a revised I-D as soon as you can.  If you can do it before the
Thursday telechat, A & K can clear their discusses.

Barry

On Wed, Jun 25, 2014 at 6:58 AM, Alissa Cooper <[email-masked]> wrote:
> I took Stephan's text and some observations from the thread and put this
>>> >>> Well, "indefinitely" wouldn't necessarily be possible, because if
>>>the user
>>> >>> specifies nothing then it's the default, and otherwise he could be
>>> >> But I can appreciate that you don't want to impose a long, arbitrary
>>> >> to the user if he's using some GUI  create a duplicate filter?

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Jun 2014 14:45:55 +0100

>Thursday telechat, A & K can clear their discusses.

I would still be interested in discussing this bit of my DISCUSS:

o Section 6:
Sieve scripts that include duplicate tests contain potentially sensitive
information (e.g., subject or body strings). So it seems like the scripts
should be confidentiality protected in transit. I checked with Barry and he
said that there is no RFC that specifies if/when scripts should be
protected in
transit, and I understand that this document is probably not the right
place to
specify required behavior there, but I'd like to discuss (more with the ADs
than the authors) if there is some plan for specifying that behavior
somewhere.

Thanks,
Alissa

---

From: Dave Cridland <[email-masked]>
Date: Wed, 25 Jun 2014 14:49:45 +0100

> than the authors) if there is some plan for specifying that behavior

http://tools.ietf.org/html/rfc5804#section-5 covers this to some degree, I
think.

Dave.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Jun 2014 10:18:01 -0400

> information (e.g., subject or body strings).

Actually, no more so than any Sieve script.  Filtering on patterns is
reasonably common, and I don't think duplicate detection will increase
that.

> So it seems like the scripts

As I said when you checked with me, this is entirely out of scope for
this document.  If someone should want to do an update to ManageSieve
or some such, that'd be fine, but it's got nothing to do with this
extension.

Barry

---

From: Eric Burger <[email-masked]>
Date: Wed, 25 Jun 2014 17:58:15 +0100

inline

> access control equivalent to that of the messages themselves.

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

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

> 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

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]

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 Jun 2014 18:24:05 -0700 (PDT)

> reasonably common, and I don't think duplicate detection will increase

Probably less so. Consider:

# Banking rule autogenerated based on user preference settings
if address :domain "from" "bankofamerica.com" {
  fileinto "Banking";
}

provides a much bigger set of clues for spear phishing than any previous
examples given in this thread.

if address "from" "[email-masked]" {
  fileinto "stupidstuff";
}

is not something you want your boss to see.

if address :detail "pager" {
  redirect "[email-masked]";
}

creates a subaddress you probably don't want just anyone to use.

And on and on and on.

> or some such, that'd be fine, but it's got nothing to do with this

Indeed. It may even be out of scope of the core Sieve specifications, since
user preferences and addressbooks are even more likely to provide a basis
for unwelcome privacy intrusions. If this is going to be addressed in
an IETF specification it probably needs to be done in as general a way
as possible.

Address books in particular have been widely exploited; there's nothing
at all theoretical about the attack surface they present.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:04:58 +0200

Hi Alissa,

>>    specified using the ":header" argument or explicitly from the

Applied in -08.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:09:00 +0200

Hi Alissa,

> against the fact that every duplicate will not necessarily be eliminated

Applied in -08. But I made the final paragraph a bit shorter.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:31:24 +0200

Hi Alissa, Barry,

> Yes, this solves my issue.

Overlooked this one for -08, sorry. Addressed in -09.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:34:29 +0200

Hi Barry,

> Thursday telechat, A & K can clear their discusses.

I think I have addressed all agreed changes. It took me more than one
version, because I overlooked one change (It is never good to be in a
bit of a hurry).

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Jun 2014 04:53:24 -0400

> version, because I overlooked one change (It is never good to be in a

Meh... revisions are cheap.
Alissa has cleared her DISCUSS.  We'll if Kathleen agrees as well,
when she wakes up in the morning (Alissa and I are in Europe this
week).

Barry