Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

[Matthew Elvey <[e-mail]>]

In order to move forward since the discussion of this draft at the last BOF:

I would like to gauge interest. Which SIEVE
implementations/implementors 'intend' to write code to support some
IETF-blessed extension in order to provide a "Reject before delivery
capability" (e.g. draft-elvey-refuse-sieve or a derivative)?  
Currently, no implementations have this ability.

Please indicate your interest! (e.g. Edit the wiki page mentioned below (put an "i" in the right place) or reply to me and I'll make the edit for you.)

('Intend' just indicates strong interest, it doesn't mean "Guarantee by x date")

<Editorial>
It's urgent and important that SIEVE gain the ability to do SMTP-time refusals.  Here's why:
Many mail recipients are starting to refuse mail from senders who reject after delivery.  Relatively conservative blacklists are starting to list IPs that are mainly sources of large amounts of joe-job blowback:
<http://groups.google.com/groups?threadm=yb2dnaRBHZwaxD_cRVn-vw%40speakeasy.net>
So whether SIEVE / refuse supports, deprecates, or disallows MUAs to reject mail, the Internet is looking at it increasingly as usually a bad idea.  Even fairly well-written vacation programs are often deprecated, as if they are linked to addresses that get lots of spam, they can cause a lot of joe-jobs.  Perhaps this will cease to be an issue as sites implement BATV-type schemes that block joe-jobs.  For now, SIEVE must gain the ability to do SMTP-time refusals.  
</Editorial>
(Please, no OT response posts not about SMTP-time refusals; I don't wish to lead us off course)

Preemptory Clarification: Because of issues already known and discussed, MUA implementations (which can't do SMTP-time rejects) will not be made incapable of being SIEVE-compliant by any SIEVE draft I wrote or intend to write.  

BTW, I belatedly noticed an error the Charter: it has a link to the -01 version of the draft-elvey-refuse-sieve, not the -02 version mentioned below. 

On 8/10/2004 1:46 AM, Matthew Elvey sent forth electrons to convey:

>
> 1) Belatedly announcing, in case folks missed it:
>    http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt
>
>    Last discussion post on 'refuse' was my post on 6/8/04.
>    I believe 'refuse' is ready for last call.
> =-=-=
>
> 2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
> might make a good addition to http://cyrusoft.com/sieve/.
>
> -- 
> Matthew
>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB12cJGZ017842; Tue, 30 Nov 2004 18:38:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB12cJu0017841; Tue, 30 Nov 2004 18:38:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB12cD0a017760 for <[e-mail]>; Tue, 30 Nov 2004 18:38:18 -0800 (PST) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 6556AC3DA03 for <[e-mail]>; Tue, 30 Nov 2004 21:38:16 -0500 (EST)
X-Sasl-enc: X7tTkyK0wm9lblHyocsccA 1101868696
Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id 36E5F247F3; Tue, 30 Nov 2004 21:38:16 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 2004 21:38:15 -0500
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In order to move forward since the discussion of this draft at the last BOF:

I would like to gauge interest. Which SIEVE
implementations/implementors 'intend' to write code to support some
IETF-blessed extension in order to provide a "Reject before delivery
capability" (e.g. draft-elvey-refuse-sieve or a derivative)?  
Currently, no implementations have this ability.

Please indicate your interest! (e.g. Edit the wiki page mentioned below (put an "i" in the right place) or reply to me and I'll make the edit for you.)

('Intend' just indicates strong interest, it doesn't mean "Guarantee by x date")

<Editorial>
It's urgent and important that SIEVE gain the ability to do SMTP-time refusals.  Here's why:
Many mail recipients are starting to refuse mail from senders who reject after delivery.  Relatively conservative blacklists are starting to list IPs that are mainly sources of large amounts of joe-job blowback:
<http://groups.google.com/groups?threadm=yb2dnaRBHZwaxD_cRVn-vw%40speakeasy.net>
So whether SIEVE / refuse supports, deprecates, or disallows MUAs to reject mail, the Internet is looking at it increasingly as usually a bad idea.  Even fairly well-written vacation programs are often deprecated, as if they are linked to addresses that get lots of spam, they can cause a lot of joe-jobs.  Perhaps this will cease to be an issue as sites implement BATV-type schemes that block joe-jobs.  For now, SIEVE must gain the ability to do SMTP-time refusals.  
</Editorial>
(Please, no OT response posts not about SMTP-time refusals; I don't wish to lead us off course)

Preemptory Clarification: Because of issues already known and discussed, MUA implementations (which can't do SMTP-time rejects) will not be made incapable of being SIEVE-compliant by any SIEVE draft I wrote or intend to write.  

BTW, I belatedly noticed an error the Charter: it has a link to the -01 version of the draft-elvey-refuse-sieve, not the -02 version mentioned below. 

On 8/10/2004 1:46 AM, Matthew Elvey sent forth electrons to convey:

>
> 1) Belatedly announcing, in case folks missed it:
>    http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt
>
>    Last discussion post on 'refuse' was my post on 6/8/04.
>    I believe 'refuse' is ready for last call.
> =-=-=
>
> 2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
> might make a good addition to http://cyrusoft.com/sieve/.
>
> -- 
> Matthew
>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUEEKQD094393; Tue, 30 Nov 2004 06:14:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUEEKTk094392; Tue, 30 Nov 2004 06:14:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUEEJTo094280 for <[e-mail]>; Tue, 30 Nov 2004 06:14:19 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 30 Nov 2004 14:14:04 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 2004 14:14:03 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-variables-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Few comments/questions after reviewing the document:

1). Is the first parameter of the STRING test (list of variable names) 
has to be "expanded"?

2). ABNF (or RFC 3028 "Syntax:" line) for MODIFIER is missing.
Also, I have an editorial suggestion. Section 5. ("Action set") doesn't 
mention modifiers at all, instead there is a subsection 5.1 for them

I would suggest to add the following sentence to section 5:

   Modifiers are applied on a value before it is stored in the variable.
   Modifier names are case insensitive. For more information see section 5.1

And drop the first 2 sentences at the top of 5.1.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATKHDHB021225; Mon, 29 Nov 2004 12:17:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATKHDpv021224; Mon, 29 Nov 2004 12:17:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATKHDHq021217 for <[e-mail]>; Mon, 29 Nov 2004 12:17:13 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27180; Mon, 29 Nov 2004 15:17:14 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-00.txt
Date: Mon, 29 Nov 2004 15:17:14 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-00.txt
	Pages		: 13
	Date		: 2004-11-29
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIJX3q002379; Mon, 29 Nov 2004 10:19:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATIJXEa002378; Mon, 29 Nov 2004 10:19:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIJW4A002355 for <[e-mail]>; Mon, 29 Nov 2004 10:19:32 -0800 (PST) (envelope-from [e-mail])
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38237) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1CYq7Z-0007OR-HK (Exim 4.44) for [e-mail] (return-path <[e-mail]>); Mon, 29 Nov 2004 18:19:33 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1CYq7Z-0003L7-Al (Exim 4.43) for [e-mail] (return-path <[e-mail]>); Mon, 29 Nov 2004 18:19:33 +0000
Date: Mon, 29 Nov 2004 18:19:33 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: matching bounce messages
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We're using the CMU Cyrus Sieve implementation. A few of our more advanced
users have asked how to identify bounce messages in a Sieve script. The
obvious doesn't work:

	if envelope :is "from" ""

The best phrasing we have seen is

	if not envelope :contains "from" "@"

which is a rather ugly circumlocution. RFC 3028 doesn't say anything about
null return paths, which is clearly an omission. As a result the Cyrus
behaviour is hard to classify as a bug.

Tony.
-- 
f.a.n.finch  <[e-mail]>  http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
MODERATE.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJEVMqf076863; Fri, 19 Nov 2004 06:31:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJEVMXp076862; Fri, 19 Nov 2004 06:31:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAJEVHOn076780 for <[e-mail]>; Fri, 19 Nov 2004 06:31:20 -0800 (PST) (envelope-from [e-mail])
Received: by kalyani.oryx.com (Postfix, from userid 1005) id 8B70B1BDE94; Fri, 19 Nov 2004 15:31:12 +0100 (CET)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id CFD981BDE90 for <[e-mail]>; Fri, 19 Nov 2004 15:31:11 +0100 (CET)
Message-Id: <[e-mail]>
Date: Fri, 19 Nov 2004 15:26:37 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: running a script after a certain delay
Cc: Thoralf Will <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thoralf Will writes:
> Currently we are using a combination of cron and reply-o-matic but 
> it's really far from being perfect.

I suggest using procmail to weed away FROM_DAEMON mail etc, then 
formail|at to do the reply. Something like this should construct a nice 
autoreply and delay sending the result:

( echo '/usr/sbin/sendmail -t' ; formail -rt ; cat boilerplate ) | at +12hours

Now, in sieve, assuming this sort of thing were to be done in sieve at 
all, wouldn't it be natural to do it with an RFC2852 argument for the 
vacation extension?

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJDx30B066344; Fri, 19 Nov 2004 05:59:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJDx3rN066343; Fri, 19 Nov 2004 05:59:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cipsoft.com (mail.cipsoft.com [62.146.47.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJDwxYK066279 for <[e-mail]>; Fri, 19 Nov 2004 05:59:02 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.cipsoft.com (Postfix) with ESMTP id 0034F1A325F for <[e-mail]>; Fri, 19 Nov 2004 14:58:51 +0100 (CET)
Received: from mail.cipsoft.com ([127.0.0.1]) by localhost (regina.cipsoft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20485-06 for <[e-mail]>; Fri, 19 Nov 2004 14:58:50 +0100 (CET)
Received: from sam.cipsoft.de (p5091CCA4.dip0.t-ipconnect.de [80.145.204.164]) by mail.cipsoft.com (Postfix) with ESMTP id 3F4C31A324D for <[e-mail]>; Fri, 19 Nov 2004 14:58:50 +0100 (CET)
Received: from celeborn.cipsoft.de (celeborn.cipsoft.de [192.168.0.112]) by sam.cipsoft.de (Postfix) with ESMTP id 732E89B784 for <[e-mail]>; Fri, 19 Nov 2004 14:58:50 +0100 (CET)
Received: by celeborn.cipsoft.de (Postfix, from userid 500) id 6497F43F5; Fri, 19 Nov 2004 14:58:50 +0100 (CET)
Date: Fri, 19 Nov 2004 14:58:50 +0100
From: Thoralf Will <[e-mail]>
To: [e-mail]
Subject: Re: running a script after a certain delay
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2i
X-Virus-Scanned: by amavisd-new at mail.cipsoft.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 05, 2003 at 03:45:22PM +0000, Alexey Melnikov wrote:
> Thoralf Will wrote:
> >is there any implementation/idea/suggestion available already to run a
> >script after a certain time has passed?
> >
> >Example:
> >Mail from [e-mail] arrives and gets delivered, the usual scripts are
> >running and put it into a special folder.
> >A 2nd script starts 1h later, looks for a mail in this special folder
> >and does something (redirect again, autoreply ...) if there is still a
> >mail.
> >
> >Is this possible
> >
> The way you describe it, the 2nd script is just being executed by a 
> special type Mail User Agent.
> 
> >and when how or are there any intentions to implement
> >something like this?
> > 
> >
> Can you be more specific. For the task you describe, I don't see any 
> need to modify/extend Sieve.
> 
> If you are looking for a product that can do that, you should at least 
> tell us what is your OS requirement.

Sorry for the extremely late reply but I thought to have found a solution
(a perl script named reply-o-matic). Sadly it looks like that this tool
is rather buggy and I don't dare to try to fix that.

To give a more detailed example:

The idea behind this is a support mail box that gets more or less spammed
and to prevent answering every single message with faq an autoreply
containing exactly those faq should be send with a 2nd mail address ad the
end telling the user to re-post the problem to that address if the problem
still persists. For cosmetic reasons the autoreply should have an initial
delay (simply because most ppl do not read autoreplies when they get the
message right away) and for technical reasons (to prevent ppl from
spamming others with spoofed addresses) we need a restriction that not
more than 1 reply will be send to the same address within 1 day.

Currently we are using a combination of cron and reply-o-matic but it's
really far from being perfect.

Thoralf



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHWjFk053643; Thu, 18 Nov 2004 09:32:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIHWj8e053642; Thu, 18 Nov 2004 09:32:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHWjWe053594 for <[e-mail]>; Thu, 18 Nov 2004 09:32:45 -0800 (PST) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 18 Nov 2004 12:32:43 -0500 id 00544297.419CDCBB.0000748B
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: SIEVE WG Approved
Date: Thu, 18 Nov 2004 12:32:55 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A few minutes ago the IESG approved creation of the SIEVE working group in
the applications area.  An announcement should be coming from the
Secretariat "soon".  Congratulations!

Now get to work! ;-)

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEhqv3073900; Mon, 15 Nov 2004 06:43:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFEhpiv073898; Mon, 15 Nov 2004 06:43:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEhksE073846 for <[e-mail]>; Mon, 15 Nov 2004 06:43:46 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 14:43:33 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 14:43:30 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jutta Degener <[e-mail]>
CC: Tim Showalter <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Action Interaction
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jutta Degener wrote:

>On Fri, Nov 05, 2004 at 11:30:26AM +0000, Alexey Melnikov wrote:  
>
>>Tim Showalter wrote:  
>>
>>>In general, I agree, and I will try to incorporate these changes into 
>>>the next draft.
>>>
>>>Alexey Melnikov wrote:
>>>      
>>>
>>>>3). Need to state that "reject" and "discard" are incompatible.
>>>>        
>>>>
>>>They aren't clearly incompatible.  If keep+discard aren't 
>>>incompatible, why would reject+discard be incompatible?
>>>      
>>>
>>Section 2.10.4 says:
>>  Implementations SHOULD prohibit reject when used with other actions.    
>>
>
>Right, so it depends on whether implementations implement
>this SHOULD.  (With ours, it's configurable.)
>  
>
Why? Why not have two separate actions instead?

>I'm not sure why something other than the quoted statement is needed.
>
>But I don't follow this logic:
>
As you noted below I am trying to redefine what "discard" means based on 
the English meaning of the word. The mailing list archive confirms that 
many people got confused by the definition of "discard", so maybe we 
should adjust its definition.

>>I frankly don't care either way, but this must clearly be stated. Either
>>a). when both discard and reject are requested, reject is executed    
>>
>
>Apart from the SHOULD in 2.10.4 (and the application-level
>considerations behind it), I don't see what the technical
>problem with executing discard and reject is.
>
I never said there is a technical problem. I am just trying to use the 
usual meaning of the words.

>  Discard cancels
>the implicit keep.  Reject sends a nastygram and cancels the implicit
>keep.  So, discard + reject do the same as reject alone, just
>like discard + fileinto do the same as fileinto alone.
>
>Not because someone explicitly said so; the math just works
>out that way.
>  
>
>>or
>>b). the last one of discard/reject is executed (i.e. discard also 
>>cancels a previous reject)
>>    
>>
>No!  Please, no time travel.
>  
>
There is no time travel for implementation that execute all actions 
after the script interpretation, as opposed to executing an action at 
the time of interpretation.
But I am Ok with not requiring this.

>>or
>>c). discard and reject are incompatible (as discard is a silent reject 
>>and one can't reject silently and not silently at the same time).    
>>
>
>That would be the right thing to do for implementations that
>implement the SHOULD in 2.10.4.  (Not because "discard is a
>silent reject"; it isn't, although that may be the way some
>people chose to think about it.)
>
>The normal *user* idea of "discard;" is usually better
>expressed by "discard; stop;" -- don't file it, and don't
>do anything else with it, either, because after something
>is discarded (in the English sense of the term), it is gone.
>But that's not how the sieve discard action is defined--it
>just cancels the implicit keep.
>  
>
I don't really like that there is a choice between a) and c). Can we 
just pick one? There is already too much optional stuff in Sieve.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABLsvWW027439; Thu, 11 Nov 2004 13:54:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABLsv7F027438; Thu, 11 Nov 2004 13:54:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABLsuRU027426 for <[e-mail]>; Thu, 11 Nov 2004 13:54:56 -0800 (PST) (envelope-from [e-mail])
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1CSMu5-0005RA-Q7 for [e-mail]; Thu, 11 Nov 2004 16:54:53 -0500
Date: Thu, 11 Nov 2004 16:54:53 -0500
From: John C Klensin <[e-mail]>
To: [e-mail]
Subject: Sieve subscribe
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

subscribe



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB2Cgnx031700; Wed, 10 Nov 2004 18:12:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB2CeUw031699; Wed, 10 Nov 2004 18:12:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB2CZPc031637 for <[e-mail]>; Wed, 10 Nov 2004 18:12:39 -0800 (PST) (envelope-from [e-mail])
Received: from [130.129.135.95] ([130.129.135.95]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAB15h6E011088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Nov 2004 20:05:47 -0500
Date: Wed, 10 Nov 2004 21:12:30 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Reminder: SIEVE BOF
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Just a reminder that the SIEVE BOF at the IETF meeting is tomorrow 
(Thursday) 15:30 - 17:30 EST. For those not present, you can participate 
via Jabber, and the Jabber address for that is:

	[e-mail]

I know some people are planning to use Jabber for the first time, so I will 
endeavor to be present in the jabber room during the previous session 
(13:00 - 15:00 EST) to make sure people know they can connect successfully.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB0o7hb092852; Wed, 10 Nov 2004 16:50:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB0o7mK092851; Wed, 10 Nov 2004 16:50:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB0o2rA092771 for <[e-mail]>; Wed, 10 Nov 2004 16:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.15] (69-161-65-27.bflony.adelphia.net [69.161.65.27]) (authenticated bits=0) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAB0npJ3009882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2004 19:49:56 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 19:49:45 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Jutta Degener <[e-mail]>
CC: [e-mail]
Subject: Re: Impending changes to "body" draft.
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 (BAYES_00)
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jutta Degener wrote:

>   QUESTION: Are we okay with throwing out :binary, or 
>   is someone using it for something worthwhile?
>   If we want to keep it, how strongly do we feel about
>   using a format that looks more like quoted-printable?

I'm more than happy to drop :binary since is one part I didn't implement 
in CMU Sieve.

>   QUESTION: Is it okay to have body :matches and
>   :regex scans not set variables?

Fien by me, but I'll defer to the consensus, since I don't yet have any 
implementation experience with sieve variables.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALmPVa020162; Wed, 10 Nov 2004 13:48:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAALmPKl020161; Wed, 10 Nov 2004 13:48:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALmOkT020107 for <[e-mail]>; Wed, 10 Nov 2004 13:48:25 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 10 Nov 2004 13:48:22 -0800 (PST)
Date: Wed, 10 Nov 2004 13:47:18 -0800 (PST)
From: [e-mail]
Subject: Re: Impending changes to "body" draft.
In-reply-to: "Your message dated Wed, 10 Nov 2004 13:18:12 -0800 (PST)" <[e-mail]>
To: Jutta Degener <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Wed, Nov 03, 2004 at 11:45:40AM -0500, Cyrus Daboo wrote:
> > If any document authors will not be at the meeting, either in person or via
> > jabber, could they please send me privately a summary of the state of their
> > document so I can present that as part of our discussions, thanks.

> After the IETF, I plan to repost the "body" extension draft in
> preparation to send it towards workgroup last call.

> Two open issues:

> - :binary.  I added it in the last iteration, and now
>   yanked it out again.  It's a neat hack, but I feel
>   like I can't make this work as a serious feature,
>   especially in connection with variables and
>   wilcard matches.

>   The hex space-separated hex pair values look ok to me,
>   graphically, but are unique in the E-mail world.  Cyrus
>   suggested making them =-separated to allow reuse of
>   quoted-printable engines, but the format I was describing
>   is not _quite_ the same, I find =-separated hard to
>   read, and I think people will assume that where
>   quoted-printable works, there's a way of doing
>   base64-encoding, and now we're really getting ridiculous.

>   I don't like the ability my format adds to match against
>   single nybbles.

>   The main use of this - to match against virus signatures -
>   really is better served in virus scanners.

>   QUESTION: Are we okay with throwing out :binary, or
>   is someone using it for something worthwhile?
>   If we want to keep it, how strongly do we feel about
>   using a format that looks more like quoted-printable?

I say "lose it".

> - In the unpublished version on disk now (and appended
>   to this message), I've added an explicit exemption from
>   the variable-setting side effect of matches.  That makes
>   body much easier to implement, but I hate special
>   cases and this is one.   We need to agree that we do
>   think the implementation cost of wildcard-matches with
>   variable-assignments in body is so high that we don't
>   want to do it.

>   QUESTION: Is it okay to have body :matches and
>   :regex scans not set variables?

I think this is a very good idea.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALJp5h007494; Wed, 10 Nov 2004 13:19:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAALJpte007493; Wed, 10 Nov 2004 13:19:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALJmjN007474 for <[e-mail]>; Wed, 10 Nov 2004 13:19:49 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAALJqbW017328 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Wed, 10 Nov 2004 13:19:52 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAALJqbW017328
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=HcnvzKpW8fuOQOXSrVeRcfaRtru4MPnO/ox8dMmUs/OwlFVAczQNt8o1zUpa4obEG ohMCirYNbVYoao6YeYo0buUfWwkie6yeVSOXJTs+A7i/R1VQPb8jOyLNvzpHNOnflmV mte8yEfRlArYWVhDt3L+6ePWx88BBobOVh78psE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAALJq7c082700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Nov 2004 13:19:52 -0800 (PST) (envelope-from [e-mail])
Received: (from jutta@localhost) by lab.smi.sendmail.com (8.12.11/8.12.11/Submit) id iAALJqAE082699 for [e-mail]; Wed, 10 Nov 2004 13:19:52 -0800 (PST) (envelope-from jutta)
From: Jutta Degener <[e-mail]>
Message-Id: <[e-mail]>
Subject: Impending changes to "editheader" draft.
To: [e-mail]
Date: Wed, 10 Nov 2004 13:19:52 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL99f (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 03, 2004 at 11:45:40AM -0500, Cyrus Daboo wrote:
> If any document authors will not be at the meeting, either in person or via 
> jabber, could they please send me privately a summary of the state of their 
> document so I can present that as part of our discussions, thanks.

The "editheader" draft is due for replublication and move towards last
call.

The changes I've made in this pre-publication version closely follow
the workgroup recommendations from the list; in particular, I've
flipped the sense of what should happen if the same message gets filed
twice into the same folder (but with different headers).

The thing I'd like to do before moving this to draft is get rid
of a lot of little parameters on deleteheader that control wich header
where gets deleted.

Right now, deleteheader has the following syntax:

   	"deleteheader"
		[":index" <fieldno: number> [":last"]]
		[COMPARATOR] [MATCH-TYPE]
		<field-name: string>
		[<value-patterns: string-list>]


I want to reduce that to

   	"deleteheader"
		[COMPARATOR] [MATCH-TYPE]
		<field-name: string>
		[<value-patterns: string-list>]


and always delete all instances of the header.

The typical use case for deleteheader is to make sure
a header field that one adds doesn't already exist.
(For example, when adding a header that communicates result
of a spam scan to a client, one may want to first delete
other header fields of the same name.)

The [":index" <fieldno: number> [":last"]] stuff specifies
which single header to delete, and can be used to e.g. edit
out "Received:" lines that one does't want to reveal towards
the outside world.  But part of that can be done by matching
the header _value_; and I don't think the rest of the users
can stay awake long enough through the explanation of how
the :index and :last attribute interact to comfortably
ignore it.  This is a lot of mechanism for very little
use.  Let's get rid of it.

QUESTION: Is there a use case for :index/:last that
makes a compelling argument to keep it?

Network Working Group                                       Jutta Degener
Internet Draft					           Sendmail, Inc.
Expires: May 2005                                           November 2004


                      Sieve -- "editheader" extension
		  <draft-degener-sieve-editheader-03.txt>
		         [PRE-REPUBLICATION DRAFT]


Status of this memo

   This document is an Internet-Draft and is subject to all
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   This document defines two new actions for the "sieve"
   language that add and delete e-mail header fields.


1. Introduction

   Email headers are a flexible and easy to understand means
   of communication between email processors.
   This extension enables sieve scripts to interact with other
   components that consume or produce header fields by allowing
   the script to delete and add header fields.


2. Conventions used.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS] and "Syntax:" label for the definition of action
   and tagged arguments syntax.

   The term "header field" is used here as in [RFC-2822] to mean a
   logical line of an e-mail message header.

   The capability string associated with extension defined in this
   document is "editheader".


3. Action addheader

   Syntax:
   	"addheader" [":last"] <name: string> <value: string>

   The addheader action adds a header field to the existing
   message header.  The name MUST be a valid 7-bit US-ASCII header
   field name as described by [RFC-2822] "field-name" nonterminal.

   If the specified field value does not match the RFC 2822
   "unstructured" nonterminal or exceeds a length limit set by
   the implementation, the implementation MUST either flag an
   error or encode the field using folding white space and the
   encodings described in RFC 2047 or RFC 2231 to be compliant
   with RFC 2822.

   An implementation MAY impose a length limit onto the size of
   the encoded header field; such a limit MUST NOT be less
   than 998 characters, not including the terminating CRLF
   supplied by the implementation.

   By default, the header field is inserted at the beginning of
   the existing header.  If the optional flag ":last" is
   specified, it is appended at the end.

   Example:
	/* Don't redirect if we already redirected */
	if not header :contains "X-Sieve-Filtered"
		["<[e-mail]>", "<[e-mail]>"]
	{
   		addheader "X-Sieve-Filtered" "<[e-mail]>";
		redirect "[e-mail]";
	}


4. Action deleteheader

   Syntax:
   	"deleteheader"
		[":index" <fieldno: number> [":last"]]
		[COMPARATOR] [MATCH-TYPE]
		<field-name: string>
		[<value-patterns: string-list>]

   By default, the deleteheader action deletes all occurrences
   of the named header field.

   The field-name is mandatory and always matched as a
   case-insensitive us-ascii string.  The value-patterns,
   if specified, are matched according to the match type and
   comparator.  If none are specified, all values match.

   The field-name MUST be a valid 7-bit header field name as
   described by the [RFC-2822] "field-name" nonterminal.

   If :index <fieldno> is specified, the attempts to match 
   a value are limited to the header field <fieldno> (beginning
   at 1, the first named header field).  If :last is specified,
   the count is backwards; 1 denotes the last named header field,
   2 the second to last, and so on.  The counting happens
   before the <value-patterns> match, if any;
   
   	deleteheader :index 2 :contains "Received" "via carrier-pidgeon"

   deletes the second "Received:" header field if it contains
   the string "via carrier-pidgeon" (not the second Received: field
   that contains "via carrier-pidgeon").


5. Interaction with Other Sieve Extensions

   Tests and actions such as "exist" or "header" that examine
   header fields MUST examine the current state of a header as
   modified by any actions that have taken place so far.
   
   As an example, the "header" test in the following fragment will
   always evaluate to true, regardless of whether the incoming
   message contained an "X-Hello" header field or not:

	addheader "X-Hello" "World";
	if header :contains "X-Hello" "World"
	{
		fileinto "international";
	}

   Actions that create messages in storage or in transport to
   MTAs MUST store and send messages with the current set of
   header fields.

   For the purpose of weeding out duplicates, a message modified
   by addheader or deleteheader MUST be considered the same as
   the original message.  For example, in an implementation that
   obeys the constraint in [SIEVE] section 2.10.3 and does not deliver
   the same message to a folder more than once, the following
   code fragment

   	keep;
	addheader "X-Flavor" "vanilla";
	keep;

   MUST only file one message.  It is up to the implementation
   to pick which of the redundant "fileinto" or "keep" actions is
   executed, and which ones are ignored.

   The "implicit keep" is thought to be executed at the end of
   the script, after the headers have been modified.  (However,
   a canceled "implicit keep" remains canceled.)


6.  IANA Considerations

    The following template specifies the IANA registration of the Sieve
    extension specified in this document:

    To: [e-mail]
    Subject: Registration of new Sieve extension

    Capability name: editheader
    Capability keyword: editheader
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

    Jutta Degener
    [e-mail]

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.


7. Security Considerations

   Someone with write access to a user's script storage may use this
   extension to generate headers that a user would otherwise be
   shielded from (by a gateway MTA that removes them).

   A sieve filter that removes headers may unwisely destroy
   evidence about the path a header has taken.

   Any change in a message content may interfere with digital
   signature mechanisms that include the header in the signed
   material.  Since normal message delivery adds "Received:"
   header fields to the beginning of a message, many such schemas
   are impervious to headers prefixed to a message, and will
   work with "addheader" unless :last is used.

   Any decision mechanism in a user's filter that is based
   on headers is vulnerable to header spoofing.  For example,
   if the user adds an APPROVED header or tag, a malicious sender
   may add that tag or header themselves.  One way to guard against
   this is to delete or rename any such headers or stamps prior
   to processing the message.


8. Acknowledgments

   Thanks to Eric Allman, Cyrus Daboo, Ned Freed, Philip Guenther,
   Simon Josefsson, Will Lee, Mark E. Mallet, Chris Markle,
   Randall Schwartz, Nigegl Swinson, Kjetil Torgrim Homme, and
   Rand Wacker for extensive corrections and suggestions.


9. Author's Address

   Jutta Degener
   Sendmail, Inc.
   6425 Christie Ave, 4th Floor
   Emeryville, CA 94608

   Email: [e-mail]


10. Discussion

   This section will be removed when this document leaves the
   Internet-Draft stage.

   This draft is intended as an extension to the Sieve mail filtering
   language.  Sieve extensions are discussed on the MTA Filters mailing
   list at <[e-mail]>.  Subscription  requests can
   be sent to <[e-mail]> (send an email
   message with the word "subscribe" in the body).

   More information on the mailing list along with a WWW archive of
   back messages is available at <http://www.imc.org/ietf-mta-filters/>.


10.1 Changes from the previous version

   Changed the duplicate restrictions from "messages with different
   headers MUST be considered different" to their direct opposite,
   "messages with different headers MUST be considered the same,"
   as requested by workgroup members on the mailing list.

   Expanded mention of header signature schemes to Security
   Considerations. 

   Added IANA Considerations section.


Appendices

Appendix A.  References

   [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [SIEVE]    Showalter, T.,  "Sieve: A Mail Filtering Language", RFC 3028,
   	      January 2001.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

Appendix B. Full Copyright Statement

    Copyright (C) The Internet Society 2004. All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Thanks!,

--Jutta <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALIGOm006851; Wed, 10 Nov 2004 13:18:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAALIGWK006850; Wed, 10 Nov 2004 13:18:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALIFdt006811 for <[e-mail]>; Wed, 10 Nov 2004 13:18:15 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAALICtQ016974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Wed, 10 Nov 2004 13:18:12 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAALICtQ016974
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Nu7Ap1e97vfS3SdftT2Yw+5XgAyvV4UQAUkeB4Aw59pDPJZg3k7wXzGXJb0iscfUW 0WeP9d7dMvMhGB8pyTxBTh4NQqjJ5syheUJTY9fXlyf290afeeQxhuGyCBJzOU/zqXK 6dN/2F1iD0jt2QUJ0iUoCIsJ+wQM/qpaLJvzo4c=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAALICSB082167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Nov 2004 13:18:12 -0800 (PST) (envelope-from [e-mail])
Received: (from jutta@localhost) by lab.smi.sendmail.com (8.12.11/8.12.11/Submit) id iAALIC8N082166 for [e-mail]; Wed, 10 Nov 2004 13:18:12 -0800 (PST) (envelope-from jutta)
From: Jutta Degener <[e-mail]>
Message-Id: <[e-mail]>
Subject: Impending changes to "body" draft.
To: [e-mail]
Date: Wed, 10 Nov 2004 13:18:12 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL99f (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 03, 2004 at 11:45:40AM -0500, Cyrus Daboo wrote:
> If any document authors will not be at the meeting, either in person or via 
> jabber, could they please send me privately a summary of the state of their 
> document so I can present that as part of our discussions, thanks.

After the IETF, I plan to repost the "body" extension draft in 
preparation to send it towards workgroup last call.

Two open issues:

- :binary.  I added it in the last iteration, and now
  yanked it out again.  It's a neat hack, but I feel
  like I can't make this work as a serious feature,
  especially in connection with variables and
  wilcard matches.

  The hex space-separated hex pair values look ok to me,
  graphically, but are unique in the E-mail world.  Cyrus
  suggested making them =-separated to allow reuse of
  quoted-printable engines, but the format I was describing
  is not _quite_ the same, I find =-separated hard to
  read, and I think people will assume that where
  quoted-printable works, there's a way of doing
  base64-encoding, and now we're really getting ridiculous.

  I don't like the ability my format adds to match against
  single nybbles.

  The main use of this - to match against virus signatures -
  really is better served in virus scanners.

  QUESTION: Are we okay with throwing out :binary, or 
  is someone using it for something worthwhile?
  If we want to keep it, how strongly do we feel about
  using a format that looks more like quoted-printable?

- In the unpublished version on disk now (and appended
  to this message), I've added an explicit exemption from
  the variable-setting side effect of matches.  That makes
  body much easier to implement, but I hate special
  cases and this is one.   We need to agree that we do
  think the implementation cost of wildcard-matches with
  variable-assignments in body is so high that we don't
  want to do it.

  QUESTION: Is it okay to have body :matches and
  :regex scans not set variables?

Here's my current document version:

Network Working Group                                       Jutta Degener
Internet Draft					           Sendmail, Inc.
Expires: May 2005                                           November 2004


                      Sieve -- "body" extension
		  <draft-degener-sieve-body-03.txt>
		  	
		     [PRE-REPUBLICATION-DRAFT]


Status of this memo

   This document is an Internet-Draft and is subject to all
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   This document defines a new primitive for the "Sieve" language
   that tests for the occurrence of one or more strings in the body
   of an e-mail message.


1. Introduction

   The proposed "body" test checks for the occurrence of one
   or more strings in the body of an e-mail message.
   Such a test was initially discussed for the [SIEVE] base
   document, but was subsequently removed because it was
   thought to be too costly to implement.

   Nevertheless, several server vendors have implemented
   some form of the "body" test.

   This document reintroduces the "body" test as an extension,
   and specifies it syntax and semantics.


2. Conventions used.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS] and "Syntax:" label for the definition of action
   and tagged arguments syntax.

   The capability string associated with extension defined in this
   document is "body".


3. Test body

   Syntax:
   	"body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
   		<key-list: string-list>

   The body test matches text in the body of an e-mail message,
   that is, anything following the first empty line after the header.
   (The empty line itself, if present, is not considered to be part
   of the body.)

   The COMPARATOR and MATCH-TYPE keyword parameters are defined
   in [SIEVE].  The BODY-TRANSFORM is a keyword parameter
   discussed in section 4, below.

   If a message consists of a header only, not followed by an empty
   line, all "body" tests fail, including that for an empty string.

   If a message consists of a header followed only by an empty
   line with no body lines following it, the message is considered
   to have an empty string as a body.


4. Body Transform

   Prior to matching text in a message body, "transformations"
   can be applied that filter and decode certain parts of the body.
   These transformations are selected by a "BODY-TRANSFORM"
   keyword parameter.

   Syntax:
   	  ":raw"
	/ ":content" <content-types: string-list>
	/ ":text"

   The default transformation is :text.


4.1 Body Transform ":raw"

   The ":raw" transform is intended to match against the undecoded
   body of a message.

   If the specified body-transform is ":raw", the [MIME] structure of
   the body is irrelevant.  The implementation MUST NOT remove any
   transfer encoding from the message, MUST NOT refuse to filter
   messages with syntactic errors (unless the environment it is part
   of rejects them outright), and MUST NOT interpret or skip MIME
   headers of enclosed body parts.

   Example:

   	require "body";

	# This will match a message containing the words "MAKE MONEY FAST"
	# in body or MIME headers other than the outermost RFC 822 header,
	# but will not match a message containing the words in a
	# content-transfer-encoded body.

	if body :raw :contains "MAKE MONEY FAST" {
		reject;
	}



4.2 Body Transform ":content"

   If the body transform is ":content", only MIME parts that have
   the specified content-types are selected for matching.

   If an individual content type contains a '/' (slash), it
   specifies a full <type>/<subtype> pair, and matches only
   that specific content type.  If it is the empty string, all
   MIME content types are matched.  Otherwise, it specifies a
   <type> only, and any subtype of that type matches it.

   The search for MIME parts matching the :content specification is
   recursive and automatically descends into multipart and
   message/rfc822 MIME parts.  Once a MIME part has been identified
   as suitable for searching, only its direct contents are searched
   for the key strings.

   For example, a document with "multipart" major content type only
   directly contains the text in its epilogue and prologue section;
   all the user-visible data inside it is directly contained in
   documents with MIME types other than multipart.

   (Nevertheless, matches against container types with an empty
   match string can be useful as tests for the existence of such
   document parts.)

   MIME parts encoded in "quoted-printable" or "base64" content
   transfer encodings MUST be decoded to prior to the match.
   MIME parts in other transfer encodings MAY be decoded, omitted
   from the test, or processed as raw data.

   MIME parts identified as using charsets other than UTF-8 as
   defined in [UTF-8] SHOULD be converted to UTF-8 prior to the match.
   A conversion from US-ASCII to UTF-8 MUST be supported.
   If an implementation does not support conversion of a given
   charset to  UTF-8, it MAY compare against the US-ASCII subset
   of the transfer-decoded character data instead.  Characters from
   documents tagged with charsets that the local implementation
   cannot convert to UTF-8 and text from mistagged documents MAY
   be omitted or processed according to local conventions.

   Search expressions MUST NOT match across MIME part boundaries.
   MIME headers of the containing text MUST NOT be included in the
   data.

   Example:
   	require ["body", "fileinto"];

	# Save any message with any text MIME part that contains the
	# worlds "missile" or "coordinates" in the "secrets" folder. 

	if body :content "text" :contains ["missile", "coordinates"] {
		fileinto "secrets";
	}

	# Save any message with an audio/mp3 MIME part in
	# the "jukebox" folder.

	if body :content "audio/mp3" :contains "" {
		fileinto "jukebox";
	}


4.3 Body Transform ":text"

   The ":text" body transform matches against the results of 
   an implementation's best effort at extracting UTF-8 encoded
   text from a message.

   In simple implementations, :text MAY be treated the same
   as :content "text".

   Sophisticated implementations MAY strip mark-up from the text
   prior to matching, and MAY convert media types other than text
   to text prior to matching.
   
   (For example, they may be able to convert proprietary text
   editor formats to text or apply optical character recognition
   algorithms to image data.)



5. Interaction with Other Sieve Extensions

   Any extension that extends the grammar for the COMPARATOR or
   MATCH-TYPE nonterminals will also affect the implementation of
   "body".
  
   The [REGEX] extension can place a considerable load on a system
   when applied to whole bodies of messages, especially when
   implemented naively or used maliciously.

   Regular and wildcard expressions used with "body" are exempt
   from the side effects described in [VARIABLES].  That is, they
   do not set numbered variables ${1}, ${2}... to the input
   values corresponding to wild card sequences in the matched
   pattern.  However, variable references in the pattern string
   are evaluated as described in the draft, if the extension
   is present.


6.  IANA Considerations

    The following template specifies the IANA registration of the Sieve
    extension specified in this document:

    To: [e-mail]
    Subject: Registration of new Sieve extension

    Capability name: body
    Capability keyword: body
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

    Jutta Degener
    [e-mail]

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.


7. Security Considerations

   The system MUST be sized and restricted in such a manner that
   even malicious use of body matching does not deny service to
   other users of the host system.

   Filters relying on string matches in the raw body of an e-mail
   message may be more general than intended.  Text matches are no
   replacement for a virus or spam filtering system.


8. Acknowledgments

   This document has been revised in part based on comments and
   discussions that took place on and off the SIEVE mailing list.
   Thanks to Cyrus Daboo, Ned Freed, Simon Josefsson, Mark E. Mallet,
   Chris Markle, Greg Shapiro, Tim Showalter, Nigel Swinson,
   and Dowson Tong for reviews and suggestions.


9. Author's Address

   Jutta Degener
   Sendmail, Inc.
   6425 Christie Ave, 4th Floor
   Emeryville, CA 94608

   Email: [e-mail]


10. Discussion

   This section will be removed when this document leaves the
   Internet-Draft stage.

   This draft is intended as an extension to the Sieve mail filtering
   language.  Sieve extensions are discussed on the MTA Filters mailing
   list at <[e-mail]>.  Subscription  requests can
   be sent to <[e-mail]> (send an email
   message with the word "subscribe" in the body).

   More information on the mailing list along with a WWW archive of
   back messages is available at <http://www.imc.org/ietf-mta-filters/>.


10.1 Changes from the previous version

   Made "body" exempt from variable-setting side effects in the presence
   of the "variables" extension and wild cards.  It's too hard to implement.

   Removed :binary.  It's uglier and less useful than it needs to be
   to bother.

   Added IANA section.



Appendices

Appendix A.  References

   [KEYWORDS] 	Bradner, S., "Key words for use in RFCs to Indicate
   		Requirement Levels", RFC 2119, March 1997.

   [MIME] 	Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   		Extensions (MIME) Part One: Format of Internet Message
		Bodies", RFC 2045, November 1996.

   [SIEVE] 	Showalter, T.,  "Sieve: A Mail Filtering Language", RFC 3028,
		January 2001.

   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of Unicode
                and ISO 10646", RFC 2044, October 1996.

   [VARIABLES] Homme, K.T., "Sieve -- Variables Extension",
               draft-homme-sieve-variables-04.txt, September 2004.


Appendix B. Full Copyright Statement

    Copyright (C) The Internet Society 2002,2003. All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


--Jutta <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9HTlbL020992; Tue, 9 Nov 2004 09:29:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9HTlYK020991; Tue, 9 Nov 2004 09:29:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from web12305.mail.yahoo.com (web12305.mail.yahoo.com [216.136.173.103]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA9HTkRW020985 for <[e-mail]>; Tue, 9 Nov 2004 09:29:46 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 60567 invoked by uid 60001); 9 Nov 2004 17:29:48 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=pJGRD0BFL0QeRmsHOhMQQxVpJuQoKhUMGAPQOuaPA5jT6Aj55x4Ywca6C7DhD1KPj7IH53TpQH9JFczNjl8szHqmzfhGXDBNZqfThKizJkuVT0+9BSp34FFmPKgqQ2Wa5WIN95qlT54yjnl9kzswTdGHpFPqNezhGDhjAACLS4k=  ;
Message-ID: <[e-mail]>
Received: from [64.76.145.107] by web12305.mail.yahoo.com via HTTP; Tue, 09 Nov 2004 17:29:44 GMT
Date: Tue, 9 Nov 2004 17:29:44 +0000 (GMT)
From: German Gutierrez <[e-mail]>
Subject: Sieve for blank email 
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi

How can i do for filter Blank E-mail , with no Subject
and No Body . 

What is the Sieve filter for it ?

I'm using CriticalPath mail platform

Regards
German 


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5JLrTT096772; Fri, 5 Nov 2004 11:21:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5JLrmG096771; Fri, 5 Nov 2004 11:21:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5JLm3q096716 for <[e-mail]>; Fri, 5 Nov 2004 11:21:48 -0800 (PST) (envelope-from [e-mail])
Received: from jutta.sendmail.com ([10.210.202.38]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iA5JLnCD002512; Fri, 5 Nov 2004 11:21:49 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iA5JLnCD002512
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=aqACQoqpuixelTpn/ptGddc7QXk/g/sSg/cNeWMiWlE0mK29b+dpjTEhGFG7uK5Sh Ce+9+WwSh36xk4IA+FlSnuzWxEBpPumg6LYD4Ay9efp8X73GV/ttn0xyHgwZJ0/0KaL quwp2AyEV9Ta99+ltd61rdhrCSHMATzF6EkM5T0=
Received: by jutta.sendmail.com (Postfix, from userid 500) id 13F3917999; Fri,  5 Nov 2004 11:21:37 -0800 (PST)
Date: Fri, 5 Nov 2004 11:21:37 -0800
From: Jutta Degener <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Tim Showalter <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Action Interaction
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Nov 05, 2004 at 11:30:26AM +0000, Alexey Melnikov wrote:
> Tim Showalter wrote:
> >In general, I agree, and I will try to incorporate these changes into 
> >the next draft.
> >
> >Alexey Melnikov wrote:
> >
> >>3). Need to state that "reject" and "discard" are incompatible.
> >
> >They aren't clearly incompatible.  If keep+discard aren't 
> >incompatible, why would reject+discard be incompatible?
> 
> Section 2.10.4 says:
>   Implementations SHOULD prohibit reject when used with other actions.

Right, so it depends on whether implementations implement
this SHOULD.  (With ours, it's configurable.)
I'm not sure why something other than the quoted statement is needed.

But I don't follow this logic:

> I frankly don't care either way, but this must clearly be stated. Either
> a). when both discard and reject are requested, reject is executed

Apart from the SHOULD in 2.10.4 (and the application-level
considerations behind it), I don't see what the technical
problem with executing discard and reject is.  Discard cancels
the implicit keep.  Reject sends a nastygram and cancels the implicit
keep.  So, discard + reject do the same as reject alone, just
like discard + fileinto do the same as fileinto alone.

Not because someone explicitly said so; the math just works
out that way.

> or
> b). the last one of discard/reject is executed (i.e. discard also 
> cancels a previous reject)

No!  Please, no time travel.

> or
> c). discard and reject are incompatible (as discard is a silent reject 
> and one can't reject silently and not silently at the same time).

That would be the right thing to do for implementations that
implement the SHOULD in 2.10.4.  (Not because "discard is a
silent reject"; it isn't, although that may be the way some
people chose to think about it.)

The normal *user* idea of "discard;" is usually better
expressed by "discard; stop;" -- don't file it, and don't
do anything else with it, either, because after something
is discarded (in the English sense of the term), it is gone.
But that's not how the sieve discard action is defined--it
just cancels the implicit keep.

Jutta



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5BUm4G097283; Fri, 5 Nov 2004 03:30:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5BUmTf097280; Fri, 5 Nov 2004 03:30:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5BUhdJ097211 for <[e-mail]>; Fri, 5 Nov 2004 03:30:43 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 5 Nov 2004 11:30:29 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 11:30:26 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Tim Showalter <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: Action Interaction
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:

> In general, I agree, and I will try to incorporate these changes into 
> the next draft.
>
> Alexey Melnikov wrote:
>
>> 3). Need to state that "reject" and "discard" are incompatible.
>
> They aren't clearly incompatible.  If keep+discard aren't 
> incompatible, why would reject+discard be incompatible?

Section 2.10.4 says:
   Implementations SHOULD prohibit reject when used with other actions.

I frankly don't care either way, but this must clearly be stated. Either
a). when both discard and reject are requested, reject is executed
or
b). the last one of discard/reject is executed (i.e. discard also 
cancels a previous reject)
or
c). discard and reject are incompatible (as discard is a silent reject 
and one can'te reject silently and not silently at the same time).

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4K2IaJ017282; Thu, 4 Nov 2004 12:02:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4K2ICw017281; Thu, 4 Nov 2004 12:02:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4K2Dmp017247 for <[e-mail]>; Thu, 4 Nov 2004 12:02:17 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.1.157] (linux5.apptran.com [192.168.1.157] (may be forged)) (authenticated bits=0) by mail.apptran.com (8.12.10/8.12.10) with ESMTP id iA4K2GL2024939; Thu, 4 Nov 2004 12:02:17 -0800
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 12:02:16 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: Action Interaction
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In general, I agree, and I will try to incorporate these changes into 
the next draft.

