Subject: Protocol Action: 'SIEVE Email Filtering: Extension for Notifications' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 29 Jan 2008 16:09:54 -0500

The IESG has approved the following document:

- 'SIEVE Email Filtering: Extension for Notifications '
   <draft-ietf-sieve-notify-12.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-12.txt

Note to RFC Editor

Add the following paragraph to the end of the Security Considerations:

"It is imperative that whatever implementations use to store the
user-defined filtering scripts protect them from unauthorized
modification, to preserve the integrity of the mail system.  An attacker
who can modify a script can cause mail to be discarded, rejected, or
forwarded to an unauthorized recipient.  In addition it's possible that
Sieve scripts might expose private information, such as mailbox names, or
email addresses of favoured (or disfavoured) correspondents. Because of
that, scripts SHOULD also be protected from unauthorized retrieval."

SIEVE notify extension WG Chairs Write-up for IESG.

draft-ietf-sieve-notify-09 - Proposed Standard

   (1.a)  Shepherd: Cyrus Daboo <mailto:[email-masked]> I have
          personally reviewed this document and believe it ready for
          submission to the IESG.

   (1.b)  It has had adequate review from WG members. Not from non-WG
          members. No concerns with the nature of those reviews.

   (1.c)  No concerns about broader review.

   (1.d)  No IPR or other concerns with this document.

   (1.e)  There is strong WG consensus behind this document.

   (1.f)  No appeals or serious discontent.

   (1.g)  ID nits were checked. Whilst some warnings appear, the draft
          in fact was correct.

   (1.h)  References are split into two sections. There is one normative
          reference to the SIEVE base spec revision draft which has
          already been submitted to the IESG. There is one informative
          reference to the SIEVE variables extension draft that is in
          the RFC Editor queue waiting on the revised base spec.

   (1.i)  IANA section verified.

   (1.j)  XML and ABNF validated.

   (1.k)  ...

Technical Summary

The SIEVE notify extension adds an action that allows users to trigger
a notification to be sent when an incoming message matches some criteria.
The "base" specification defines a framework on how this action can be
used with a URI to specify the notification method. Subsequent documents
will profile different URI schemes for use with the notify action.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

Several implementers have indicated they will implement this extension.

Personal

Document Shepherd: Cyrus Daboo <mailto:[email-masked]>
AD: Lisa Dusseault <mailto:[email-masked]>

---

From: Aaron Stone <[email-masked]>
Date: Tue, 29 Jan 2008 15:30:01 -0800

To be consistent with the names for the recently published RFC's, may we
include in the instructions to the RFC Editor to update the title to:

    Sieve Email Filtering: Notify Extension

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 Jan 2008 19:36:41 +0000

>    Sieve Email Filtering: Notify Extension
Ok, I will try to to remember to do that.

Date: Wed, 30 Jan 2008 19:36:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: ietf-mta-filters <[email-masked]>
Subject: Re: Protocol Action: 'SIEVE Email Filtering: Extension for Notifications' to Proposed Standard
Sender: [email-masked]

>    Sieve Email Filtering: Notify Extension
Ok, I will try to to remember to do that.

Subject: Re: Protocol Action: 'SIEVE Email Filtering: Extension for Notifications' to Proposed Standard
From: Aaron Stone <[email-masked]>
To: ietf-mta-filters <[email-masked]>
Date: Tue, 29 Jan 2008 15:30:01 -0800
Sender: [email-masked]

Aaron

> AD: Lisa Dusseault <mailto:[email-masked]>

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'SIEVE Email Filtering: Extension for  Notifications' to Proposed Standard 
Date: Tue, 29 Jan 2008 16:09:54 -0500
Sender: [email-masked]

Note to RFC Editor

   (1.k)  ...

Technical Summary

Working Group Summary

Document Quality

Personal

Date: Fri, 25 Jan 2008 12:54:23 +0200
From: Alexandros Vellis <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Re: New RFCs, thanks to all!
Organization: National and Kapodistrian University of Athens
Sender: [email-masked]

On Mon, 21 Jan 2008 11:22:44 +0100
Stephane Bortzmeyer <[email-masked]> wrote:

> Can anyone update http://www.fastmail.fm/docs/sieve/, which seems well
> referenced (Google mentions it in the first results)?

This page has been outdated for a long time. All its contents have been
incorporated to http://sieve.info , though.

I've updated the http://sieve.info/documents  page to point to the new
RFCs. If you notice anything is omitted or wrong, please notify me and
I'll fix it.

-- 
Alexandros Vellis

From: "Matthew Elvey" <[email-masked]>
To: [email-masked]
Subject: I-D Action:draft-ietf-sieve-refuse-reject-06.txt & spam blowback.
Date: Mon, 21 Jan 2008 11:59:46 -0800
Sender: [email-masked]

I'm unhappy with the current draft.

There is reluctance to change the current behaviour for what was
presented as nothing more than an unwillingness to explain what we all
agreed were net good reasons for the change to a customer!  The push to
change the draft in a way that (unlike the versions I worked on - i.e.
from pre-00 to Change log entry 07) makes it significantly fail to
address the blowback issue that was my primary motivation for getting
involved is not an improvement; it changes a view that had on-list
consensus for a long time, through many revision changes.

