Skip to main content

Sieve Email Filtering: Detecting Duplicate Deliveries
RFC 7352

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from appsawg-chairs@ietf.org, draft-ietf-appsawg-sieve-duplicate@ietf.org, ned+ietf@mrochek.com to ned+ietf@mrochek.com
2014-09-15
09 (System) RFC published
2014-09-12
09 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-08-14
09 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-08-14
09 (System) RFC Editor state changed to RFC-EDITOR from AUTH48
2014-08-14
09 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-08-06
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-07-01
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-07-01
09 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-07-01
09 (System) RFC Editor state changed to EDIT
2014-07-01
09 (System) Announcement was received by RFC Editor
2014-06-30
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-06-30
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-06-30
09 (System) IANA Action state changed to In Progress
2014-06-30
09 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-06-30
09 Cindy Morgan IESG has approved the document
2014-06-30
09 Cindy Morgan Closed "Approve" ballot
2014-06-30
09 Cindy Morgan Ballot approval text was generated
2014-06-27
09 Shaun Cooley Request for Last Call review by SECDIR Completed: Ready. Reviewer: Shaun Cooley.
2014-06-26
09 Barry Leiba Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com
2014-06-26
09 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2014-06-26
09 Benoît Claise
[Ballot comment]
Background info:
While doing a PC migration, along with an email migration, I found myself in the situation where
- I had some …
[Ballot comment]
Background info:
While doing a PC migration, along with an email migration, I found myself in the situation where
- I had some duplicate emails in thunderbird
- Some of my emails were already manually classified into folders. So it was hard to discover those without redoing the manual classification.

This thunderbird add-on , http://removedupes.mozdev.org/, was very helpful to me.

Discussing with Stephan Bosch, I understand that Thunderbird add-on is used to remove duplicates from the user's mailbox, after delivery, while this Sieve extension is used to detect duplicates while they are being delivered. This is performed using a persistent duplicate tracking list with unique ID values (typically the Message-ID) of previous deliveries and not by searching the destination folder(s) for messages with a matching ID.

The issue with the SIEVE extension is that you have to enable this functionality in advance ... when you know that you're going to do something dangerous. Maybe that works ... but that reminds me of access-list management: "No, I will not do anything stupid! ... oops, I can't access my device any longer!". Or maybe you probably expect this SIEVE extension to be always on? I don't think it's mentioned.

Along the same line (and with my use case in mind):

  Implementations SHOULD let entries in the tracking list expire after
  a short period of time.

I was thinking: "short" = seconds, or minute. So not applicable to my email/PC migration use case.
I saw later:

  A default expiration time of around 7 days is usually
  appropriate.

Good.

I like your 4 examples, but the one I was more interested into was: can we send the duplicates into the same folder.
That would allow me to troubleshoot the root cause being the duplicates (subscribed to 2 mailing lists, synch issue, redirection, etc.)

Bottom line: this draft could be improved by discussing the use cases you have in mind. Certainly not a blocking factor though
2014-06-26
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-06-26
09 Kathleen Moriarty [Ballot comment]
Thanks for clarifying my questions in the updated text!
2014-06-26
09 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2014-06-26
09 Stephen Farrell
[Ballot 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 …
[Ballot 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).
2014-06-26
09 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-06-26
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-06-26
09 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-09.txt
2014-06-26
08 Alissa Cooper
[Ballot comment]
Thanks for addressing my DISCUSS points.

As for protecting scripts/address books in transit, per Ned's email, I would be interested to know if …
[Ballot comment]
Thanks for addressing my DISCUSS points.

As for protecting scripts/address books in transit, per Ned's email, I would be interested to know if there is anyone interested in taking that work up. Or if not, if we could at least note it somewhere as an outstanding vulnerability -- maybe at https://trac.tools.ietf.org/group/ppm-legacy-review/ (which I can't load right now because the tools site seems to be down, so not sure if that is a good place)?
2014-06-26
08 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2014-06-26
08 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-08.txt
2014-06-25
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-06-25
07 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-06-25
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-06-25
07 Pete Resnick
[Ballot comment]
I have no objection to this extension; I think it will be helpful for some folks. Interestingly, I can't see ever using it …
[Ballot comment]
I have no objection to this extension; I think it will be helpful for some folks. Interestingly, I can't see ever using it myself: When I get duplicates from a mailing list, I *always* want the one that was sent from the list, with the List-* header fields on it, and *not* the one sent directly to me. Unfortunately, the one from the list is almost always going to arrive after the one sent directly to me, and the extension doesn't give me enough state to find the message(s) that came in earlier so I can decide which one to keep. But like I said, I can see others using this.