Alexey Melnikov wrote:
> 3). Need to state that "reject" and "discard" are incompatible.

They aren't clearly incompatible.  If keep+discard aren't incompatible, 
why would reject+discard be incompatible?

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HmF9h066298; Thu, 4 Nov 2004 09:48:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HmFuE066297; Thu, 4 Nov 2004 09:48:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HmADX066234 for <[e-mail]>; Thu, 4 Nov 2004 09:48:15 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 4 Nov 2004 17:48:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 17:48:01 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: IETF MTA Filters List <[e-mail]>
Subject: Action Interaction
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think there is more than one problem in this area, so I will try to 
summarize a list of issues (all section #s are for the RFC 3028). Please 
feel free to correct me and add more issues to the list:

1). In section "2.10.2.  Implicit Keep"

 >   An implicit keep is performed if a message is not written to a
 >   mailbox, redirected to a new address, or explicitly thrown out.  That
 >   is, if a fileinto, a keep, a redirect, or a discard is performed, an
 >   implicit keep is not.

"reject" should be added to the list.

2). Section "2.10.4.  Limits on Numbers of Actions" states:

 >   Implementations SHOULD prohibit reject when used with other actions.

It would be nice if this is mentioned where "reject" is described (i.e. 
in section 4.1.)

3). Need to state that "reject" and "discard" are incompatible.