My last long post to the list to draw out views on this issue in order
to move forward was answered by the blocker, Ned, IIRC. 

I just reread the "Spam blowback from Sieve implementations." thread to
refresh my memory.   I reread Ned's posts, which made it explicit that
he had no intention of directly responding to the question I posed to
him, but his view is clear.   Ned's answer to my question below is (an
implicit but clear) yes:
> Do we want to have the spec allow implementers to not bother to
> implement the ability to do proper smtp-time refusals, even though all
> implementers at the meeting indicated that it was possible for the
> implementations to be changed so that they could do so, and not doing so
> produces and will continue to produce immense economic harm caused by
> spam blowback?  

We've discussed the issue pretty throughly in that thread and though Ned
and others have made notable points, we still disagree, or at least my
opinion remains the same.  My answer, after balancing the pros and cons,
is still no.

I strongly support requiring a change to the default behaviour, and most
certainly requiring that all implementations implement the ability to do
proper smtp-time (or lmtp-time) protocol-level refusals (other than
MUA-based implementations).  It's an important interoperability issue.

Given the current draft, the latter requires a small change: 

To the sentence that begins:

"The Sieve interpreter MUST carry out one of the following actions
(listed in order from most to least preferred),"
add something like: 
"MUST support the user's choice to carry out the most preferable action
possible"

An alternate (perhaps clearer) way of accomplishing this would be to
require that all (but MUA-based) implementations supporting 'reject'
also support 'ereject': change
"   The ereject action MUST NOT be available in environments that do not
   support protocol level rejection, e.g. an MUA."
to 
"   The ereject action MUST NOT be available in environments that do not
   support protocol level rejection, e.g. an MUA, but MUST be available
   in all other environments that support the reject action"

Date: Mon, 21 Jan 2008 11:22:44 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: SIEVE <[email-masked]>
Subject: Re: New RFCs, thanks to all!
Organization: NIC France
Sender: [email-masked]

On Wed, Jan 16, 2008 at 02:58:02PM -0500,
 Cyrus Daboo <[email-masked]> wrote 
 a message of 17 lines which said:

> Our new RFCs have just been published:

Can anyone update http://www.fastmail.fm/docs/sieve/, which seems well
referenced (Google mentions it in the first results)?

Date: Wed, 16 Jan 2008 20:25:16 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Call for interop proposals]
Sender: [email-masked]

--------------040502030606010000060500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Is there any interest in doing this during the Philadelphia IETF in 
March this year?
I know that we have many active participants in this WG from Europe, but 
maybe we can have some US and some remote participants in Philadelphia.

--------------040502030606010000060500
Content-Type: message/rfc822;
 name="Call for interop proposals"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Call for interop proposals"

Cc: Lisa Dusseault's Chairs <[email-masked]>,
 [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Wed, 9 Jan 2008 17:13:17 -0800
To: Apps Discuss <[email-masked]>
Subject: Call for interop proposals

At the Apps area open meeting in Vancouver, Chris & I mentioned the  
possibility of doing a day of interoperability events at the next  
IETF meeting.  This would replace a day of Apps area meetings during  
the normal meeting hours and in the normal meeting location.  Ideally  
it would allow people to come to the IETF for more than just "their"  
meeting (although we have always hoped they can attend other WG  
meetings as well) and participants may get more benefit and better  
justification for attending.

If we're going to do this, we need proposals: what topic  ( IDs,  
RFCs, suites or functionality) will be tested.  I don't think  
interops will need a lot of management but volunteer coordinators  
would be ideal.  Proposals will need to be followed quickly by some  
indications of who will participate.  WG scheduling is already open  
and we need to tell the Secretariat immediately if they need to  
reserve a day for interops.

Proposals should probably be posted on some relevant subject mailing  
list to quickly generate discussion among potential participants --  
not everybody reads Apps Discuss.

Thanks,
Lisa

--------------040502030606010000060500--

Date: Wed, 16 Jan 2008 20:15:43 +0000
From: Alexey Melnikov <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Re: New RFCs, thanks to all!
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> Our new RFCs have just been published:
>
> RFC 5228 on Sieve: An Email Filtering Language
> RFC 5229 on Sieve Email Filtering: Variables Extension
> RFC 5230 on Sieve Email Filtering: Vacation Extension
> RFC 5231 on Sieve Email Filtering: Relational Extension
> RFC 5232 on Sieve Email Filtering: Imap4flags Extension
> RFC 5233 on Sieve Email Filtering: Subaddress Extension
> RFC 5235 on Sieve Email Filtering: Spamtest and Virustest Extensions
>
> Thanks to all the authors and editors for getting these done. And 
> thanks to all the WG participants and ADs for helping out.

Indeed, your names will not be forgotten!

Date: Wed, 16 Jan 2008 14:58:02 -0500
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: New RFCs, thanks to all!
Sender: [email-masked]