As to specific comments:

  As a side-effect, the "duplicate" test adds the message ID to an
  internal duplicate tracking list once the Sieve execution finishes
  successfully.

I think this may have been mentioned in response to someone else's comment, but perhaps this should be:

  As a side-effect, the "duplicate" test adds a unique identifier
  (again, by default the contents of the Message-ID header field) to an
  internal duplicate tracking list once the Sieve execution finishes
  successfully.

And then change other occurrences of "message ID" to "unique identifier" elsewhere in the document as appropriate.
2014-06-25
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-06-24
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-06-24
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-06-24
07 Brian Haberman [Ballot comment]
I will watch, with interest, the discussion of Alissa's DISCUSS points.
2014-06-24
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-06-24
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-06-23
07 Kathleen Moriarty
[Ballot discuss]
The security considerations seem light, shouldn't there be a security consideration for the possibility of overwriting a message with another?  If an attacker …
[Ballot discuss]
The security considerations seem light, shouldn't there be a security consideration for the possibility of overwriting a message with another?  If an attacker wants to prevent someone from receiving a certain version of a message, couldn't this be used to achieve that goal?  I don't see anything to prevent this, with the exception of good security practices, trusted administrators, and monitoring for any tampering on sending servers.  I'm not looking for too much of a description, but a statement on this possible risk.
2014-06-23
07 Kathleen Moriarty [Ballot comment]
I support Alissa's discusses and will watch for the responses to address privacy and to protect the identifiers used.
2014-06-23
07 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2014-06-22
07 Brian Carpenter Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter.
2014-06-21
07 Adrian Farrel
[Ballot comment]
A small point that is not at the level of a Discuss, but...
Are there not some implications on the integrity of the …
[Ballot comment]
A small point that is not at the level of a Discuss, but...
Are there not some implications on the integrity of the message ID on a message that should be stated. Clearly, if a message ID can be touched, the message can be made to appear to be a duplicate causing the sieve to throw it out.
2014-06-21
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-06-19
07 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2014-06-19
07 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2014-06-19
07 Alissa Cooper
[Ballot discuss]
o Section 3.3:
"A default expiration time of around 7 days is usually
  appropriate. ... If that limit is exceeded by the …