4). In section "10.     Security Considerations":

 >   It is equally important that implementations sanity-check the user's
 >   scripts, and not allow users to create on-demand mailbombs.  For
 >   instance, an implementation that allows a user to reject or redirect
 >   multiple times to a single message

Section 2.10.4 says:

   Implementations MUST prohibit more than one reject.

So "more than one reject" is illegal.

 > might also allow a user to create
 >   a mailbomb triggered by mail from a specific user.  Site- or
 >   implementation-defined limits on actions are useful for this.

5). Ok, that might be obvious, but I want the document to be explicit on 
this: if an implementation allows for multiple fileinto/redirect for the 
same input message, than the document should state that all 
fileinto/redirect should be honored, not the last executed one.
Also a clarification that redirect and fileinto are compatible, might be 
a good idea.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4F8LJA002511; Thu, 4 Nov 2004 07:08:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4F8L1i002510; Thu, 4 Nov 2004 07:08:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4F8JoA002474 for <[e-mail]>; Thu, 4 Nov 2004 07:08:20 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id iA4F8Fh431870 for <[e-mail]>; Thu, 4 Nov 2004 10:08:16 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id iA4F8F439608 for <[e-mail]>; Thu, 4 Nov 2004 10:08:15 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id iA4F8F439606 for <[e-mail]>; Thu, 4 Nov 2004 10:08:15 -0500
Received: from saturn ([9.2.43.227]) by mars.watson.ibm.com ID IMFd1099580895.1; Thu, 04 Nov 2004 10:08:15 -0400
Date: Thu, 04 Nov 2004 10:08:15 -0500
From: Barry Leiba <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Re: Meeting in DC
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> We have a BOF meeting slot for next week: Thursday  1530-1730. [...]
> 
> I'm leaving Wednesday night, so expect mail from me.
> Anyone up for a lunch or evening meeting on Monday?

