Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 26 Jun 2014 03:47:27 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-sieve-duplicate-09: No Objection

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/

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

I wondered what'd happen if you used a DKIM-Signature
header with this, but I guess it should just work.
However, I don't recall if that header value is ok to
compare case-sensitive (e.g. "d=" might not be?).  I
don't think any of your examples show how to do the
tolower thing with a header field value, (or is that the
default for "set"?) so I guess you could add one that
does, but up to you, since I assume the intended
readership know this stuff.

Nothing to do with this draft in the end, but I think the 
security/privacy discussion ended up raising a couple of
interesting issues that might be worth revisiting if/when
someone has energy: those were a) if we could make some
good privacy-friendly (but also admin friendly) 
recommendations about logging mail and b) if we could
consider the privacy implications of sieve scripts or
other filters (I liked the "stupid boss" folder name one,
and am guilty of that for some of my own mail:-) and what 
those might expose. For (a) I could imagine a useful
informational RFC, not sure for (b).

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Jun 2014 07:13:40 -0400

> header with this, but I guess it should just work.

Yeh, I think it should just work.  For that case, I actually think the
best approach would be to use the Variables extension to extract the
hash from the DKIM "b=" tag, and use that for the unique ID.  But even
using the whole header field should work fine.

> compare case-sensitive (e.g. "d=" might not be?).

I'd think that shouldn't be an issue.  If you're really looking for
duplicates, it's probably fine to only consider them duplicates if
they're exact matches.

> informational RFC, not sure for (b).

Yeh.  I think a "privacy issues with email deployment" document might
be interesting to have.  I don't know who would have the interest and
energy to do it.

Barry