Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-13

[Ballot discuss]
The document says that one SHOULD do loop detection - I think it needs to point at some advice that provided at least one way to implement loop detection at a level of detail high enough that it is implementable.

I see a serious problem with the allowing redirection a single message to more than one user. This allows a very high speed server to be used for amplification of traffic and used for DOS attacks. The security consideration should provide mechanism to mitigate this. For example, if an anonymous users could get accounts on a service such as yahoo, then upload sieve scripts that did recursive forwarding, the attacker could send very few messages and cause a very huge number of message to be sent from the yahoo mail servers to a system under attack. If a script could redirect to a million addresses, it might be a fine way to send spam. Several people have told me (and I believe them) that the email systems deployed today stop these problems. I'm looking for enough advice that implementors can build sieve implementations that don't cause harm in this way.

[Ballot comment]
I doubt the statement about the system not being Turing-complete. It clearly can do loops with the redirect command and headers can be use for storage by controlling a few accounts that things get looped through.

The comparison of how Carnegie Mellon found this better than FLAME is probably best removed from a standards track document.

[Ballot discuss]
The document says that one SHOULD do loop detection - I think it needs to point at some advice that provided at least one way to implement loop detection at a level of detail high enough that it is implementable.

I see a serious problem with the allowing redirection to more than one users. This allows a very high speed server in the center of the network to perform a application of already large traffic. When filtering happens on an end user email client it is no worse than what the client could do by just sending new email. This is worse. It is also different than mailing lists which hopefully have a consent mechanism. I am proposing fixing this by saying that the limit on number of redirects SHOULD be one and the times to ignore this SHOULD are text environments and such.

[Ballot discuss]
The looping advice is very vague and non normative. I think you need to normatively require something here.

I see a serious problem with the allowing redirection to more than one users. This allows a very high speed server in the center of the network to perform a application of already large traffic. When filtering happens on an end user email client it is no worse than what the client could do by just sending new email. This is worse.

I think this cold be fixed by saying things only get sent to the last address that a redirect is sent to.

Does this meet our i18n requirements?

[Ballot comment]
I doubt the statement about the system not being Turing-complete. It clearly can do loops with the redirect command and headers can be use for storage by controlling a few accounts that things get looped through.

The comparison of how Carnegie Mellon found this better than FLAME is probably best removed from a standards track document.

In many situation it would be nice to be able to add a header to a message in a script - for example a header to add a List-ID header or a header that deals with indication of spam. Any reason not to do this?

[Ballot discuss]
During a November 2006 discussion of a security review by ekr, the
following problematic paragraph was discussed:
>The base
>  language is intentionally not Turing-complete: it provides no way to
>  write a loop or a function


Eric pointed out proposed new text that Alexey was going to take to
the WG.  What ever happened with that discussion?

Also, the change controller for MIME registrations should be the IESG
not the editors.

IANA Additional comments:

Note to editors: The breakup of the IANA considerations
sections in this document is confusing to say the least.
(sections 6.2, 6.3, and 7).
This needs to be fixed before publication IANA considerations
section should be a single number section with subsections.


Action #1: (Section 6.1)
Upon approval of this document, the IANA will make the
following changes in xxx registry located at

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

for capability(s): comparator, envelope, fileinfo
OLD:
RFC 3028

NEW:
[RFC-sieve-3028bis-12]

Name of the registry should also reflect this RFC not 3028.


Action #2: (Section 6.1)

Upon approval of this document, the IANA will make
the following assignments in the "Sieve Extensions
- per [RFC3028]" registry located at

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


Capability name: encoded-character
Capability keyword: encoded-character
Capability arguments:
encoded-character [Sting]
Standards Track/IESG-approved experimental RFC number:
Person and email address to contact for further
information: Philip Guenther
Email: guenther&sendmail.com




Action #3: (section 6.2 and subsections)
Upon approval of this document, the IANA will make
the following changes in the :Sieve Extensions -
per [RFC3028]" registry located at

http://www.iana.org/assignments/sieve-extensions
create sub-registry "Capabilities registrations
[RFC-sieve-3028bis-12]"

Change in registration policy.

Note: The document is actually asking for 3 different
policies, requiring judgement that is outside IANA
expertize.

Proposal: Document should be updated to require expert
review and  the guideline on allocation policies should
be applied by the expert.
In this case the current strong assertions about
Standards Track can  probably be eased.

Action #4: (Sections 6.2 and 7.)

Upon approval of this document, the IANA will make
the following changes in the "Application Media-Types"
registry located at

http://www.iana.org/assignments/media-types/application/

OLD:
sieve [RFC3028]


NEW:
sieve [RFC-sieve-3028bis-12]


We understand the above to be the only IANA Action
for this document.

[Ballot comment]
The document would be better if it discussed where support for IDN-encoded domain names vs. UTF-8 encoded domain names was allowed.  However, that can be fixed with a subsequent "require" extension so I don't consider it a blocking issue.

[Note]: 'Sent review comments to Sieve WG mailing list, waiting for WG chair/editor to give go-ahead for -12, or hold for a -13 revision.' added by Chris Newman

Working Group Summary -- PROTO writeup