I'll be leaving on Thursday early afternoon, so I won't be able to make
it either.  I'll talk with Cyrus on Monday.  Yes, I think either a
lunch or dinner meeting on Monday would be great.  We can have a
pre-BOF lunch BOF, or something like that.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3JoIxF091153; Wed, 3 Nov 2004 11:50:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3JoItU091152; Wed, 3 Nov 2004 11:50:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3JoDTe091062 for <[e-mail]>; Wed, 3 Nov 2004 11:50:13 -0800 (PST) (envelope-from [e-mail])
Received: from jutta.sendmail.com ([10.210.202.33]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iA3JoAAE019339; Wed, 3 Nov 2004 11:50:11 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iA3JoAAE019339
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=SpKkPV8hVqR72PKaywemsb6VCMt8KjLMBZVlrmCWHeh355Y8zvozjx5Znpjupk4t9 GbU2sASgGxFMyuEQugkFmHkRQ6CnfXRSH6aAs/cOrGQTlIu3EATOtQnGNvgocpHzS6n ai27NAUzY1QfiGdLE4ObiE7MRq1uXrBArSA37d0=
Received: by jutta.sendmail.com (Postfix, from userid 500) id DCF4F17999; Wed,  3 Nov 2004 11:50:04 -0800 (PST)
Date: Wed, 3 Nov 2004 11:50:04 -0800
From: Jutta Degener <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
Subject: Re: Meeting in DC
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 03, 2004 at 11:45:40AM -0500, Cyrus Daboo wrote:
> 
> Hi folks,
> We have a BOF meeting slot for next week: Thursday  1530-1730. [...]

I'm leaving Wednesday night, so expect mail from me.
Anyone up for a lunch or evening meeting on Monday?

--Jutta



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GlJBN014990; Wed, 3 Nov 2004 08:47:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GlJHs014989; Wed, 3 Nov 2004 08:47:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GlHOK014974 for <[e-mail]>; Wed, 3 Nov 2004 08:47:18 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA3FfX6E011217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2004 10:41:34 -0500
Date: Wed, 03 Nov 2004 11:47:14 -0500
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: updated variables draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0a2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Tuesday, November 2, 2004 4:24:36 AM EST +0100 Kjetil Torgrim Homme 
<[e-mail]> wrote:

> I tried to submit an update, but it was rejected since IETF is in
> session.  problem is, I'm going away for a month long holiday.
>
> feel free to submit it if possible and necessary.

OK - I will submit this to the repository once it opens. I think we are at 
the point where we should issue a last call on this document, but lets have 
one more pass over it with -05 and discuss at next week's meeting.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GjjeT014184; Wed, 3 Nov 2004 08:45:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GjjKf014183; Wed, 3 Nov 2004 08:45:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Gje1j014129 for <[e-mail]>; Wed, 3 Nov 2004 08:45:45 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA3Fdx6E011174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 3 Nov 2004 10:40:01 -0500
Date: Wed, 03 Nov 2004 11:45:40 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Meeting in DC
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
We have a BOF meeting slot for next week: Thursday  1530-1730. The agenda 
for the meeting is posted here: <http://www.ietf.org/ietf/04nov/sieve.txt>. 
We have time on the agenda to discuss all the current set of documents as 
well as start off our discussion of the base spec revision.

If any document authors will not be at the meeting, either in person or via 
jabber, could they please send me privately a summary of the state of their 
document so I can present that as part of our discussions, thanks.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GQCkf005689; Wed, 3 Nov 2004 08:26:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GQCdI005688; Wed, 3 Nov 2004 08:26:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GQBQw005682 for <[e-mail]>; Wed, 3 Nov 2004 08:26:11 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23831; Wed, 3 Nov 2004 11:26:11 -0500 (EST)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Reply-to: [e-mail]
Subject: WG Review: Sieve Mail Filtering (sieve)
Date: Wed, 03 Nov 2004 11:26:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new IETF working group has been proposed in the Applications Area.  
The IESG has not made any determination as yet. The following description 
was submitted, and is provided for informational purposes only. Please send 
your comments to the IESG mailing list ([e-mail]) by November 10th.

Sieve Mail Filtering (sieve)
============================

Current Status: Proposed Working Group

Description of the group:

The sieve mail filtering language specified in RFC 3028 has now been
implemented in a wide variety of user agents (UAs), mail delivery agents
(MDAs), and mail transfer agents (MTAs). Several extensions have been
specified (RFCs 3431, 3598, 3685, 3894) and have also been widely
implemented. Several additional sieve extensions have been defined in
various internet-drafts.

All of these documents are individual submissions; up to this point
work on sieve has been done informally and not under the auspices of
any IETF working group.

The sieve working group is being chartered to:

(1) Revise the base sieve specification, RFC 3028, with the intention of
moving it to draft standard. Substantive additions or revisions to the
base specification are out of scope of this working group. However, the
need to loosen current restrictions on side effects of tests as well as
the need for a normative reference to the newly-defined comparators
registry may necessitate a recycle at proposed.

(2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
spamtest/virustest (RFC 3685), and copy (RFC 3894) extension
specifications, again with the intention of making a move to
draft standard possible. It may be necessary to recycle some or all
of these documents at proposed, depending on the scope of any changes.

(3) Finalize and publish the sieve extensions as proposed standards:

(a) Variables (draft-homme-sieve-variables-04.txt)
(b) Vacation action (draft-showalter-sieve-vacation-05.txt)
(c) Message body tests (draft-degener-sieve-body-02.txt)
(d) Regular expressions (draft-murchison-sieve-regex-07.txt)
(e) MIME part tests (draft-daboo-sieve-mime-00.txt)
(f) Notification action (draft-martin-sieve-notify-02.txt)
(g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt)
(h) Header editing actions (draft-degener-sieve-editheader-01.txt)
(i) Reject before delivery (draft-elvey-refuse-sieve-01.txt)

Additional drafts may be added this list, but only via a charter
revision. There must also be demonstrable willingness in the sieve
development community to actually implement a given extension before
it can be added to this charter.

Some aspects of sieve have complex internationalization issues; the working
group will seek out internationalization expertise as needed to complete its
work.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FRWel081351; Wed, 3 Nov 2004 07:27:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FRWPa081350; Wed, 3 Nov 2004 07:27:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FRV3J081314 for <[e-mail]>; Wed, 3 Nov 2004 07:27:31 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.43) id 1CPN2r-0006zc-5q for [e-mail]; Wed, 03 Nov 2004 16:27:33 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #2) id 1CPN2r-00049y-48 for [e-mail]; Wed, 03 Nov 2004 16:27:33 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.43 #12) id 1CPN2o-0000Ac-Q2 for [e-mail]; Wed, 03 Nov 2004 16:27:30 +0100
To: [e-mail]
Subject: Re: new vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 03 Nov 2004 16:27:30 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >                     (The SMTP MAIL FROM address should be available in
> >      the Return-path: header field if sieve processing occurs after
> >      final delivery.)
>
> > That's not the case for bounces.

> Mailer-daemon normally appears in the From: header, not in the MAIL FROM
> or return-path.

Oops, you are right, and the flood of vacation responses origins from
systems responding to From:, not Return-Path:.  Just forget about that
part of my mail.

Sorry about the confusion,

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FCsJH075622; Wed, 3 Nov 2004 07:12:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FCsUf075621; Wed, 3 Nov 2004 07:12:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FCrBd075586 for <[e-mail]>; Wed, 3 Nov 2004 07:12:53 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 03 Nov 2004 07:12:49 -0800 (PST)
Date: Wed, 03 Nov 2004 07:10:04 -0800 (PST)
From: [e-mail]
Subject: Re: new vacation draft
In-reply-to: "Your message dated Wed, 03 Nov 2004 12:48:20 +0100" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> There is one (new?) problem in Section 3.2:

>                     (The SMTP MAIL FROM address should be available in
>      the Return-path: header field if sieve processing occurs after
>      final delivery.)

> That's not the case for bounces.

I must be missing something here. A bounce message normally has an empty
MAIL FROM. This means that the return-path would also be empty, or not
provided, or whatever, and the lack of this information should be sufficient
to say "don't sent a vacation notice".

> A bunch software writers thinks
> different and as a result, the local part mailer-daemon at larger sites
> is flooded with vacation responses of various systems real bad.  I know
> that the Sieve vacation extension tries to avoid that by not responding to
> well known addresses, but that does not make the above statement correct.
> I suggest to remove references to "Return-path:".

Mailer-daemon normally appears in the From: header, not in the MAIL FROM
or return-path.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3BmhrX077868; Wed, 3 Nov 2004 03:48:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3BmhMi077867; Wed, 3 Nov 2004 03:48:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3BmeIA077570 for <[e-mail]>; Wed, 3 Nov 2004 03:48:43 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.43) id 1CPJck-0007gi-J4 for [e-mail]; Wed, 03 Nov 2004 12:48:22 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #2) id 1CPJck-0000kg-H4 for [e-mail]; Wed, 03 Nov 2004 12:48:22 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.43 #12) id 1CPJci-00005V-Br for [e-mail]; Wed, 03 Nov 2004 12:48:20 +0100
To: [e-mail]
Subject: Re: new vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 03 Nov 2004 12:48:20 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I generally believe this reflects the last round of changes, but there 
> were some editorial comments that I felt I couldn't incorporate becaue I 
> couldn't improve on my text.  If you have editorial suggestions, text 
> would be greatly appreciated.