[Ballot 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).
2014-06-19
07 Alissa Cooper
[Ballot 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 …
[Ballot 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."
2014-06-19
07 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2014-06-16
07 Stephan Bosch IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-06-16
07 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-07.txt
2014-06-12
06 Barry Leiba Ballot has been issued
2014-06-12
06 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2014-06-12
06 Barry Leiba Created "Approve" ballot
2014-06-12
06 Barry Leiba Ballot writeup was changed
2014-06-12
06 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-06-12
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-06-06
06 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Stefan Winter.
2014-06-06
06 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-06-06
06 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-sieve-duplicate-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-sieve-duplicate-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Sieve Extensions registry located at:

http://www.iana.org/assignments/sieve-extensions/

a new extension will be registered as follows:

Capability name: duplicate

Description: Adds test 'duplicate' that can be used to test whether a particular message is a duplicate; i.e., whether a copy of it was seen before by the delivery agent that is executing the Sieve script.

RFC number: [ RFC-to-be ]

Contact address: Sieve mailing list

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-06-06
06 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter.
2014-06-05
06 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2014-06-05
06 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2014-06-02
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2014-06-02
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2014-05-30
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-05-30
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-05-29
06 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-05-29
06 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Sieve Email Filtering: Detecting Duplicate …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Sieve Email Filtering: Detecting Duplicate Deliveries) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Sieve Email Filtering: Detecting Duplicate Deliveries'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a new test command "duplicate" for the "Sieve"
  email filtering language.  This test adds the ability to detect
  duplications.  The main application for this new test is handling
  duplicate deliveries commonly caused by mailing list subscriptions or
  redirected mail addresses.  The detection is normally performed by
  matching the message ID to an internal list of message IDs from
  previously delivered messages.  For more complex applications, the
  "duplicate" test can also use the content of a specific header or
  other parts of the message.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-05-29
06 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-05-29
06 Barry Leiba Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com, apps-discuss@ietf.org
2014-05-29
06 Barry Leiba Placed on agenda for telechat - 2014-06-26
2014-05-29
06 Barry Leiba Ballot writeup was changed
2014-05-29
06 Barry Leiba Last call was requested
2014-05-29
06 Barry Leiba Last call announcement was generated
2014-05-29
06 Barry Leiba Ballot approval text was generated
2014-05-29
06 Barry Leiba Ballot writeup was generated
2014-05-29
06 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-05-29
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-05-29
06 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-06.txt
2014-05-28
05 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-05-23
05 Barry Leiba
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
    Proposed standard. …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
    Proposed standard.

    Why is this the proper type of RFC?
   
    This document specifies a Sieve extension. Per RFC 5228 section 6.2, such
    extensions must be published as either standards track or experimental.
    Experimental status seems inappropriate given the straightforward nature
    of this extension.
   
    Is this type of RFC indicated in the title page header?

    Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

    Technical Summary:

      This document defines a new test command "duplicate" for the "Sieve"
      email filtering language.  This test adds the ability to detect
      duplications.  The main application for this new test is handling
      duplicate deliveries commonly caused by mailing list subscriptions or
      redirected mail addresses.  The detection is normally performed by
      matching the message ID to an internal list of message IDs from
      previously delivered messages.  For more complex applications, the
      "duplicate" test can also use the content of a specific header or
      other parts of the message.

    Working Group Summary:

      The document was discussed by a few participants within the Applications
      Area Working Group and it has the consensus of the working group. The
      document was also discussed on the Sieve mailing list, sieve@ietf.org

    Document Quality:

      There are at least two implementations of this extension. Reviews have
      been done at various times by:

        Ned Freed
        Kristin Hubner
        Alexey Melnikov
        Tom Petch
        Aaron Stone

    Personnel:

      Document Shepard: Ned Freed
      Responsible Area Director: Barry Leiba < barryleiba@computer.org>

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd. If this version of the document is not ready for
    publication, please explain why the document is being forwarded to the
    IESG.

      The Document Shepherd has reviewed every revision and has updated his own
      implementation of the extension accordingly.

(4) Does the document Shepherd have any concerns about the depth or breadth
    of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from broader 
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

      N/A

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of? For example, perhaps he or she is uncomfortable
    with certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues and
    has indicated that it still wishes to advance the document, detail those
    concerns here.

      No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79
    have already been filed. If not, explain why?

      The author is in compliance with BCPs 78 and 79.

(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

      N/A

(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or
    does the WG as a whole understand and agree with it?

      The interest level isn't high, but there appears to be consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in separate
    email messages to the Responsible Area Director. (It should be in a
    separate email because this questionnaire is publicly available.)

      N/A

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
    Checklist). Boilerplate checks are not enough; this check needs to be
    thorough.

      The only nit was a comment about coding tags. The only code in the
      document is example Sieve scripts.

(12) Describe how the document meets any required formal review criteria,
    such as the MIB Doctor, media type, and URI type reviews.

      N/A

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

      No.

(15) Are there downward normative references references (see RFC 3967)? If
    so, list these downward references to support the Area Director in the
    Last Call procedure.

      N/A

(16) Will publication of this document change the status of any existing
    RFCs? Are those RFCs listed on the title page header, listed in the
    abstract, and discussed in the introduction? If the RFCs are not listed
    in the Abstract and Introduction, explain why, and point to the part
    of the document where the relationship of this document to the other
    RFCs is discussed. If this information is not in the document, explain
    why the WG considers it unnecessary.

      N/A

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body
    of the document. Confirm that all protocol extensions that the document
    makes are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been suggested
    (see RFC 5226).

      This specification defines a Sieve extension. The IANA Considerations
      contain the necessary registration template for the extension. The
      registration has been checked and looks ok.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      N/A

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

      All of the Sieve examples have been run through a Sieve parser and
      have been found to be valid.


2014-05-23
05 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2014-05-23
05 Amy Vezza Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, ned+ietf@mrochek.com
2014-05-23
05 Murray Kucherawy
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
    Proposed standard. …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
    Proposed standard.

    Why is this the proper type of RFC?
   
    This document specifies a Sieve extension. Per RFC 5228 section 6.2, such
    extensions must be published as either standards track or experimental.
    Experimental status seems inappropriate given the straightforward nature
    of this extension.
   
    Is this type of RFC indicated in the title page header?

    Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

    Technical Summary:

      This document defines a new test command "duplicate" for the "Sieve"
      email filtering language.  This test adds the ability to detect
      duplications.  The main application for this new test is handling
      duplicate deliveries commonly caused by mailing list subscriptions or
      redirected mail addresses.  The detection is normally performed by
      matching the message ID to an internal list of message IDs from
      previously delivered messages.  For more complex applications, the
      "duplicate" test can also use the content of a specific header or
      other parts of the message.

    Working Group Summary:

      The document was discussed by a few participants within the Applications
      Area Working Group and it has the consensus of the working group. The
      document was also discussed on the Sieve mailing list, sieve@ietf.org

    Document Quality:

      There are at least two implementations of this extension. Reviews have
      been done at various times by:

        Ned Freed
        Kristin Hubner
        Alexey Melnikov
        Tom Petch
        Aaron Stone

    Personnel:

      Document Shepard: Ned Freed
      Responsible Area Director: Barry Leiba < barryleiba@computer.org>

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd. If this version of the document is not ready for
    publication, please explain why the document is being forwarded to the
    IESG.

      The Document Shepherd has reviewed every revision and has updated his own
      implementation of the extension accordingly.

(4) Does the document Shepherd have any concerns about the depth or breadth
    of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from broader 
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

      N/A

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of? For example, perhaps he or she is uncomfortable
    with certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues and
    has indicated that it still wishes to advance the document, detail those
    concerns here.

      No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79
    have already been filed. If not, explain why?

      The necessary BCP 78/79 language is present.

(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

      N/A

(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or
    does the WG as a whole understand and agree with it?

      The interest level isn't high, but there appears to be consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in separate
    email messages to the Responsible Area Director. (It should be in a
    separate email because this questionnaire is publicly available.)

      N/A

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
    Checklist). Boilerplate checks are not enough; this check needs to be
    thorough.

      The only nit was a comment about coding tags. The only code in the
      document is example Sieve scripts.

(12) Describe how the document meets any required formal review criteria,
    such as the MIB Doctor, media type, and URI type reviews.

      N/A

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

      No.

(15) Are there downward normative references references (see RFC 3967)? If
    so, list these downward references to support the Area Director in the
    Last Call procedure.

      N/A

(16) Will publication of this document change the status of any existing
    RFCs? Are those RFCs listed on the title page header, listed in the
    abstract, and discussed in the introduction? If the RFCs are not listed
    in the Abstract and Introduction, explain why, and point to the part
    of the document where the relationship of this document to the other
    RFCs is discussed. If this information is not in the document, explain
    why the WG considers it unnecessary.

      N/A

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body
    of the document. Confirm that all protocol extensions that the document
    makes are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been suggested
    (see RFC 5226).

      This specification defines a Sieve extension. The IANA Considerations
      contain the necessary registration template for the extension. The
      registration has been checked and looks ok.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      N/A

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

      All of the Sieve examples have been run through a Sieve parser and
      have been found to be valid.


2014-05-23
05 Murray Kucherawy State Change Notice email list changed to appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org
2014-05-23
05 Murray Kucherawy Responsible AD changed to Barry Leiba
2014-05-23
05 Murray Kucherawy IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-05-23
05 Murray Kucherawy IESG state changed to Publication Requested
2014-05-23
05 Murray Kucherawy IESG process started in state Publication Requested
2014-05-23
05 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-05.txt
2014-05-22
04 Ned Freed Changed document writeup
2014-05-21
04 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-04.txt
2014-04-17
03 Murray Kucherawy Changed consensus to Yes from Unknown
2014-04-17
03 Murray Kucherawy Tags Awaiting Expert Review/Resolution of Issues Raised, Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway cleared.
2014-04-17
03 Murray Kucherawy IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2014-04-17
03 Murray Kucherawy Intended Status changed to Proposed Standard from None
2014-03-03
03 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-03.txt
2014-01-21
02 Murray Kucherawy Tag Revised I-D Needed - Issue raised by WGLC set.
2014-01-10
02 Murray Kucherawy Tags Awaiting Expert Review/Resolution of Issues Raised, Doc Shepherd Follow-up Underway set.
2014-01-10
02 Murray Kucherawy IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2013-12-13
02 Murray Kucherawy WGLC ends January 10, 2014.
2013-12-13
02 Murray Kucherawy IETF WG state changed to In WG Last Call from WG Document
2013-12-11
02 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-02.txt
2013-11-04
01 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-01.txt
2013-05-24
00 Murray Kucherawy Document shepherd changed to Ned Freed
2013-05-22
00 Murray Kucherawy Document shepherd changed to Murray Kucherawy
2013-05-22
00 Murray Kucherawy Document shepherd changed to (None)
2013-05-22
00 Stephan Bosch New version available: draft-ietf-appsawg-sieve-duplicate-00.txt