1). Have the chairs personally reviewed this version of the ID
and do they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes and yes.

2). Has the document had adequate review from both key WG members and
key non-WG members?

Yes and No.

Do you have any concerns about the depth or breadth of the reviews that
have been performed?

No.

3). Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No concerns.

4). Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or whether there
really is a need for it, etc., but at the same time these issues have been
discussed in the WG and the WG has indicated it wishes to advance the
document anyway.

No concerns.

5). 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 document has strong support from the WG members.

6). Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7). Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes.
(Note that the following warnings reported by ID nits are incorrect:
* The document seems to lack an Introduction section.
* The document seems to lack a Security Considerations section.
* The document seems to lack an IANA Considerations section.
)

8). Does the document a) split references into normative/informative,

Yes

  and b) are there normative references to IDs, where the IDs are not
also ready for advancement
  or are otherwise in an unclear state? (Note: the RFC editor will not
publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)


9). For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following sections:

Summary

This document describes a language for filtering email messages at
time of or after final delivery.  It is designed to be implementable on
either a mail client or mail server.  It is meant to be extensible,
simple, and independent of access protocol, mail architecture, and
operating system.  It is suitable for running on a mail server where
users may not be allowed to execute arbitrary programs, such as on black
box Internet Message Access Protocol (IMAP) servers, as it has no
ability to shell out to external programs.

This document is a revision of RFC 3028.

Process and goals history of this draft.

This document is a revision of RFC 3028. In addition to updating
boilerplate, updating and splitting references into normative and
informative, and correcting ABNF errors, the document also clarified
many ambiguities in RFC 3028, such as handling of invalid RFC 2047
encoding, invalid addresses in headers, invalid header field names in
tests, unknown envelope parts, null return-path in "envelope" test,
capability string case-sensitivity, etc. This update also brings Sieve
in line with the recent comparator spec draft-newman-i18n-comparator-XX)
and removes some requirements which were found to be problematic when
designing some Sieve extensions, for example the ban on tests having
side-effects was removed due to introduction of Sieve variables.

Note that description of the reject action originally specified in RFC
3028 was moved to another draft.

The first WGLC on the draft has ended at the beginning of August 2005.
After the LC WG members realized that the document was unclear on how it
was using comparators. Most of the time in the following year was spent
on building common understanding on how comparators should work in
general and how they are to be used in Sieve. Also, during this period
some additional issues were clarified in the document. Now that
draft-newman-i18n-comparator-XX is in IESG evaluation, the update to RFC
3028 can be sent to IESG.

This draft is being submitted for Proposed Standard.

The SIEVE WG has reviewed the draft and discussed it at a several
meetings.
Last-call (and post last-call) reviews included:
- Kjetil Torgrim Homme
- Ned Freed
- Michael Haardt
- Ken Murchison
- Mark E. Mallett



Protocol Quality

(Who has reviewed the spec for the IESG? Are there implementations?)

Note to RFC Editor

(Insert note to RFC Editor here)

IESG Note

(Insert IESG Note here)

IANA Note

(Insert IANA Note here)

[Note]: 'IANA Considerations is section 6.2. The original comment was that there would be one more Sieve capability to register; -12 has the necessary registration in section 6.2.3 (the first entry for "encoded-character").' added by Chris Newman

IANA Comments:

IANA was said that "There would be one more capability in draft-ietf-sieve-3028bis, when the version 10 is out".

IANA is expecting the new IANA Consideration Section and it
should state the value, location, and other necessary
information clearly.

IANA Last Call Comment:

Upon approval of this document, the IANA understands it must
take three actions.

First, the template for Capability Registrations located in
the registry at:

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

must be updated to reflect the new template located in section
6.2.1 of the approved document.

Second, all of the existing Capability Registrations located
in the registry at:

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

must be updated. For each Capability Registration the following
changes will be made:

[1] The "capability name" and "capability arguments" fields
    will be eliminated
[2] The "capability keyword" field will be renamed to "Capability
    name"
[3] An empty "Description" field will be added
[4] The "Standards Track/IESG-approved experimental RFC number"
    field will be renamed to "RFC number"
[5] The "Person and email address to contact for further
    information" will be renamed to "Contact address"

Third, several of the existing Capability Registrations located
in the registry at:

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

need individual updates:

[1] for the Capability named "fileinto" make the following changes:
Capability name: fileinto
Description: adds the 'fileinto' action for delivering to a
            mailbox other than the default
RFC number: this RFC (Sieve base spec)
Contact address: The Sieve discussion list

[2] for the Capability named "envelope" make the following changes:
Capability name: envelope
Description: adds the 'envelope' test for testing the message
            transport sender and recipient address
RFC number: this RFC (Sieve base spec)
Contact address: The Sieve discussion list

[3] for the Capability named "comparator-*" make the following changes:
Capability name: comparator-* (anything starting with "comparator-")
Description: adds the indicated comparator for use with the
:comparator argument
RFC number: this RFC (Sieve base spec)
Contact address: The Sieve discussion list

IANA understands that these are the only actions required upon
document approval.

[Note]: 'Alexey recommends to review and do IETF last call on version -09 although they have a couple minor edits and a -10 will be necessary.' added by Lisa Dusseault