Overall, I am happy with the new version.  Now, my list of implementation
notes mostly consists of the fact that message composition when using
":mime" is not defined anywhere and that there is a conflict whether to
use "Re: " or "Auto: ".  Further, "Re: " is to be taken as a literal
string, not as "[rR][eE]: *", as some older mail/news clients used.
I would be glad if a new version could state that clearly, just to be on
the safe side.

There is one (new?) problem in Section 3.2:

                    (The SMTP MAIL FROM address should be available in
     the Return-path: header field if sieve processing occurs after
     final delivery.)

That's not the case for bounces.  A bunch software writers thinks
different and as a result, the local part mailer-daemon at larger sites
is flooded with vacation responses of various systems real bad.  I know
that the Sieve vacation extension tries to avoid that by not responding to
well known addresses, but that does not make the above statement correct.
I suggest to remove references to "Return-path:".

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA31vdQU003372; Tue, 2 Nov 2004 17:57:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA31vckS003366; Tue, 2 Nov 2004 17:57:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA31vX0i003312 for <[e-mail]>; Tue, 2 Nov 2004 17:57:38 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.1.157] (linux5.apptran.com [192.168.1.157] (may be forged)) (authenticated bits=0) by mail.apptran.com (8.12.10/8.12.10) with ESMTP id iA31vcL2019463 for <[e-mail]>; Tue, 2 Nov 2004 17:57:39 -0800
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 2004 17:57:38 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: new vacation draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Version 06 of the vacation draft was posted to the Internet-Drafts 
repository.  I intend to last call this real soon (immediately after the 
upcoming IETF meeting).  I apologize for not having official notice sent 
here, but I forgot to ask for it.