Hi folks,
Our new RFCs have just been published:

RFC 5228 on Sieve: An Email Filtering Language
RFC 5229 on Sieve Email Filtering: Variables Extension
RFC 5230 on Sieve Email Filtering: Vacation Extension
RFC 5231 on Sieve Email Filtering: Relational Extension
RFC 5232 on Sieve Email Filtering: Imap4flags Extension
RFC 5233 on Sieve Email Filtering: Subaddress Extension
RFC 5235 on Sieve Email Filtering: Spamtest and Virustest Extensions

Thanks to all the authors and editors for getting these done. And thanks to 
all the WG participants and ADs for helping out.

-- 
Cyrus Daboo

To: [email-masked], [email-masked]
Subject:  RFC 5235 on Sieve Email Filtering: Spamtest and Virustest Extensions
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:52:31 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5235

        Title:      Sieve Email Filtering: Spamtest and 
                    Virustest Extensions 
        Author:     C. Daboo
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked]
        Pages:      13
        Characters: 25957
        Obsoletes:  RFC3685
        See-Also:   

        I-D Tag:    draft-ietf-sieve-spamtestbis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5235.txt

The Sieve email filtering language "spamtest", "spamtestplus", and
"virustest" extensions permit users to use simple, portable commands
for spam and virus tests on email messages.  Each extension provides
a new test using matches against numeric "scores".  It is the
responsibility of the underlying Sieve implementation to do the
actual checks that result in proper input to the tests.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5233 on Sieve Email Filtering: Subaddress Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:52:12 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5233

        Title:      Sieve Email Filtering: Subaddress Extension 
        Author:     K. Murchison
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked]
        Pages:      7
        Characters: 12448
        Obsoletes:  RFC3598
        See-Also:   

        I-D Tag:    draft-ietf-sieve-rfc3598bis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5233.txt

On email systems that allow for 'subaddressing' or 'detailed
addressing' (e.g., "[email-masked]"), it is sometimes
desirable to make comparisons against these sub-parts of addresses.
This document defines an extension to the Sieve Email Filtering
Language that allows users to compare against the user and detail
sub-parts of an address.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5232 on Sieve Email Filtering: Imap4flags Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:52:02 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5232

        Title:      Sieve Email Filtering: Imap4flags Extension 
        Author:     A. Melnikov
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked]
        Pages:      12
        Characters: 21964
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-imapflags-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5232.txt

Recent discussions have shown that it is desirable to set different
IMAP (RFC 3501) flags on message delivery.  This can be done, for
example, by a Sieve interpreter that works as a part of a Mail
Delivery Agent.

This document describes an extension to the Sieve mail filtering
language for setting IMAP flags.  The extension allows setting of both
IMAP system flags and IMAP keywords.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5231 on Sieve Email Filtering: Relational Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:51:45 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5231

        Title:      Sieve Email Filtering: Relational Extension 
        Author:     W. Segmuller, B. Leiba
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      9
        Characters: 15243
        Obsoletes:  RFC3431
        See-Also:   

        I-D Tag:    draft-ietf-sieve-3431bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5231.txt

This document describes the RELATIONAL extension to the Sieve mail
filtering language defined in RFC 3028.  This extension extends
existing conditional tests in Sieve to allow relational operators.
In addition to testing their content, it also allows for testing of
the number of entities in header and envelope fields.

This document obsoletes RFC 3431.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5230 on Sieve Email Filtering: Vacation Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:51:37 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5230

        Title:      Sieve Email Filtering: Vacation Extension 
        Author:     T. Showalter, N. Freed, Ed.
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      16
        Characters: 29822
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-vacation-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5230.txt

This document describes an extension to the Sieve email filtering
language for an autoresponder similar to that of the Unix "vacation"
command for replying to messages.  Various safety features are
included to prevent problems such as message loops.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5229 on Sieve Email Filtering: Variables Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:51:28 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5229

        Title:      Sieve Email Filtering: Variables Extension 
        Author:     K. Homme
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked]
        Pages:      11
        Characters: 20023
        Updates:    RFC5228
        See-Also:   

        I-D Tag:    draft-ietf-sieve-variables-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5229.txt

In advanced mail filtering rule sets, it is useful to keep state or
configuration details across rules.  This document updates the Sieve
filtering language (RFC 5228) with an extension to support variables.
The extension changes the interpretation of strings, adds an action to
store data in variables, and supplies a new test so that the value of
a string can be examined.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

To: [email-masked], [email-masked]
Subject:  RFC 5228 on Sieve: An Email Filtering Language
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 16 Jan 2008 11:51:17 -0800 (PST)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5228

        Title:      Sieve: An Email Filtering Language 
        Author:     P. Guenther, Ed.,
                    T. Showalter, Ed.
        Status:     Standards Track
        Date:       January 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      42
        Characters: 87531
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-3028bis-13.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5228.txt

This document describes a language for filtering email messages at
time of 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 the base language
has no variables, loops, or ability to shell out to external
programs.  [STANDARDS TRACK]

This document is a product of the Sieve Mail Filtering Language
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...