I generally believe this reflects the last round of changes, but there 
were some editorial comments that I felt I couldn't incorporate becaue I 
couldn't improve on my text.  If you have editorial suggestions, text 
would be greatly appreciated.

http://www.ietf.org/internet-drafts/draft-showalter-sieve-vacation-06.txt

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA23Otrt090505; Mon, 1 Nov 2004 19:24:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA23OtkZ090504; Mon, 1 Nov 2004 19:24:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA23OrCp090459 for <[e-mail]>; Mon, 1 Nov 2004 19:24:54 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1COpI0-0002Yq-8I for [e-mail]; Tue, 02 Nov 2004 04:24:56 +0100
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1COpHq-0001Ip-99 for [e-mail]; Tue, 02 Nov 2004 04:24:46 +0100
Subject: updated variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: multipart/mixed; boundary="=-2p6Q5THmTXdYlTaCY60X"
Date: Tue, 02 Nov 2004 04:24:36 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-0.mozer.2) 
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=1.999, required 12, NEW_DOMAIN_EXTENSIONS 2.00)
X-UiO-Spam-score: s
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=-2p6Q5THmTXdYlTaCY60X
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I tried to submit an update, but it was rejected since IETF is in
session.  problem is, I'm going away for a month long holiday.

feel free to submit it if possible and necessary.
-- 
Kjetil T.

--=-2p6Q5THmTXdYlTaCY60X
Content-Disposition: attachment; filename=draft-homme-sieve-variables-05.txt
Content-Type: text/plain; name=draft-homme-sieve-variables-05.txt; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit







Network Working Group                                        K. T. Homme
Updates: 3028
Document: draft-homme-sieve-variables-05.txt          University of Oslo
Expires May 15, 2005                                          3 Nov 2004



           Sieve Mail Filtering Language: Variables Extension



Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.


Abstract

   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This 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.




Homme                                                           [Page 1]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


1.  Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.


1.1.  Discussion

   This draft is intended to be an extension to the Sieve mail filtering
   language, available from the RFC repository as
   <ftp://ftp.ietf.org/rfc/rfc3028.txt>.

   This draft and the Sieve language itself are being discussed on the
   MTA Filters mailing list at <[e-mail]>.  Subscription
   requests can be sent to <[e-mail]> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.


1.2.  Noted Changes

1.2.1.  Changes since -00

a)   allow generic time zone names, without requiring implementations to
     support it.  added a "${timezone}" variable so that the user can
     check if the implementation does support the time zone name he
     wants.  the default time zone was changed to localtime again.

b)   allow back references from :matches as well as :regex.

c)   added a section on implementation limits.

d)   clarified global scope so that it spans include.

e)   clarified that this draft only affects scripts which require
     "variables".

f)   changed modifiers into being tagged arguments for SET, added
     precedence table.

g)   added optional COMPARATOR to SET to solve the internationalisation
     problem with :lower etc.

h)   the name of the variable being SET is passed in a string to conform
     with overall Sieve grammar.  this string is explicitly disallowed
     from containing variable references.




Homme                                                           [Page 2]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


1.2.2.  Changes since -01

a)   clarify that a character is a Unicode character.

b)   added paragraph warning against relying on Sieve for virus checking
     to security section.

c)   added a paragraph defining constant string.

d)   added namespace to grammar.

e)   removed SETDATE.

f)   added wording and example requiring short-circuiting of test
     evaluation.


1.2.3.  Changes since -02

a)   add references to Unicode and UTF-8, also more boilerplate

b)   fixed a meaningless example.

c)   changed term "numeric variables" to "numbered variables" to reduce
     the chance of it being interpreted as variables holding integer
     values.

d)   allow future extensions to access the raw string value.

e)   an unsuccessful match does NOT reset the numbered variables.

f)   added definition of "string :count"

g)   exceeding implementation limits on variable lengths should not make
     scripts abort.


1.2.4.  Changes since -03

a)   clarify short-circuiting.

b)   editorial changes.


1.2.4.1.  Changes since -04

a)   the wildcards in :matches was changed from greedy to non-greedy to
     better support "principle of least surprise".  added example to



Homme                                                           [Page 3]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


     illustrate the difference.

b)   add definition of "variable"; clarify grammar is based on [SIEVE];
     clarify role of namespaces; add informative references for [REGEX]
     and [SPAMTEST]; add normative reference for [RELATIONAL]

c)   the use of unsupported numbered variables must be flagged as a
     syntax error by implementations.


1.3.  Open Issues

   This extension is in conflict with a MUST in [SIEVE] 2.4: "Tests MUST
   NOT have side effects."  This document therefore can't leave draft
   status until a revised Sieve specification has been accepted by the
   IESG.  No significant changes to this draft are foreseen before
   submission as a proposed standard.


2.  Introduction

   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing named data.  The mechanisms
   detailed in this document will only apply to Sieve scripts that
   include a require clause for the "variables" extension.  The require
   clauses themselves are not affected by this extension.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS] and [ABNF].  The grammar builds on the grammar of
   [SIEVE].  In this document, "character" means a [UNICODE] character,
   which may consist of multiple octets coded in [UTF-8], and "variable"
   is a named reference to data stored or read back using the mechanisms
   of this extension.


3.  Capability Identifier

   The capability string associated with the extension defined in this
   document is "variables".


4.  Interpretation of strings

   This extension changes the semantics of quoted-string, multi-line-
   literal and multi-line-dotstuff found in [SIEVE] to enable the
   inclusion of the value of variables.

   When a string is evaluated, substrings matching variable-ref SHALL be



Homme                                                           [Page 4]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


   replaced by the value of variable-name.  Only one pass through the
   string SHALL be done.  Variable names are case insensitive, so "foo"
   and "FOO" refer to the same variable.  Unknown variables are replaced
   by the empty string.

      variable-ref        =  "${" variable-name "}"
      variable-name       =  num-variable / *namespace identifier
      namespace           =  identifier "."
      num-variable        =  1*DIGIT

   Examples:
      "&%${}!"     => unchanged, as the empty string is an illegal
                      identifier
      "${doh!}"    => unchanged, as "!" is illegal in identifiers

      The variable company holds the value "ACME".  No other variables
      are set.

      "${full}"    => the empty string
      "${company}" => "ACME"
      "${President, ${Company} Inc.}"
                   => "${President, ACME Inc.}"

   The expanded string MUST use the variable values which are current
   when control reaches the statement the string is part of.

   Strings where no variable substitutions take place are referred to as
   constant strings.  Future extensions may specify that passing non-
   constant strings as arguments to its actions or tests is an error.

   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

   Tests or actions in future extensions may need to access the
   unexpanded version of the string argument and, e.g., do the expansion
   after setting variables in its namespace.  The design of the
   implementation should allow this.


4.1.  Quoting

   The semantics of quoting using backslash are not changed: backslash
   quoting is resolved before doing variable substitution.

   Examples:
      "${fo\o}"  => ${foo}  => the expansion of variable foo.



Homme                                                           [Page 5]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


      "${fo\\o}" => ${fo\o} => illegal identifier => left verbatim.
      "\${foo}"  => ${foo}  => the expansion of variable foo.
      "\\${foo}" => \${foo} => a backslash character followed by the
                               expansion of variable foo.

   If it is required to include a character sequence such as "${beep}"
   verbatim in a text literal, the user can define a variable to
   circumvent expansion to the empty string.

   Example:
      set "dollar" "$";
      set "text" "regarding ${dollar}{beep}";


4.2.  Numbered variables

   The decimal value of the numbered variable name will index the list
   of matching strings from the most recently evaluated successful match
   of type ":matches" or ":regex" (see [REGEX]).  The list is empty if
   no match has been successful.

   For ":matches", the list will contain one string for each wildcard
   ("?" and "*") in the match pattern.  Each string holds what the
   corresponding wildcard expands to, possibly the empty string.  The
   wildcards match as little as possible (non-greedy matching).

   For ":regex", the list will contain the strings corresponding to the
   group operators.  The groups are ordered by the position of the
   opening parenthesis, from left to right.  Note that in regular
   expressions, expansions match as much as possible (greedy matching).

   The first string in the list has index 1.  If the index is out of
   range, the empty string will be substituted.  Index 0 returns the
   number of strings in the list as a decimal number.

   The interpreter MUST short-circuit tests, ie. not perform more tests
   than necessary to find the result.  Evaluation order MUST be left to
   right.  If a test has two or more list arguments, the implementation
   is free to choose which to iterate over first.

   Example:

      require [ "fileinto", "regex", "variables" ];

      if header :regex "List-ID" "<(.*)@" {
          fileinto "lists.${1}"; stop;
      }




Homme                                                           [Page 6]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


      # This usually gives the same result as the above
      if header :matches "List-ID" "*<*@*" {
          fileinto "lists.${2}"; stop;
      }

      # Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :regex "Subject" "^[(.*)] (.*)$" {
          # ${1} will hold "acme-users] fwd"
      }
      if header :matches "Subject" "[*] *" {
          # ${1} will hold "acme-users"
          fileinfo "lists.${1}"; stop;
      }

      if address :matches [ "To", "Cc" ] "coyote@**.com" {
          # ${0} is always "2", and ${1} is always the empty string.
          fileinto "business.${2}"; stop;
      } else {
          # Control can't reach this block if any match was
          # successful, so ${0} is always "0" here.
      }

      if anyof (true, address :domain :matches "To" "*.com") {
          # Second test is never evaluated, so ${0} is still "0"
          stop;
      }


5.  Action set

   Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>

   The "set" action stores the specified value in the variable
   identified by name.  The name MUST be a constant string and conform
   to the syntax of identifier.  An illegal name MUST cause a syntax
   error.

   The default comparator is "i;ascii-casemap".  The comparator only
   affects the result when certain modifiers are used.

   All variables have global scope: they are visible until processing
   stops.  Variable names are case insensitive.

   Example:
      set "honorific"  "Mr";
      set "first_name" "Wile";
      set "last_name"  "Coyote";



Homme                                                           [Page 7]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


      set "vacation" text:
      Dear ${HONORIFIC} ${last_name},
      I'm out, please leave a message after the meep.
      .
      ;

   "set" does not affect the implicit keep.


5.1.  Modifiers

   Modifiers are applied on a value before it is stored in the variable.
   Modifier names are case insensitive.  Unknown modifiers MUST yield a
   syntax error.  More than one modifier can be specified, in which case
   they are applied according to this precedence list, highest value
   first:


                      +-----------------------------+
                      | Precedence     Modifier     |
                      +-----------------------------+
                      |     3          :lower       |
                      |                :upper       |
                      +-----------------------------+
                      |     2          :lowerfirst  |
                      |                :upperfirst  |
                      +-----------------------------+
                      |     1          :length      |
                      +-----------------------------+

   If two or more modifiers of the same precedence are used, they can be
   applied in any order.

   Examples:
      set "a" "juMBlEd lETteRS";             => "juMBlEd lETteRS"
      set :length "b" "${a}";                => "15"
      set :lower "b" "${a}";                 => "jumbled letters"
      set :upperfirst "b" "${a}";            => "JuMBlEd lETteRS"
      set :upperfirst :lower "b" "${a}";     => "Jumbled letters"


5.1.1.  Modifier ":length"

   The value is the decimal number of characters in the expansion,
   converted to a string.






Homme                                                           [Page 8]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


5.1.2.  Case modifiers

   These modifiers change the letters of the text from upper to lower
   case or vice versa.  The implementation MUST support US-ASCII, but is
   not required to handle the entire Unicode repertoire.  The comparator
   specified SHOULD be consulted to establish which locale to use.


5.1.2.1.  Modifier ":upper"

   All lower case letters are converted to their upper case counterpart.


5.1.2.2.  Modifier ":lower"

   All upper case letters are converted to their lower case counterpart.


5.1.2.3.  Modifier ":upperfirst"

   The first character of the string is converted to upper case if it is
   a letter and set in lower case.  The rest of the string is left
   unchanged.


5.1.2.4.  Modifier ":lowerfirst"

   The first character of the string is converted to lower case if it is
   a letter and set in upper case.  The rest of the string is left
   unchanged.


6.  Test string

   Syntax: string [MATCH-TYPE] [COMPARATOR]
           <source: string-list> <key-list: string-list>

   The "string" test evaluates to true if any of the source strings
   matches any key.  The type of match defaults to ":is".

   The "relational" extension [RELATIONAL] adds a match type called
   ":count".  The count of a single string is 0 if it is the empty
   string, or 1 otherwise.  The count of a string list is the sum of the
   counts of the member strings.







Homme                                                           [Page 9]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


7.  Implementation Limits

   An implementation of this draft MUST support at least 128 distinct
   variables.  The supported length of variable names MUST be at least
   32 characters.  Each variable MUST be able to hold at least 4000
   characters.  Attempts to set the variable to a value larger than what
   the implementation supports SHOULD be reported as an error at
   compile-time if possible.  If the attempt is discovered during run-
   time, the value SHOULD be truncated and it MUST NOT be treated as an
   error.

   Numbered variables ${1} through ${9} MUST be supported.  References
   to higher indices than the implementation supports MUST be treated as
   a syntax error which SHOULD be discovered at compile-time.


8.  Security Considerations

   When numbered variables are used, and the author of the script isn't
   careful, strings can contain arbitrary values controlled by the
   sender of the e-mail.

   The introduction of variables makes advanced decision making easier
   to write, but since no looping construct is provided, all Sieve
   scripts will terminate in an orderly manner.

   Sieve filtering should not be relied on as a security measure against
   hostile e-mail messages.  Sieve is designed to do simple, mostly
   static tests, and is not suitable for use as a spam or virus checker,
   where the perpetrator has a motivation to vary the format of the
   email in order to avoid filtering rules.  See also [SPAMTEST].


9.  IANA Considerations

   The following template specifies the IANA registration of the
   variables Sieve extension specified in this document:

   To: [e-mail]
   Subject: Registration of new Sieve extension

   Capability name: variables
   Capability keyword: variables
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number: this RFC
   Person and email address to contact for further information:

      Kjetil Torgrim Homme



Homme                                                          [Page 10]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


      University of Oslo
      Pb 1080, Blindern
      NO-0316 OSLO

      E-mail: [e-mail]

   This information should be added to the list of sieve extensions
   given on http://www.iana.org/assignments/sieve-extensions.

10.  Acknowledgments

   Thanks to Jutta Degener, Ned Freed, Lawrence Greenfield, Mark E.
   Mallett, Peder Stray and Nigel Swinson for valuable feedback.


11.  Author's Address

   Kjetil T. Homme
   University of Oslo
   PO Box 1080
   0316 Oslo, Norway

   Phone: [phone]
   E-mail: [e-mail]


Appendix A.  Normative References


     [ABNF]     D. Crocker, Ed., "Augmented BNF for Syntax
                Specifications: ABNF", Internet Mail Consortium, RFC
                2234, November 1997

     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", Harvard University, RFC 2119, March
                1997.

     [RELATIONAL]
                Segmuller, W., "Sieve Extension: Relational Tests", IBM
                T.J. Watson Research Center, December 2002

     [SIEVE]    Showalter, T., "Sieve: A Mail Filtering Language",
                Mirapoint, RFC 3028, January 2001.

     [UNICODE]  The Unicode Consortium, "The Unicode Standard --
                Worldwide Character Encoding -- Version 1.0", Addison-
                Wesley, Volume 1, 1991, Volume 2, 1992.




Homme                                                          [Page 11]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


     [UTF-8]    Yergeau, F., "UTF-8, a transformation format of Unicode
                and ISO 10646", RFC 2044, October 1996.


A.1  Informative References


     [REGEX]    K. Murchison, "Sieve Email Filtering -- Regular
                Expression Extension", Work in Progress.

     [SPAMTEST] C. Daboo, "SIEVE Email Filtering: Spamtest and VirusTest
                Extensions", Work in Progress.


Appendix B.  Intellectual Property Rights Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.


Appendix C.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Homme                                                          [Page 12]

Internet Draft        Sieve -- Variables Extension            3 Nov 2004


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






















Homme                                                          [Page 13]

--=-2p6Q5THmTXdYlTaCY60X--