Re: Sieve - definition of comments

[Tim Showalter <[e-mail]>]

> Date: Mon, 23 Nov 1998 12:13:53 +0100
> From: Wilbert de Graaf <[e-mail]>

> 1) firts of all, comments cannot have white spaces according to the rule
> comment    = "#" *VCHAR CRLF
> [...]

Good point.

Should VCHAR be "(%01-0A / %0B-0C / %0E-7F)" or "(WSP / VCHAR)"?

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19161 for ietf-mta-filters-bks; Mon, 30 Nov 1998 12:58:55 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19156 for <[e-mail]>; Mon, 30 Nov 1998 12:58:50 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA17025; Mon, 30 Nov 1998 16:03:30 -0500 (EST)
Date: 30 Nov 1998 16:03:31 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Treasury supercomputer terrorist [Hello to all my fans in domestic surveillance] cracking plutonium Soviet
To: [e-mail]
In-reply-to: <008d01be16d2$5b5a7270$[e-mail]>
Subject: Re: Sieve - definition of comments
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 23 Nov 1998 12:13:53 +0100
> From: Wilbert de Graaf <[e-mail]>

> 1) firts of all, comments cannot have white spaces according to the rule
> comment    = "#" *VCHAR CRLF
> [...]

Good point.

Should VCHAR be "(%01-0A / %0B-0C / %0E-7F)" or "(WSP / VCHAR)"?

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26328 for ietf-mta-filters-bks; Tue, 24 Nov 1998 01:13:13 -0800 (PST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26322 for <[e-mail]>; Tue, 24 Nov 1998 01:13:11 -0800 (PST)
Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3149) with ESMTP id <[e-mail]> for [e-mail]; Tue, 24 Nov 1998 10:17:33 +0100
Received: by ntl11.research.kpn.com with Internet Mail Service (5.5.2232.9) id <XK4S8X04>; Tue, 24 Nov 1998 10:17:32 +0100
Content-return: allowed
Date: Tue, 24 Nov 1998 10:17:25 +0100
From: "Graaf, W.L.J.M. de" <[e-mail]>
Subject: RE: Sieve - definition of comments
To: [e-mail], "'Wilbert de Graaf'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA26324
Sender: [e-mail]
Precedence: bulk

Sorry about point 2) - I overlooked that 'comment' was part of the WSP
definition.

- Wilbert


> ----------
> From: 	Wilbert de Graaf[SMTP:[e-mail]]
> Sent: 	maandag 23 november 1998 12:13
> To: 	[e-mail]
> Subject: 	Sieve - definition of comments
> 
> Sieve.all,
>  
> I have a little problem with the comments in the sieve language as
> specified in draft 05.
>  
> 1) firts of all, comments cannot have white spaces according to the rule
> comment    = "#" *VCHAR CRLF
> since VCHAR is defined in ABNF as 
> VCHAR         = %x21-7e ; visible (printing) characters
> and it is not overruled in the sieve spec. This does not include spaces
> and \t. Until now, I defined it to be
> comment       = "#" *(SP / HTAB / VCHAR) CRLF
> (btw. WSP in the ABNF doc is defined to be (SP / HTAB) while in the sieve
> draft it is (SP / HTAB / CRLF) but this is not really a problem)
>  
> 2) As I read it, a sieve script cannot start with a comment according to
> the definition:
> start        = commands
> commands     = *([WSP] command [WSP])
> command      = identifier *(WSP argument) [WSP] (";" / block)
> This tells that every script should start with an identifier. Maybe start
> could be more like
> start        = *(commands / comments)
> This is actually not correct but I do not understand where comments can be
> put. Especially the example script at 2.3 
> if size :over 100K { # this is a comment
>     discard;
> }
> Comment is embedded in command in this specific example:
> command  = identifier *(WSP argument) [WSP] ( ";" / block )
> block    = "{" commands "}"
> commands = *([WSP] command [WSP])
> argument = string / string-list / number / tag / test
> I cannot think about the best way to insert 'comments' somewhere right now
> but before I try to think of something, I will wait if these issues made
> sense.
>  
> Also, I think almost every [WSP} should be replaced with *[WSP], or even
> better, with LWSP.
>  
> - Wilbert
>  
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06243 for ietf-mta-filters-bks; Mon, 23 Nov 1998 11:18:57 -0800 (PST)
Received: from anis.crucible.com (mail.crudites.com [208.242.218.190]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA06239 for <[e-mail]>; Mon, 23 Nov 1998 11:18:57 -0800 (PST)
Received: from CARROT (CARROT [208.242.218.191]) by anis.crucible.com (NTMail 3.03.0017/1.ad24) with ESMTP id ra001057 for <[e-mail]>; Mon, 23 Nov 1998 11:05:59 +0000
From: "Brian Raney" <[e-mail]>
Organization: Crudites
To: [e-mail]
Date: Mon, 23 Nov 1998 11:15:56 -7
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: sieve enabled mailing lists
Reply-to: [e-mail]
CC: [e-mail]
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Pardon my lack of proper research on this topic but can someone point 
me to an open source SIEVE enabled mailing list expander? Perl or C 
variant please.

I had in mind adding on a piece that would do anonymous statistic 
collection on message rejection and prepend these statistics on the 
relevant message.

thanks in advance,

brianr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA03739 for ietf-mta-filters-bks; Mon, 23 Nov 1998 08:46:59 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03735 for <[e-mail]>; Mon, 23 Nov 1998 08:46:57 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA09150 for <[e-mail]>; Mon, 23 Nov 1998 11:51:06 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA10536 for <[e-mail]>; Mon, 23 Nov 1998 11:51:06 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id LAA021.53; Mon, 23 Nov 1998 11:50:19 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-showalter-sieve-05.txt
Date: Mon, 23 Nov 1998 11:51:06 -0500
Message-ID: <000b01be1701$767ca940$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Anybody interested in an informal get-together (a non-BOF bof) on
Sieve at
> > Orlando?
> 
> Absolutely.  I suspect someone else should choose a time, as my
schedule 
> is not very constrained, relatively speaking.

Count me in, but I'm leaving on Wednesday evening, so I won't be
available
after 3:00 Wednesday.

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.5

iQA/AwUBNlmSecUGaCd8CtuXEQL/tgCg6/r/0JbIKVfTCx2mjL0YGQZxxW8AoL30
xUTRDg5gMjK1/XLrpLAVxwUu
=fsHE
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA01476 for ietf-mta-filters-bks; Mon, 23 Nov 1998 03:11:03 -0800 (PST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00905 for <[e-mail]>; Mon, 23 Nov 1998 03:10:05 -0800 (PST)
Received: from david.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3149) with SMTP id <[e-mail]> for [e-mail]; Mon, 23 Nov 1998 12:13:54 +0100
Received: from l4146 by david.research.kpn.com (SMI-8.6/SMI-SVR4) id MAA09356; Mon, 23 Nov 1998 12:13:54 +0100
Date: Mon, 23 Nov 1998 12:13:53 +0100
From: Wilbert de Graaf <[e-mail]>
Subject: Sieve - definition of comments
To: [e-mail]
Message-id: <008d01be16d2$5b5a7270$[e-mail]>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 4.72.3110.5
Content-type: multipart/alternative; boundary="----=_NextPart_000_008A_01BE16DA.BCC7B9C0"
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Priority: 3
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01BE16DA.BCC7B9C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sieve.all,

I have a little problem with the comments in the sieve language as =
specified in draft 05.

1) firts of all, comments cannot have white spaces according to the rule
comment    =3D "#" *VCHAR CRLF
since VCHAR is defined in ABNF as=20
VCHAR         =3D %x21-7e ; visible (printing) characters
and it is not overruled in the sieve spec. This does not include spaces =
and \t. Until now, I defined it to be
comment       =3D "#" *(SP / HTAB / VCHAR) CRLF
(btw. WSP in the ABNF doc is defined to be (SP / HTAB) while in the =
sieve draft it is (SP / HTAB / CRLF) but this is not really a problem)

2) As I read it, a sieve script cannot start with a comment according to =
the definition:
start        =3D commands
commands     =3D *([WSP] command [WSP])
command      =3D identifier *(WSP argument) [WSP] (";" / block)
This tells that every script should start with an identifier. Maybe =
start could be more like
start        =3D *(commands / comments)
This is actually not correct but I do not understand where comments can =
be put. Especially the example script at 2.3=20
if size :over 100K { # this is a comment
    discard;
}
Comment is embedded in command in this specific example:
command  =3D identifier *(WSP argument) [WSP] ( ";" / block )
block    =3D "{" commands "}"
commands =3D *([WSP] command [WSP])
argument =3D string / string-list / number / tag / test
I cannot think about the best way to insert 'comments' somewhere right =
now but before I try to think of something, I will wait if these issues =
made sense.

Also, I think almost every [WSP} should be replaced with *[WSP], or even =
better, with LWSP.

- Wilbert


------=_NextPart_000_008A_01BE16DA.BCC7B9C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2>Sieve.all,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>I have a little =
problem with=20
the comments in the sieve language as specified in draft =
05.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>1) firts of =
all, comments=20
cannot have white spaces according to the rule</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2>comment&nbsp;&nbsp;&nbsp; =3D=20
&quot;#&quot; *VCHAR CRLF</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>since VCHAR is =
defined in=20
ABNF as </FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New"=20
size=3D2>VCHAR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D =
%x21-7e ; visible=20
(printing) characters</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>and it is not =
overruled in=20
the sieve spec. This does not include spaces and \t. Until now, I =
defined it to=20
be</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" =
size=3D2>comment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=20
&quot;#&quot; *(SP / HTAB / VCHAR) CRLF</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>(btw. WSP in the ABNF doc is =
defined to be=20
(SP / HTAB) while in the sieve draft it is (SP / HTAB / CRLF) but this =
is not=20
really a problem)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>2) As I read =
it, a sieve=20
script cannot start with a comment according to the =
definition:</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" =
size=3D2>start&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=20
commands</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>commands&nbsp;&nbsp;&nbsp;&nbsp; =3D *([WSP]=20
command [WSP])</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>command&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D=20
identifier *(WSP argument) [WSP] (&quot;;&quot; / block)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>This tells that every script =
should start=20
with an identifier. Maybe start could be more like</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>start&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D *(commands =
/=20
comments)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>This is actually not correct =
but I do not=20
understand where comments can be put. Especially the example script at =
2.3=20
</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>if size :over 100K { # this is =
a=20
comment</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT><FONT color=3D#000000=20
face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; discard;</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" size=3D2>}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Comment is embedded in command =
in this=20
specific example:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>command&nbsp; =3D identifier =
*(WSP argument)=20
[WSP] ( &quot;;&quot; / block )</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>block&nbsp;&nbsp;&nbsp; =3D =
&quot;{&quot;=20
commands &quot;}&quot;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>
<DIV><FONT face=3D"Courier New" size=3D2>commands =3D *([WSP] command=20
[WSP])</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT><FONT color=3D#000000=20
face=3D"Courier New" size=3D2>argument =3D string / string-list / number =
/ tag /=20
test</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>I cannot think =
about the best=20
way to insert 'comments' somewhere right now but before I try to think =
of=20
something, I will wait if these issues made sense.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>Also, I think =
almost every=20
[WSP} should be replaced with *[WSP], or even better, with=20
LWSP.</FONT></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>- =
Wilbert</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_008A_01BE16DA.BCC7B9C0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA27962 for ietf-mta-filters-bks; Sat, 21 Nov 1998 01:23:47 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA27956 for <[e-mail]>; Sat, 21 Nov 1998 01:23:40 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.88]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 21 Nov 1998 12:25:29 +0300
Message-ID: <[e-mail]>
Date: Sat, 21 Nov 1998 12:24:24 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: draft-showalter-sieve-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> > Date: Fri, 20 Nov 1998 13:53:14 -0400
> > From: Matthew Wall <[e-mail]>
>
> > Anybody interested in an informal get-together (a non-BOF bof) on Sieve at
> > Orlando?
>
> Absolutely.  I suspect someone else should choose a time, as my schedule
> is not very constrained, relatively speaking.

We definitely should meet (in a BOF or not). My schedule is not constrained
either.

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA15393 for ietf-mta-filters-bks; Fri, 20 Nov 1998 20:28:13 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA15389 for <[e-mail]>; Fri, 20 Nov 1998 20:28:12 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id XAA00760; Fri, 20 Nov 1998 23:32:17 -0500 (EST)
Date: 20 Nov 1998 23:32:17 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Khaddafi Serbian munitions Treasury KGB plutonium Vince Foster
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: draft-showalter-sieve-05.txt
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Fri, 20 Nov 1998 13:53:14 -0400
> From: Matthew Wall <[e-mail]>

> Anybody interested in an informal get-together (a non-BOF bof) on Sieve at
> Orlando?

Absolutely.  I suspect someone else should choose a time, as my schedule 
is not very constrained, relatively speaking.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA14715 for ietf-mta-filters-bks; Fri, 20 Nov 1998 18:56:33 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA14711 for <[e-mail]>; Fri, 20 Nov 1998 18:56:32 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Fri, 20 Nov 1998 18:59:35 PST
Date: Fri, 20 Nov 1998 18:59:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: mostly open issues
In-reply-to: "Your message dated Fri, 20 Nov 1998 17:02:48 -0800" <v04103203b27bc0df83a3@129.46.219.133>
To: Randall Gellens <[e-mail]>
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> At 12:20 AM -0800 11/18/98, Ned Freed wrote:

> > I'm sorry, but if short circuit evaluation is useful then it should be a
> > requirement, and if not it should not even be an extension. I don't buy the
> > argument that this is problematic because some languages don't support
> > short-circuit evaluation. Just because you don't have short-circuit in some
> > language doesn't mean that you cannot write a sieve interpreter in that
> > language that does have short circuit characteristics. The two are largely
> > unrelated unless you're using a direct translation approach, in which case
> > other constraints are likely to be a lot more onerous.

> True.  I withdraw my concern regarding mandatory short circuit
> evaluation.  (After reading Ned's message I realized that my own
> implementation would still support short-circuit evaluations even if
> the underlying language didn't.)

> How about something like:

> ANYOF evaluation MUST stop as soon as one element evaluates to TRUE.
> That is, Sieve implementations are REQUIRED to support short-circuit
> evaluations.

> (With the same for ALLOF, except TRUE replaced by FALSE.)

Sounds fine to me.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14202 for ietf-mta-filters-bks; Fri, 20 Nov 1998 17:12:23 -0800 (PST)
Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14198 for <[e-mail]>; Fri, 20 Nov 1998 17:12:23 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA06311; Fri, 20 Nov 1998 17:15:47 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103203b27bc0df83a3@129.46.219.133>
In-Reply-To: <[e-mail]>
References: "Your message dated Tue, 17 Nov 1998 15:47:24 -0500" <[e-mail]> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 20 Nov 1998 17:02:48 -0800
To: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 12:20 AM -0800 11/18/98, Ned Freed wrote:

> I'm sorry, but if short circuit evaluation is useful then it should be a
> requirement, and if not it should not even be an extension. I don't buy the
> argument that this is problematic because some languages don't support
> short-circuit evaluation. Just because you don't have short-circuit in some
> language doesn't mean that you cannot write a sieve interpreter in that
> language that does have short circuit characteristics. The two are largely
> unrelated unless you're using a direct translation approach, in which case
> other constraints are likely to be a lot more onerous.

True.  I withdraw my concern regarding mandatory short circuit 
evaluation.  (After reading Ned's message I realized that my own 
implementation would still support short-circuit evaluations even if 
the underlying language didn't.)

How about something like:

ANYOF evaluation MUST stop as soon as one element evaluates to TRUE. 
That is, Sieve implementations are REQUIRED to support short-circuit 
evaluations.

(With the same for ALLOF, except TRUE replaced by FALSE.)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12132 for ietf-mta-filters-bks; Fri, 20 Nov 1998 10:52:41 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12128 for <[e-mail]>; Fri, 20 Nov 1998 10:52:39 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA28640; Fri, 20 Nov 1998 13:56:38 -0500 (EST)
Date: Fri, 20 Nov 1998 14:00:28 -0400
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>
Subject: Small correction Re: draft-showalter-sieve-05.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--On Thu, Nov 19, 1998 11:49 PM -0500 the entity known as Tim Showalter
<[e-mail]> wrote:


> [IMAP] Crispin, M., "Internet Mail Access Protocol - version 4rev1",
>     RFC 2060, University of Washington, December 1996.

--> "Internet Message Access Protocol"

I do this myself from time to time...

- mw

 =====================================================================
   Matthew Wall * mailto:[e-mail] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
 =====================================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12077 for ietf-mta-filters-bks; Fri, 20 Nov 1998 10:45:27 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12073 for <[e-mail]>; Fri, 20 Nov 1998 10:45:25 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA28592; Fri, 20 Nov 1998 13:49:24 -0500 (EST)
Date: Fri, 20 Nov 1998 13:53:14 -0400
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>
Subject: Re: draft-showalter-sieve-05.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--On Thu, Nov 19, 1998 11:49 PM -0500 the entity known as Tim Showalter
<[e-mail]> wrote:


> 
> 
> I assume that my draft will be ignored until after the December IETF.
> 
> So I'll post a copy here for discussion.  This will become
> draft-showalter-sieve-05.txt.

As we've not planned any formal meeting, I don't think this is a problem at
all. I also suspect the editor will process it, anyway.

Anybody interested in an informal get-together (a non-BOF bof) on Sieve at
Orlando?

- matt


 =====================================================================
   Matthew Wall * mailto:[e-mail] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
 =====================================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29519 for ietf-mta-filters-bks; Thu, 19 Nov 1998 20:45:07 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29511 for <[e-mail]>; Thu, 19 Nov 1998 20:45:04 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id XAA10621; Thu, 19 Nov 1998 23:48:59 -0500 (EST)
Date: 19 Nov 1998 23:49:00 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: COSCO Uzi World Trade Center cryptographic radar Saddam Hussein SDI
To: [e-mail]
Subject: draft-showalter-sieve-05.txt
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hi.  Because of some problems here, most of which were my fault, I
missed the I-D deadline by about ten minutes.  (The ultimate failure was
that I typed internet-drafs by mistake, and didn't get the bounce until
5:10.)

I assume that my draft will be ignored until after the December IETF.

So I'll post a copy here for discussion.  This will become
draft-showalter-sieve-05.txt.

Thanks...

-- 
Tim Showalter <[e-mail]>

Network Working Group                                       T. Showalter
Internet Draft: Sieve                                    Carnegie Mellon
Document: draft-showalter-sieve-05.txt                     November 1998
Expire in six months (30 Apr 1999)


                   Sieve -- a Mail Filtering Language


Status of this memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright

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

Abstract

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




Showalter                 Expires 30 Apr 1999                   [Page 1]

Internet DRAFT                   Sieve                 November 18, 1998





                           Table of Contents



Status of this memo
Copyright
Abstract
0. Meta-information on this draft
0.1. Discussion
0.2. Known Problems
0.2.1. Probable Extensions
0.2.2. Known Bugs
0.3. Noted Changes
1. Introduction
1.1. Conventions Used in This Document
1.2. Example mail messages
2. Design
2.1. Form of the Language
2.2. Whitespace
2.3. Comments
2.4. Literal Data
2.4.1. Numbers
2.4.2. Strings
2.4.2.1. String Lists
2.4.2.2. Headers
2.4.2.3. Addresses
2.5. Tests
2.6. Tagged Arguments
2.7. String Comparison
2.7.1. Match Keyword
2.7.2. Comparisons across Character Sets
2.7.3. Comparators
   2.8. Blocks
2.9. Commands
2.9.1. Positional Arguments
2.9.2. Optional Arguments
2.9.3. Blocks as Arguments
2.10. Evaluation
2.11.1. Implicit keep
3. Conditionals and Control Structures
4. Actions
4.1. Action reject
4.2. Action fileinto
4.3. Action forward
4.4. Action keep



Showalter                 Expires 30 Apr 1999                   [Page 2]

Internet DRAFT                   Sieve                 November 18, 1998


4.6. Action stop
4.7. Action discard
5. Tests
5.1. Test allof
5.2. Test anyof
5.3. Test envelope
5.3. Test exists
5.4. Test false
5.5. Test header
5.6. Test not
5.7. Test size
6. Extensibility
6.1. Capability String
6.2. Registry
6.3. Capability Transport
7. Transmission
8. Acknowledgments
9.  Formal Grammar
10. Security Considerations
11. Author's Address
Appendices
Appendix A.  References
Appendix B. Full Copyright Statement




























Showalter                 Expires 30 Apr 1999                   [Page 3]

Internet DRAFT                   Sieve                 November 18, 1998





















































Showalter                 Expires 30 Apr 1999                   [Page 2]

Internet DRAFT                   Sieve                 November 18, 1998


0. Meta-information on this draft

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

0.1. Discussion

   This draft is 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>.

0.2. Known Problems

0.2.1. Probable Extensions

   The following suggestions have been made, and will probably be
   addressed by extensions.

   An extension for regular expressions will be written.  While regular
   expressions are of questionable utility for most users, the
   programmers writing implementations desperately want regular
   expressions.

   "Detailed" addressing or "sub-addressing" (i.e., the "foo" in an
   address "[e-mail]") is not handled, and will be moved
   to an extension for those systems that offer it.

   A vacation command has been requested for an extension; a preliminary
   draft exists and will be submitted to the internet-drafts repository.
   Vacation functionality is isn't in the draft because having vacation
   assumes you can store the addresses of people who have already
   received vacation notifications, which isn't always the case.

   A suggestion was made to set IMAP flags on delivery (e.g., \Flagged,
   \Deleted, \Answered, \Seen).

   An "include" command is not included, but has been suggested for an
   extension.

0.2.2. Known Bugs

   The discussion of the limits of actions is not there.  Only one
   forward should be allowed per message.  Keep and reject are mutually
   exclusive.




Showalter                 Expires 30 Apr 1999                   [Page 4]

Internet DRAFT                   Sieve                 November 18, 1998


0.3. Noted Changes

   Here are a list of changes from draft 04.  (It may not be complete.)

   * Concensus: i;ascii-casemap is required.

   * Consensus: i;ascii-casemap is the default.

   * Header name compares are always case-insensitive; the draft now
     says so.

   * Several examples were fixed, but it is likely that errors remain.

   * Bug: Section 7, remove reference to "support".

   * There are two namespaces  for extension names, one "vnd.", one
     everything else, just like MIME.

   * All XXXs have been removed, except for in IANA section.

   * Fileinto is optional, and discussion of local mail folders and POP3
     has been removed.

   * A non-present comparator is considered to be basically a syntax
     error.

   * Resent headers are not to be added by the "forward" command.

   * Tagged arguments must follow the keyword, and may not be
     interspersed with positional arguments.

   * Envelope-matching commands are to be added with the syntax that
     Barry suggested.

   * Put back :matches match keyword.

   * What happens when an error occurs has been dropped.

   * Reject is now optional.

   * Implementations are encouraged to decode header charsets, and if
     they don't, are required to not do compares on 8-bit data.









Showalter                 Expires 30 Apr 1999                   [Page 5]

Internet DRAFT                   Sieve                 November 18, 1998


1. Introduction

   This memo documents a language that can be used to create filters for
   electronic mail. It is not tied to any particular operating system or
   mail architecture.  It requires the use of [IMAIL]-compliant
   messages, but otherwise should generalize to other systems that meet
   these criteria.

   The language is powerful enough to be useful, but limited in power in
   order to allow for a safe server-side filtering system.  The
   intention is to make it impossible for users to do anything more
   complex (and dangerous) than write simple mail filters, along with
   facilitating GUI-based editors. The language is not Turing-complete,
   and provides no way to write a loop or a function.  Variables are not
   provided.

   Implementations of the language are expected to take place at time of
   final delivery, when the message is moved to the user-accessible
   mailbox.  In systems where the MTA does final delivery, such as and
   traditional UNIX mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.

   There are a number of reasons to use a filtering system.  Mail
   traffic for most users has been increasing due both to increased
   usage of e-mail, the emergence of unsolicited email as a form of
   advertising, and increased usage of mailing lists.

   Experience at Carnegie Mellon has shown that if a filtering system is
   made available to users, many will make use of it in order to file
   messages from specific users or mailing lists.  However, many others
   did not make use of the Andrew system's FLAMES [FLAMES] filtering
   language due to difficulty in setting it up.

   Because of the expectation that users will make use of filtering if
   it is offered and easy to use, this language has been made simple
   enough to allow many users to make use of it, but rich enough that it
   can be used productively.  However, it is expected that GUI-based
   editors will be the preferred way of editing filters for a large
   number of users.

1.1. Conventions Used in This Document

   In examples, line breaks have been inserted for readability.

   In the sections of this document that discuss the requirements of
   various keywords and operators, the following conventions have been
   adopted.




Showalter                 Expires 30 Apr 1999                   [Page 6]

Internet DRAFT                   Sieve                 November 18, 1998


   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
   "MAY" in this document are to be interpreted as defined in
   [KEYWORDS].

   Each section on a test, action, or control structure has a line
   labeled "Syntax:".  This line describes the syntax of the command,
   including its name and its arguments.  Required arguments are listed
   inside angle brackets ("<" and ">").  Optional arguments are listed
   inside square brackets ("[" and "]").  However, the formal grammar
   for these commands in section 10 and is the authoritative reference
   on how to construct these commands.

1.2. Example mail messages

   The following mail messages will be used throughout this document  in
   examples.

   Message A
   -----------------------------------------------------------
   Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
   From: [e-mail]
   To: [e-mail]
   Subject: I have a present for you

   Look, I'm sorry about the whole anvil thing, and I really
   didn't mean to try and drop it on you from the top of the
   cliff.  I want to try to make it up to you.  I've got some
   great birdseed over here at my place--top of the line
   stuff--and if you come by, I'll have it all wrapped up
   for you.  I'm really sorry for all the problems I've caused
   for you over the years, but I know we can work this out.
   --
   Wile E. Coyote       "Super Genius"        [e-mail]
   -----------------------------------------------------------

















Showalter                 Expires 30 Apr 1999                   [Page 7]

Internet DRAFT                   Sieve                 November 18, 1998


   Message B
   -----------------------------------------------------------
   From: youcouldberich!@reply-by-postal-mail
   Sender: [e-mail]
   To: [e-mail]
   Date:  Mon, 31 Mar 1997 18:26:10 -0800 (PST)
   Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$

   YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
   IT!  SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS!  IT WILL
   GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
   MONEY! MONEY! COLD HARD CASH!  YOU WILL RECEIVE OVER
   $20,000 IN LESS THAN TWO MONTHS!  AND IT'S LEGAL!!!!!!!!!
   !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1  JUST
   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
   -----------------------------------------------------------

2. Design

2.1. Form of the Language

   This language is made up as a set of commands.  Commands can take a
   number of arguments; arguments can be either literal data, tests, or
   blocks of commands.

2.2. Whitespace

   Whitespace is used to separate commands.  Whitespace is made up of
   tabs, newlines (CRLF, never just CR or LF), and the space character.
   The amount of whitespace used is not significant.

2.3. Comments

   Comments begin with a "#" character that is not contained within a
   string and continue until the next CRLF.

   Example:  if size :over 100K { # this is a comment
                discard;
             }


2.4. Literal Data

   Literal data means data that is not executed and is supplied as
   arguments, such as numbers and strings.






Showalter                 Expires 30 Apr 1999                   [Page 8]

Internet DRAFT                   Sieve                 November 18, 1998


2.4.1. Numbers

   Numbers are given as ordinary decimal numbers.  However, those
   numbers that have a tendency to be fairly large, such as message
   sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
   a base-two number.  To be comparable with the power-of-two-based
   versions of SI units that computers frequently use, K specifies kilo,
   or 1,024 (2^10) times the value of the number; M specifies mega, or
   1,048,576 (2^20) times the value of the number; and G specifies giga,
   or 1,073,741,824 (2^30) times the value of the number.

   Implementations MUST provide 31 bits of magnitude in numbers, but may
   provide more.

   Negative, fractional, and decimal numbers are not permitted  by  this
   specification.

2.4.2. Strings


   Scripts involve large numbers of strings, as they are used for
   pattern matching, addresses, and textual bodies, etc.  Typically,
   short quoted strings suffice for most uses, but a more convenient
   form is provided for longer strings such as bodies of messages.

   A quoted string starts and ends with a single double quote (the <">
   character).  A backslash ("\") inside of a quoted string is followed
   by either another backslash or a double quote.  This two-character
   sequence represents a single backslash or double-quote within the
   string, respectively.

   Other escape sequences may be permitted depending on context.  An
   undefined escape sequence (such as "\a" in a context where "a" has no
   special meaning) is interpreted as if there were no backslash (in
   this case, "\a" is just "a").

   Non-printing characters such as tabs, CR and LF, and control
   characters are permitted in strings.  NUL (ASCII 0) is not allowed in
   strings.

   For entering larger amounts of text, such as an email message, a
   multi-line form is allowed.  It starts with the keyword "text:",
   followed by a CRLF, and ends with the sequence of a CRLF, a single
   period, and another CRLF.  In order to allow the message to begin
   lines with a single-dot, lines are dot-stuffed.  That is, when
   composing a message body, an extra `.' is added before each line
   which begins with a `.'.  When the server interprets the script,
   these extra dots are removed.



Showalter                 Expires 30 Apr 1999                   [Page 9]

Internet DRAFT                   Sieve                 November 18, 1998


   Note that a comment may occur in between the "text:" and the CRLF,
   but not within the string itself.

2.4.2.1. String Lists

   When matching patterns, strings frequently come in groups.  For this
   reason, a list of strings is allowed in many tests, implying that if
   the test is true using any one of the strings, then the test is true.
   Implementations are encouraged to use short-circuit evaluation in
   these cases.

   For instance, the test `header ["To", "Cc"] contains
   ["[e-mail]", "[e-mail]"]' is true if either the
   To header or Cc header of the input message contains either of the
   e-mail addresses "[e-mail]" or "[e-mail]".

   Conversely, in any case where a list of strings would be appropriate,
   a single string is allowed without being a member of a list; it is
   equivalent to a list with a single member.  So the test `exists "To"'
   is equivalent to the test `exists ["To"]'.

2.4.2.2. Headers

   Headers are a subset of strings.  In the Internet Message
   Specification [IMAIL], each header line is allowed to have whitespace
   nearly anywhere in the line, including after the field name and
   before the subsequent colon.  Extra spaces between the header name
   and the ":" in a header field are ignored by the interpreter.

   A header name never contains a colon.  The "From" header refers to a
   line beginning "From:" (or "From   :", etc.).  No header will match
   the string "From:" due to the trailing colon.

2.4.2.3. Addresses

   A number of commands call for email addresses, which are also a
   subset of strings.  These addresses must be compliant with [IMAIL].
   Implementations MUST ensure that the addresses are syntactically
   valid, but need not ensure that they are actually deliverable.

2.5. Tests

   Tests are given as arguments to commands in order to control how the
   run.  Generally, a test is used to decide if a block of code should
   be evaluated.






Showalter                 Expires 30 Apr 1999                  [Page 10]

Internet DRAFT                   Sieve                 November 18, 1998


2.6. Tagged Arguments

   This document provides for tagged arguments in the style of
   CommonLISP.

   A tagged argument is an an argument for a command that begins with
   ":", and consists of a tag naming the argument, such as ":contains".
   This argument means that zero or more of the next tokens have some
   particular meaning, depending on the argument.  These next tokens may
   be numbers or strings, but are never blocks.

   One case where this is useful is the ":comparator" argument, which
   allows the user to specify which ACAP comparator will be used to
   compare two strings, since different languages may impose different
   orderings on UTF-8 [UTF-8] characters.

   Tagged arguments must appear before positional arguments.

   To keep the language simple, tagged arguments should not take tagged
   arguments as arguments.

2.7. String Comparison

   When matching one string against another, there are a number of ways
   of performing the match.  These are accomplished with three matches:
   exact match, a substring match, and a wildcard glob-style match.  In
   order to provide for matches between character sets and case
   insensitivity, Sieve borrows ACAP's comparator registry.

   However, when a string is being used to represent the name of a
   header, the comparator is not user-specified.  Header comparisons are
   always done in a case-insensitive manner, since this is the way
   things are specified in the message specification [IMAIL].  That is,
   header-name comparisons are always done with the "i;ascii-casemap"
   comparator.

2.7.1. Match Keyword

   There are three allowed match keywords describing the allowed match
   in this draft: they are ":is", ":contains", and ":matches".  Match
   keywords are supplied to those commands which allow them to specify
   whether the match is to be a complete match or not.

   These are used as tagged arguments to tests that perform string
   comparison.  Exactly one of them is necessary for a command.

   The ":contains" version describes a substring match.  If the value
   argument contains the key argument as a substring, the match is true.



Showalter                 Expires 30 Apr 1999                  [Page 11]

Internet DRAFT                   Sieve                 November 18, 1998


   For instance, the string "frobnitzm" contains "frob" and "nit", but
   not "fbm".  The null key ("") is contained in all values.

   The ":is" version describes an absolute match; if the contents of the
   first string are absolutely the same as the contents of the second
   string, they match.  Only the string "frobnitzm" is the string
   "frobnitzm".  The null key only ":is" the null value.

   The ":matches" version specifies a wildcard match using the
   characters "*" and "?".  "*" matches any number of characters, and
   "?" matches a single character.  "?" and "*" may be escaped as "\?"
   and "\*" in strings to match against them by name.

   In order to specify  what  type  of  match  is  supposed  to  happen,
   commands   that  support  matching  take  optional  tagged  arguments
   ":matches", ":is", and ":contains".  Commands default to using  ":is"
   matching.   Note  that these modifiers may interact with comparators;
   in particular, some comparators are not suitable  for  matching  with
   ":contains"  or  ":matches".  It is an error to use a comparator with
   ":contains" or ":matches" that is not compatible with it.

2.7.2. Comparisons across Character Sets

   All Sieve scripts are represented in UTF-8, but messages may involve
   a number of character sets.  In order for comparisons to work across
   character sets, implementations SHOULD implement the following
   behavior:

      Implementations decode header charsets to UTF-8 two strings are
      considered equal if their UTF-8 representations are identical.
      Implementations should decode charsets represented in the forms
      specified by [MIME] for both message headers and bodies.
      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
      the ASCII subset of ISO-8859-* character sets, and UTF-8.

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings containing 8-bit data can be considered equal.

2.7.3. Comparators

   In order to allow for character set-independent matches, the match
   keyword may be coupled with a comparator name.  Comparators are
   described for [ACAP]; a registry is defined for ACAP, and this
   specification uses that registry.

   ACAP defines multiple comparator types.  Only equality types are used



Showalter                 Expires 30 Apr 1999                  [Page 12]

Internet DRAFT                   Sieve                 November 18, 1998


   in this specification.

   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase English characters in the same).  If left
   unspecified, the default is "i;ascii-casemap".

   Some comparators may not be usable with substring matches; that is,
   they may only work with ":is".  It is an error to try and use a
   comparator with ":matches" or ":contains" that is not compatible with
   it.

   A comparator is specified with commands that support matching by the
   ":comparator" option.  This option is followed by a string providing
   the name of the comparator to be used.  So in this example,

   Example:  if header :contains :comparator "i;octet" "Subject"
                "MAKE MONEY FAST" {
                   discard;
                }

             would discard any message with subjects like "You can MAKE
             MONEY FAST", but not "You can Make Money Fast", since the
             comparator used is not case-sensitive.

             If a comparator is not known to an implementation, it is
             treated in the same way as an unknown command or syntax
             error.

             Both ":matches" and ":contains" match keywords are
             compatible with the "i;octet" and "i;ascii-casemap"
             comparators and may be used with them.

   2.8. Blocks

   Blocks are sets of commands enclosed within curly braces.  Blocks are
   supplied to commands so that the commands can implement control
   structures.

   So a control structure is just a command that happens to take a test
   and a block as its arguments; depending on the result of the control
   structure, it runs the code in the block zero or more times.  (Note
   that by the commands supplied in the specification, there are no
   loops, so the control structures supplied--if, elsif, and else--run a
   block either once or not at all.)






Showalter                 Expires 30 Apr 1999                  [Page 13]

Internet DRAFT                   Sieve                 November 18, 1998


2.9. Commands

   Sieve scripts are sequences of commands.  Commands can take any of
   the tokens above as arguments, and arguments may be either tagged or
   positional arguments.

   A command begins with a name, which is a simple token.  It ends with
   either a semicolon or a block.  (Commands ending with blocks are used
   to implement control structures.)  Commands never take both a
   semicolon and a block, nor do they ever take more than one block as
   an argument.

2.9.1. Positional Arguments

   Positional arguments are familiar from any programming language.  A
   command takes zero or more untagged positional arguments in order to
   specify its behavior.  Positional arguments are given their value
   based on their order in the command.

2.9.2. Optional Arguments

   Optional arguments are tagged arguments that may be omitted; when
   omitted, they are given default values.

2.9.3. Blocks as Arguments

   Commands may take blocks as arguments.  A block is always the last
   argument to a command, and when it exists, it replaces the semicolon
   that would otherwise end the command.

2.10. Evaluation

   Precedence is not important in any of the commands in this base
   specification.  However, as an extension might make order of
   operation important, all arguments to rules MUST be evaluated in
   left-to-right order.  Those operations that can implement short-
   circuit evaluation (such as "allof" and "anyof") MUST do so.

   Sieve imposes specific limits on actions; for instance, a rejected
   message may not also be filed into a mailbox.  These restrictions are
   noted on a per-command basis.

   OPEN:   Or rather, they should be.

2.11.1. Implicit keep

   If evaluation of a script fails to result in one "fileinto", "keep",
   or "reject", a "keep" action is implicitly taken.  So the message is



Showalter                 Expires 30 Apr 1999                  [Page 14]

Internet DRAFT                   Sieve                 November 18, 1998


   filed into the user's primary mailbox; that is,

   For instance, with any of the short messages offered above, the
   following script produces no actions.

   Example:  if size :over 500K { discard; }

3. Conditionals and Control Structures

   In order for a script to do more than one set of actions, control
   structures are needed.  In Sieve, a control structure is a command
   that takes a block as an argument.

   In this document, only the "if" control structure is provided.  There
   are three pieces to if: "if", "elsif", and "else".

   Syntax:   if <test> <block>

   Syntax:   elsif <test> <block>

   Syntax:   else <block>

   The semantics are similar to any other programming language this
   appears in.  When the interpreter sees an "if", it evaluates the test
   associated with it.  If the test is true, it executes the block
   associated with it.

   If the test of the "if" is false, it evaluates the test of the first
   "elsif" (if any).  If the test of "elsif" is true, it runs the
   elsif's block.  An elsif may be followed by an elsif, in which case,
   the interpreter repeats this process until it runs out of elsifs.

   When the interpreter runs out of elsifs, there may be an "else" case.
   If there is, and none of the if or elsif tests were true, the
   interpreter runs the else case.

   This provides a way of performing exactly one of the blocks in the
   chain.













Showalter                 Expires 30 Apr 1999                  [Page 15]

Internet DRAFT                   Sieve                 November 18, 1998


   In the following example, both Message A and B are dropped.

   Example:  if header "from" contains "coyote" {
                discard;
             } elsif  header ["subject"] :contains ["$$$"] {
                discard;
             } else {
                fileinto "INBOX";
             }


   In the script below, when run over message A, forwards the message to
   [e-mail];  message B, to [e-mail]; any other
   message is forwarded to [e-mail].

   Example:  if header ["From"] contains ["coyote"] {
                forward "[e-mail]";
             } else if header "Subject" contains "$$$" {
                forward "[e-mail]";
             } else {
                forward "[e-mail]";
             }

4. Actions


   This document supplies six actions that may be taken on a message:
   keep, fileinto, forward, reject, discard, and stop.

4.1. Action reject


   Syntax:   reject <reason-string>

   The optional "reject" action resends the message to the sender,
   wrapping it in a "reject" form, noting that it was rejected by the
   recipient.  In the following script, message A is rejected and
   returned to the sender.

   Example:  if header "from" contains "[e-mail]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }








Showalter                 Expires 30 Apr 1999                  [Page 16]

Internet DRAFT                   Sieve                 November 18, 1998


   A reject message MUST takes the form of a failed DSN as specified  by
   [DSN].    The  human-readable  portion  of  the  message,  the  first
   component of the DSN, contains the human readable message  describing
   the  error,  although  it SHOULD contain additional text alerting the
   original sender that mail was refused by a filter.  This part of  the
   DSN might appear as follows:

   ------------------------------------------------------------
   Message was refused by recipient's mail filtering program.
   Reason given was as follows:

   I am not taking mail from you, and I don't want your
   birdseed, either!
   ------------------------------------------------------------

   The action-value field as defined in the DSN specification MUST be
   "failed".

   A rejected message may not be filed, forwarded, or kept.  A message
   that triggers a "reject" action is never allowed to be kept by the
   user, and the "reject" overrides all other actions.

   A message may only be rejected once.

   Because some implementations cannot implement the reject command, it
   is optional.

4.2. Action fileinto


   Syntax:   fileinto <folder>

   The "fileinto" action drops the message into a named folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.

   In  the  following  script,  message   A   is   filed   into   folder
   "INBOX.harassment".

   Example:  if header :contains ["from"] "coyote" {
                fileinto "INBOX.harassment";
             }

4.3. Action forward


   Syntax:   forward <address>




Showalter                 Expires 30 Apr 1999                  [Page 17]

Internet DRAFT                   Sieve                 November 18, 1998


   The "forward" action is used to forward the message to another user
   at the supplied address, as a mail forwarding feature does.  The
   "forward" action makes no changes to the message body or headers, and
   only modifies the envelope recipient.

   A simple script can be used for forwarding:

   Example:  forward "[e-mail]";

   The forward command performs an MTA-style forward--that is, what  you
   get  from  a .forward file using sendmail under UNIX.  The address on
   the SMTP envelope is replaced with the one on the forward command and
   the  message  is  sent  back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and  message  ID,
   wrapping the old message in a new one.)  The forward command does not
   add Resent- headers.

4.4. Action keep


   Syntax:   keep

   The "keep" action is whatever action is taken in lieu of all other
   actions, if no filtering happens at all; generally, this simply means
   to file the message into the user's main mailbox.  This command
   provides a way to execute this action without needing to know the
   name of the user's main mailbox, providing a way to call it without
   needing to understand the user's setup, or the underlying mail
   system.

   Example:  if size :under 1M keep; else discard;

4.6. Action stop


   Syntax:   stop

   The "stop" action ends all processing.  If no actions have been
   executed, then the keep action is taken.

4.7. Action discard


   Syntax:   discard

   Discard drops the message.  In the following script, any mail from
   "[e-mail]" is thrown out.




Showalter                 Expires 30 Apr 1999                  [Page 18]

Internet DRAFT                   Sieve                 November 18, 1998


   Example:  if header ["from"] contains ["[e-mail]"]
             discard;

   Discard takes no arguments.

   While an important part of this language, "discard" has the potential
   to create serious problems for users: A student leaving themselves
   logged in to a machine in a computer lab may find their script
   changed to just "discard".  In order to protect users in this
   situation (along with similar situations), implementations MAY keep
   messages destroyed by a script for an indefinite period, and MAY
   disallow scripts that throw out all mail.

5. Tests

   Tests are used in conditionals to decide which part(s) of the
   conditional to execute.
5.1. Test allof


   Syntax:   allof ( <test> , <test> , ... <test> )

   The allof test preforms a logical AND on the tests supplied to it.

   Example:  allof (false, false)  =>   false
             allof (false, true)   =>   false
             allof (true, true)    =>   true

   The allof test takes as its argument a test-list.

5.2. Test anyof


   Syntax:   anyof ( <test> , <test> , ... <test> )

   The anyof test preforms a logical OR on the tests supplied to it.

   Example:  anyof (false, false)  =>   false
             anyof (false, true)   =>   true
             anyof (true, true)    =>   true

5.3. Test envelope


   Syntax:   envelope <match-keyword> <envelope-part> <key-list>

   The "envelope" test is true if the specified part of the RFC-822
   envelope matches the specified key.



Showalter                 Expires 30 Apr 1999                  [Page 19]

Internet DRAFT                   Sieve                 November 18, 1998


   If the envelope-part contains (case insensitive) "from", then
   matching occurs against the FROM address used in the SMTP MAIL
   command.

   If the envelope-part contains (case insensitive) "to", then matching
   occurs against the TO address used in the SMTP RCPT command that
   resulted in this message getting delivered to this user.  Note that
   only the most recent TO is avaliable.

   The envelope-part is a string list and may contain both "from" and
   "to", in which case the strings specified in the key-list are matched
   against both parts of the envelope.

5.3. Test exists


   Syntax:   exists <header-name-list>

   The "exists" test is true if the headers listed in the
   <header-name-list> argument exist within the message.  All of the
   headers must exist or the test is false.

   The following example throws out mail that doesn't have a From header
   and a Date header.

   Example:  if not exists ["From","Date"] {
                discard;
             }

5.4. Test false


   Syntax:   false

   The "false" test always evaluates to false.

5.5. Test header


   Syntax:   header <match-keyword> <header-name-list> <key-list>

   The "header" test evaluates to true if the any header name matches
   any key.  How the match is done is described by the second argument,
   which is one of the string comparison arguments discussed in section
   2.6.  The first argument to header, the header-name-list, is a list
   of headers to get values from to be searched.  The key-list is a list
   of keys.




Showalter                 Expires 30 Apr 1999                  [Page 20]

Internet DRAFT                   Sieve                 November 18, 1998


   If a header  listed  in  the  header-name-list  argument  exists,  it
   contains  the  null  key  ("").   However, if the named header is not
   present, it does not contain the null key. So if a message  contained
   the header

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header ["X-Caffeine"] is [""]         => false
           header ["X-Caffeine"] contains [""]   => true

5.6. Test not


   Syntax:   not <test>

   The "not" test takes some other test as an argument, and yields the
   opposite result.

5.7. Test size


   Syntax:   size <":over" / ":under"> <limit [quantifier]>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

   If the argument is ":over", and the size of the message is greater
   than the number provided, the test is true; otherwise, it is false.

   If the argument is ":under", and the size of the message is less than
   the number provided, the test is true; otherwise, it is false.

   The size of a message is defined to be the number of octets from the
   initial header until the last character in the message body.

6. Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; this
   document does not define a way to discover the list of extensions
   supported by the server.

   Any extensions to this language MUST define a capability string that
   uniquely identifies that extension.  If a new version of an extension
   changes the functionality of a previously defined extension, it MUST



Showalter                 Expires 30 Apr 1999                  [Page 21]

Internet DRAFT                   Sieve                 November 18, 1998


   use a different name.

   In a situation where there is a submission protocol and an extension
   advertisement mechanism aware of the details of this language,
   scripts submitted can be checked against the mail server to prevent
   use of an extension that that the server does not support.

6.1. Capability String

   Capability strings are typically short strings describing what
   capabilities are supported by the server.

   Capability strings beginning with "vnd." represent vendor-defined
   extensions.  Such extensions are not defined by Internet standards or
   RFCs, but are still registered with IANA in order to prevent
   conflicts.  Extensions starting with "vnd." should be followed by the
   name of the vendor, such as "vnd.acme.rocket-sled".

   The following capability strings are defined by this document:

   envelope    The string "envelope" indicates that the implementation
               supports the "envelope" command.

   fileinto    The string "fileinto" indicates that the implementation
               supports the "fileinto" command.


   reject      The string "reject" incidates that the implementation
               supports the "reject" command.


   comparator- The string "comparator-elbonia" is provided if the
               implementation supports the "elbonia" comparator.
               Therefore, all implementations have at least the
               "comparator-i;octet" capability.


6.2. Registry

   In order to provide a standard set of extensions, a registry is
   provided by IANA.  Capability names may be registered on a first-
   come, first-served basis.  Extensions designed for interoperable use
   should be defined as standards track or IESG approved experimental
   RFCs.

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




Showalter                 Expires 30 Apr 1999                  [Page 22]

Internet DRAFT                   Sieve                 November 18, 1998


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

6.3. Capability Transport

   As the range of mail systems that this draft is intended to apply to
   is quite large, a method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.  Such a mechanism, however, should have the
   following properties.

   (1)  The implementation can advertise the complete set of extensions
        that it supports.


   OPEN:   There needs to be a more complete description here.


7. Transmission

   The MIME type for a SIEVE script is "application/sieve".  Scripts are
   encoded in UTF-8 during transmission.

8. Acknowledgments

   I am very thankful to Chris Newman for his support and his ABNF
   syntax checker, to John Myers and Steve Hole for outlining the
   requirements for the original drafts, and to Rob Earhart for an early
   implementation and a great deal of help.  I am also indebted to all
   of the readers of the [e-mail] mailing list.

9.  Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].

   In the case of alternative or optional rules in which a later rule
   overlaps an earlier rule, the rule which is listed earlier MUST take
   priority.  (This shouldn't happen.  Please let me know if it does.)

   The start symbol for this grammar is "start".

   argument = string / string-list / number / tag / test

   block = "{" commands "}"



Showalter                 Expires 30 Apr 1999                  [Page 23]

Internet DRAFT                   Sieve                 November 18, 1998


           ;; C-style block

   CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)
           ;; all the characters that aren't "."

   command = identifier *(WSP argument) [WSP] ( ";" / block )

   commands = *([WSP] command [WSP])

   comment = "#" *VCHAR CRLF

   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")

   multi-line = "text:" [WSP] CRLF
           *((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR CRLF) /
             (".." *CHAR CRLF) / CRLF)
           "." CRLF
           ;; Note when used,
           ;; a leading ".." on a line is mapped to ".".

   number = 1*DIGIT [QUANTIFIER]
           ;; quantifier is a multiplier (or bit shift)

   QUANTIFIER = "K" / "M" / "G"
           ;; K == 2^10; M == 2^20; G = 2^30

   quoted-string = DQUOTE *CHAR DQUOTE
           ;; \" inside a string maps to "
           ;; \\ inside a string maps to \
           ;; All other characters map to themselves.
           ;; Note that newlines and other weird characters
           ;; are all allowed strings.

   start = commands

   string = quoted-string / multi-line

   string-list = "[" [WSP] string *([WSP] "," [WSP] string) [WSP] "]" / string
           ;; if there is only a single string, the brackets are optional

   tag = ":" identifier

   test = identifier *(WSP argument) [WSP test-list]

   test-list = [WSP] "(" [WSP] *(test [WSP] "," [WSP])
       test [WSP] ")" [WSP]

   WSP = 1*(SP / CRLF / HTAB) / comment



Showalter                 Expires 30 Apr 1999                  [Page 24]

Internet DRAFT                   Sieve                 November 18, 1998


           ;; just whitespace.  anyplace this is allowed, a comment is
           ;; as well

10. Security Considerations

   Users must get their mail.  It is imperative that whatever method
   implementations use to store the user-defined filtering scripts be
   secure.

   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 forward
   multiple times to a single message might also allow a user to create
   a mailbomb triggered by mail from a specific user.

   Therefore, an implementation SHOULD only allow one "reject" per
   message processed, and MAY limit the number of forward actions taken.
   An implementation MUST refuse to forward a message to itself.  [OPEN:
   What do you do when a site limit prevents you from this?  Say I do
   three replies; which ones take effect when the limit is 1? 2? 0?]

   Several commands, such as "discard", "forward", and "fileinto" allow
   for actions to be taken that are potentially very dangerous.

11. Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]



















Showalter                 Expires 30 Apr 1999                  [Page 25]

Internet DRAFT                   Sieve                 November 18, 1998


Appendices

Appendix A.  References

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

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
   Delivery Status Notifications", RFC 1894, January 1996.

   [FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and
   Cooperative Work in a Practical Multimedia Message System", Int. J.
   of Man-Machine Studies, April, 1991.  Reprinted in Computer-Supported
   Cooperative Work and Groupware, Saul Greenberg, editor, Harcourt
   Brace Jovanovich, 1991.  Reprinted in Readings in Groupware and
   Computer-Supported Cooperative Work, Ronald Baecker, editor, Morgan
   Kaufmann, 1993.

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

   [IMAP] Crispin, M., "Internet Mail Access Protocol - version 4rev1",
   RFC 2060, University of Washington, December 1996.

   [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, University of Delaware, August 1982.

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

   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
   USC/Information Sciences Institute, August 1982.

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



Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1998. 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



Showalter                 Expires 30 Apr 1999                  [Page 26]

Internet DRAFT                   Sieve                 November 18, 1998


   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 will expire before Apr 30, 1999.






































Showalter                 Expires 30 Apr 1999                  [Page 27]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05346 for ietf-mta-filters-bks; Wed, 18 Nov 1998 18:30:15 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05342 for <[e-mail]>; Wed, 18 Nov 1998 18:30:14 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Wed, 18 Nov 1998 18:33:38 PST
Date: Wed, 18 Nov 1998 18:27:24 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
In-reply-to: "Your message dated Wed, 18 Nov 1998 14:39:49 -0500" <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: Tim Showalter <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Tim Showalter wrote:
> >
> > > Date: Wed, 11 Nov 1998 11:47:53 -0800 (PST)
> > > From: Ned Freed <[e-mail]>
> >
> > > > ...which also allows '["from", "rcpt"]' for more flexibility.
> > >
> > > What a great idea! I really like this approach, even though it isn't what
> > > I implemented.
> >
> > I'm writing this now and it occurs to me that it might be clearer if
> > that's "from" and "to" instead of "from" and "rcpt".
> >
> > This is a nice approach, though.

> How about "mail-from" and "rcpt-to" to make them more consistent with
> the smtp envelope verbs?

To my mind this makes things less consistent, not more. MAIL FROM can have many
parameters, the FROM address being just one of them. And RCPT TO has, if
anything, even more. So to me mail-from identifies a bunch of stuff and so does
rcpt-to.

But since the set of parameters to MAIL FROM and RCPT TO is currently disjoint,
and is likely to remain that way, it seems more consistent to me to go by
parameter name, with the "special" parameter names FROM and TO for the
special, initial parameters.

I also _really_ don't like the use of minus in these names. I thought this came
up some time ago and it was decided that we wouldn't use minus in names. Of
course this can simply be cured by using underscores instead.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03111 for ietf-mta-filters-bks; Wed, 18 Nov 1998 14:22:16 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03107 for <[e-mail]>; Wed, 18 Nov 1998 14:22:15 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 127; Thu, 19 Nov 1998 01:40:02 +0300
Message-ID: <[e-mail]>
Date: Thu, 19 Nov 1998 01:25:38 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Matthew Wall <[e-mail]>
CC: [e-mail], Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Matthew Wall wrote:

> --On Wed, Nov 18, 1998 3:32 PM -0500 in response to Tony Hansen
> <[e-mail]>:
>
> >
> > > > > > ...which also allows '["from", "rcpt"]' for more flexibility.
> >
> > > > I'm writing this now and it occurs to me that it might be clearer if
> > > > that's "from" and "to" instead of "from" and "rcpt".
> >
> > > How about "mail-from" and "rcpt-to" to make them more consistent with
> > > the smtp envelope verbs?
>
> the entity known as Tim Showalter <[e-mail]> wrote:
>
> > I don't see a lot of merit in making them similar to the SMTP verbs
>
> well, except there is virtue in being consistent with _something_, and one
> might make the point that the SMTP-savvy are going to be well-represented
> among those looking at the syntax.
>
> Still, I'd prefer 'from' and 'to' for simplicity's sake, even if it's
> technically a bit less explicit. Why bother typing the extra chars, eh?
>
> - matt <[e-mail]>

Why not just use "f" and "t". They are even shorter :-)

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03075 for ietf-mta-filters-bks; Wed, 18 Nov 1998 14:19:34 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03071 for <[e-mail]>; Wed, 18 Nov 1998 14:19:34 -0800 (PST)
Received: from esys.ca (zappa.esys.ca [198.161.92.28]) by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id PAA21173 for <[e-mail]>; Wed, 18 Nov 1998 15:23:26 -0700
Message-Id: <[e-mail]>
Date: Wed, 18 Nov 1998 15:23:23 -0700
From: Lyndon Nerenberg <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> I don't see a lot of merit in making them similar to the SMTP verbs.
> Even really clueful users (ones capable and willing to write raw Sieve
> scripts) don't know much about SMTP, and making them type "rcpt" doesn't 
> seem like the right thing to me.

Well, this (hopefully :-) clueful user finds mail-from and rcpt-to to
be much more intiutive than the alternatives.

--lyndon




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03013 for ietf-mta-filters-bks; Wed, 18 Nov 1998 14:11:29 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03009 for <[e-mail]>; Wed, 18 Nov 1998 14:11:27 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id RAA25160; Wed, 18 Nov 1998 17:15:13 -0500 (EST)
Date: Wed, 18 Nov 1998 17:19:01 -0400
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--On Wed, Nov 18, 1998 3:32 PM -0500 in response to Tony Hansen
<[e-mail]>: 

> 
> > > > > ...which also allows '["from", "rcpt"]' for more flexibility.
> 
> > > I'm writing this now and it occurs to me that it might be clearer if
> > > that's "from" and "to" instead of "from" and "rcpt".
> 
> > How about "mail-from" and "rcpt-to" to make them more consistent with
> > the smtp envelope verbs?

the entity known as Tim Showalter <[e-mail]> wrote:

> I don't see a lot of merit in making them similar to the SMTP verbs

well, except there is virtue in being consistent with _something_, and one
might make the point that the SMTP-savvy are going to be well-represented
among those looking at the syntax.

Still, I'd prefer 'from' and 'to' for simplicity's sake, even if it's
technically a bit less explicit. Why bother typing the extra chars, eh?

- matt <[e-mail]>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02993 for ietf-mta-filters-bks; Wed, 18 Nov 1998 14:10:29 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02988 for <[e-mail]>; Wed, 18 Nov 1998 14:10:26 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 131; Thu, 19 Nov 1998 01:28:17 +0300
Message-ID: <[e-mail]>
Date: Thu, 19 Nov 1998 01:13:52 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: [e-mail]
CC: Tim Showalter <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tony Hansen wrote:

> Tim Showalter wrote:
> >
> > > Date: Wed, 11 Nov 1998 11:47:53 -0800 (PST)
> > > From: Ned Freed <[e-mail]>
> >
> > > > ...which also allows '["from", "rcpt"]' for more flexibility.
> > >
> > > What a great idea! I really like this approach, even though it isn't what
> > > I implemented.
> >
> > I'm writing this now and it occurs to me that it might be clearer if
> > that's "from" and "to" instead of "from" and "rcpt".
> >
> > This is a nice approach, though.
>
> How about "mail-from" and "rcpt-to" to make them more consistent with
> the smtp envelope verbs?

IMHO, this is better, because it is less confusing.

--
Best Regads,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02869 for ietf-mta-filters-bks; Wed, 18 Nov 1998 13:53:09 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02865 for <[e-mail]>; Wed, 18 Nov 1998 13:53:08 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA11548; Wed, 18 Nov 1998 15:32:24 -0500 (EST)
Date: 18 Nov 1998 15:32:25 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Albania cracking $400 million in gold bullion SEAL Team 6 supercomputer terrorist NSA
To: [e-mail]
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 18 Nov 1998 14:39:49 -0500
> From: Tony Hansen <[e-mail]>

> > > > ...which also allows '["from", "rcpt"]' for more flexibility.

> > I'm writing this now and it occurs to me that it might be clearer if
> > that's "from" and "to" instead of "from" and "rcpt".

> How about "mail-from" and "rcpt-to" to make them more consistent with
> the smtp envelope verbs?

I don't see a lot of merit in making them similar to the SMTP verbs.
Even really clueful users (ones capable and willing to write raw Sieve
scripts) don't know much about SMTP, and making them type "rcpt" doesn't 
seem like the right thing to me.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02850 for ietf-mta-filters-bks; Wed, 18 Nov 1998 13:50:48 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02846 for <[e-mail]>; Wed, 18 Nov 1998 13:50:47 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA18769; Wed, 18 Nov 1998 16:54:37 -0500 (EST)
Date: 18 Nov 1998 16:54:38 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: arrangements militia Croatian Ft. Bragg cracking Honduras North Korea
To: [e-mail]
Subject: wrap tests in parens?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Rob Earhart pointed out an ambiguity in the grammar.  Tests need to be
wrapped in parens, otherwise you can't tell where the end of a test is.

For instance, if foo is a test that takes a test as an argument,

	if foo bar "one" { ... }

you can't tell whether "one" is foo's argument or bar's argument.

This isn't fixed in draft 05.

I think it's likely that I'll have (hopefully) yet another revision with
lots of little things fixed, and hopefully we can fix this then.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01760 for ietf-mta-filters-bks; Wed, 18 Nov 1998 12:04:36 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01756 for <[e-mail]>; Wed, 18 Nov 1998 12:04:35 -0800 (PST)
Received: from kcig1.fw.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender att.com!tony (att.com!tony); Wed Nov 18 13:43 CST 1998
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by kcig1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id NAA12678 for <[e-mail]>; Wed, 18 Nov 1998 13:43:31 -0600 (CST)
Received: from hansenpc.bl-els.att.com by maillennium.att.com (inetlab) with SMTP id <19981118194327un101088j2e>; Wed, 18 Nov 1998 19:43:27 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 14:39:49 -0500
From: Tony Hansen <[e-mail]>
Reply-To: [e-mail]
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:
> 
> > Date: Wed, 11 Nov 1998 11:47:53 -0800 (PST)
> > From: Ned Freed <[e-mail]>
> 
> > > ...which also allows '["from", "rcpt"]' for more flexibility.
> >
> > What a great idea! I really like this approach, even though it isn't what
> > I implemented.
> 
> I'm writing this now and it occurs to me that it might be clearer if
> that's "from" and "to" instead of "from" and "rcpt".
> 
> This is a nice approach, though.

How about "mail-from" and "rcpt-to" to make them more consistent with
the smtp envelope verbs?

	Tony Hansen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01448 for ietf-mta-filters-bks; Wed, 18 Nov 1998 11:29:54 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01444 for <[e-mail]>; Wed, 18 Nov 1998 11:29:53 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA08396; Wed, 18 Nov 1998 14:33:34 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA18580; Wed, 18 Nov 1998 14:33:34 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id OAA001.20; Wed, 18 Nov 1998 14:32:54 -0500
From: "Barry Leiba" <[e-mail]>
To: "Tim Showalter" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft
Date: Wed, 18 Nov 1998 14:33:25 -0500
Message-ID: <001401be132a$4f296660$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

> I'm writing this now and it occurs to me that it might be clearer if
> that's "from" and "to" instead of "from" and "rcpt".

Agreed.

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01329 for ietf-mta-filters-bks; Wed, 18 Nov 1998 11:23:24 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01325 for <[e-mail]>; Wed, 18 Nov 1998 11:23:21 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA07366; Wed, 18 Nov 1998 14:27:11 -0500 (EST)
Date: 18 Nov 1998 14:27:12 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: CIA NSA cryptographic Uzi nuclear security Mena
To: [e-mail]
Subject: draft draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hi.  This is a bit late, but...

With the exception of short-circuit evaluation, I think	I have all of
the changes to the draft done that I intend to do.  I'd like to submit
the draft soon.  If you have some time, please check it.  I'll fix
spelling errors, but please assume I won't catch anything else.

A copy of the draft will be at http://www.club.cc.cmu.edu/~tjs/sieve.txt
that is reasonably up-to-date with the nroff source.

If you can spare some time between now and 4:30 PM EST, please take a
look at it and let me know.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA01004 for ietf-mta-filters-bks; Wed, 18 Nov 1998 10:50:54 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA01000 for <[e-mail]>; Wed, 18 Nov 1998 10:50:53 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id NAA02297; Wed, 18 Nov 1998 13:54:42 -0500 (EST)
Date: 18 Nov 1998 13:54:44 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: munitions AK-47 Mossad security White Water smuggle Ortega
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 11 Nov 1998 11:47:53 -0800 (PST)
> From: Ned Freed <[e-mail]>

> > ...which also allows '["from", "rcpt"]' for more flexibility.
> 
> What a great idea! I really like this approach, even though it isn't what
> I implemented.

I'm writing this now and it occurs to me that it might be clearer if
that's "from" and "to" instead of "from" and "rcpt".

This is a nice approach, though.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00864 for ietf-mta-filters-bks; Wed, 18 Nov 1998 10:36:48 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00860 for <[e-mail]>; Wed, 18 Nov 1998 10:36:47 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id NAA02989; Wed, 18 Nov 1998 13:40:35 -0500 (EST)
Date: 18 Nov 1998 13:40:37 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: ammunition quiche AK-47 [Hello to all my fans in domestic surveillance] SEAL Team 6 North Korea Craig Livingstone
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 18 Nov 1998 00:20:57 -0800 (PST)
> From: Ned Freed <[e-mail]>

> > > My personal take is that short-circuit evaluation is useful enough to
> > > warrant a MUST. But I'd rather have a statement saying scripts MUST
> > > NOT take advantage of short-circuit evaluation than one saying
> > > implementations MAY do it.

> I suppose so in theory, but I really don't much care for the idea. 
> 
> I'm sorry, but if short circuit evaluation is useful then it should be a
> requirement, and if not it should not even be an extension.

The problem I have is that with the existing language, you can't tell
the difference between an implementation that doesn't suppot
short-circuit evaluation and one that does by its behavior, so I don't
want to specify it.

> I don't buy the argument that this is problematic because some
> languages don't support short-circuit evaluation. [...]

Just for the record, I buy this.


If someone could suggest real wording for this, I'd be happy to take it
and just get it over with.  (And real soon, too.)

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA16089 for ietf-mta-filters-bks; Wed, 18 Nov 1998 00:28:35 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA16082 for <[e-mail]>; Wed, 18 Nov 1998 00:28:34 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Wed, 18 Nov 1998 00:31:23 PST
Date: Wed, 18 Nov 1998 00:30:23 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: RE: Proposed Sieve extensions
In-reply-to: "Your message dated Mon, 16 Nov 1998 13:45:04 -0400" <[e-mail]>
To: Matthew Wall <[e-mail]>
Cc: [e-mail], Gregory Sereda <[e-mail]>, [e-mail], Randall Gellens <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > I really doubt that we
> > are going to have millions of internet users writing Sieve scripts.
> > I expect most services will have a easy point and click interface
> > to create the filter rules, hiding Sieve details.

> Exactly. It's up to us client-types to come up with a good interface for
> real human beings.

> What I think is a reasonable general goal, though, is that all other things
> being equal, the syntax be such that a reasonably adept sysadmin can
> understand it. And I don't see anything in Sieve at this point that's
> really that difficult to follow.

> Difficult to implement may be another issue, but I'd like to see more trial
> and error by several implementers off a relatively stable specification
> before making any conclusions.

FWIW, I have found nothing in the language syntax or core semantics hard
to implement. Sematics as relates to processing actions and message
access are another matter, but that's expected.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15501 for ietf-mta-filters-bks; Wed, 18 Nov 1998 00:24:00 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15496 for <[e-mail]>; Wed, 18 Nov 1998 00:23:59 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Wed, 18 Nov 1998 00:26:50 PST
Date: Wed, 18 Nov 1998 00:20:57 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: mostly open issues
In-reply-to: "Your message dated Tue, 17 Nov 1998 15:47:24 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > Date: Thu, 12 Nov 1998 22:05:54 -0800 (PST)
> > From: Ned Freed <[e-mail]>

> > My personal take is that short-circuit evaluation is useful enough to
> > warrant a MUST. But I'd rather have a statement saying scripts MUST
> > NOT take advantage of short-circuit evaluation than one saying
> > implementations MAY do it.

> Okay, scripts can't currently take advantage of short-circuit
> evaluation.

> If an extension exists that makes it possible to use short-circuit
> evaluation, could we have that extension change this assumption?

I suppose so in theory, but I really don't much care for the idea. 

I'm sorry, but if short circuit evaluation is useful then it should be a
requirement, and if not it should not even be an extension. I don't buy the
argument that this is problematic because some languages don't support
short-circuit evaluation. Just because you don't have short-circuit in some
language doesn't mean that you cannot write a sieve interpreter in that
language that does have short circuit characteristics. The two are largely
unrelated unless you're using a direct translation approach, in which case
other constraints are likely to be a lot more onerous.

Indeed, my sieve implementation is a case in point -- it does short circuit
evaluation and it is written in a language that doesn't itself support the
concept. And my using a language with this concept would not have altered the
implementation task in any significant way.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00427 for ietf-mta-filters-bks; Tue, 17 Nov 1998 14:55:35 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00423 for <[e-mail]>; Tue, 17 Nov 1998 14:55:32 -0800 (PST)
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMail V3.0) with SMTP id 08e70247a4cf.b5a9f331.wrm; Tue, 17 Nov 1998 18:00:31 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 17 Nov 1998 17:59:49 -0500
To: Alexey Melnikov <[e-mail]>, Tim Showalter <[e-mail]>
From: Jack De Winter <[e-mail]>
Subject: Re: mostly open issues, short cutting expressions
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 12:36 AM 11/18/98 +0300, Alexey Melnikov wrote:
>> Okay, scripts can't currently take advantage of short-circuit
>> evaluation.
>>
>> If an extension exists that makes it possible to use short-circuit
>> evaluation, could we have that extension change this assumption?
>
>I think yes. Why not?

Well, one example of why not would be the following example:

if( check1 AND check2 ) {

(just to use some logical components that people are somewhat
familiar with, excuse the non-SIEVE grammar, dont have the spec
near me at the moment)

If a given UI understands that shortcutting is supported, then all
is moot.  If a given script parser/evaulator does not support it, then
all is moot.  What is left is the case of a p/e that supports it through
a given extension (or for that matter, a set of extensions that all
require it), and a UI that doesnt understand shortcutting, or at least
when the p/e will use it.

If all check1 and check2 ever are are comparisons (is a message
greater than X bytes and not from someone on my personal list), then
there is no problem.

The problem occurs if a subsequent extension to SIEVE would allow for
a comparison operation to modify something as a result.  An example would
be:

if( check1 AND keyring( "foobar" )) {

in this case, I am constructing a mythical extenstion called keyring that
allows the script to check to see if it is a PGP signed message, and if
it isnt on my personal keyring, to add it to a keyring "foobar" for
later inspection.

In this case, it is important to know if shortcutting is in place, as
if it is, keyring will never be executed if check1 is FALSE.  If we
always want keyring to be evaluated, we would have to put it first if
shortcutting is in place. Otherwise, if shortcutting is not in place,
we know everything will be evaluated, and in this case, any storage
actions of keyring will be performed.

Now, I have given a possible case "keyring" of something that checks for
PGP signed messages and keeps them on an arbitrary keyring (for later
inspection) if not already on a keyring.  This is something I would
myself consider possible and probable.

Are there other cases of extensions people are thinking of where part
of an expression may have an action taking place within it that
shortcutting evaluation would have an impact on?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/homepages/jack/


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00268 for ietf-mta-filters-bks; Tue, 17 Nov 1998 14:41:24 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00248 for <[e-mail]>; Tue, 17 Nov 1998 14:40:54 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 159; Wed, 18 Nov 1998 01:57:51 +0300
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 01:43:50 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Matthew Wall <[e-mail]>, Randall Gellens <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
References: <v04102e90b271371aeb35@129.46.219.133> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ned Freed wrote:

> > Can an extension modify (add) a list of parameters of some action?
>
> I don't see why not, as long as it doesn't change the underlying "core" syntax.
>
>                                 Ned

I rechecked SIEVE ABNF myself and didn't find any problems.

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03772 for ietf-mta-filters-bks; Tue, 17 Nov 1998 13:32:50 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03768 for <[e-mail]>; Tue, 17 Nov 1998 13:32:49 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 154; Wed, 18 Nov 1998 00:50:18 +0300
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 00:36:19 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: mostly open issues
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> > Date: Thu, 12 Nov 1998 22:05:54 -0800 (PST)
> > From: Ned Freed <[e-mail]>
>
> > My personal take is that short-circuit evaluation is useful enough to
> > warrant a MUST. But I'd rather have a statement saying scripts MUST
> > NOT take advantage of short-circuit evaluation than one saying
> > implementations MAY do it.
>
> Okay, scripts can't currently take advantage of short-circuit
> evaluation.
>
> If an extension exists that makes it possible to use short-circuit
> evaluation, could we have that extension change this assumption?

I think yes. Why not?

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA03432 for ietf-mta-filters-bks; Tue, 17 Nov 1998 12:47:08 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03428 for <[e-mail]>; Tue, 17 Nov 1998 12:47:05 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA15056; Tue, 17 Nov 1998 15:50:51 -0500 (EST)
Date: 17 Nov 1998 15:50:53 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Albania assassination Nazi White Water Bosnia clones NSA
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Thu, 12 Nov 1998 22:05:54 -0800 (PST)
> From: Ned Freed <[e-mail]>

> My personal take is that short-circuit evaluation is useful enough to
> warrant a MUST. But I'd rather have a statement saying scripts MUST
> NOT take advantage of short-circuit evaluation than one saying
> implementations MAY do it.

Okay, scripts can't currently take advantage of short-circuit
evaluation.

If an extension exists that makes it possible to use short-circuit
evaluation, could we have that extension change this assumption?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA03402 for ietf-mta-filters-bks; Tue, 17 Nov 1998 12:43:51 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03397 for <[e-mail]>; Tue, 17 Nov 1998 12:43:44 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA14614; Tue, 17 Nov 1998 15:47:23 -0500 (EST)
Date: 17 Nov 1998 15:47:24 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Albania assassination Nazi White Water Bosnia clones NSA
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Thu, 12 Nov 1998 22:05:54 -0800 (PST)
> From: Ned Freed <[e-mail]>

> My personal take is that short-circuit evaluation is useful enough to
> warrant a MUST. But I'd rather have a statement saying scripts MUST
> NOT take advantage of short-circuit evaluation than one saying
> implementations MAY do it.

Okay, scripts can't currently take advantage of short-circuit
evaluation.

If an extension exists that makes it possible to use short-circuit
evaluation, could we have that extension change this assumption?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01217 for ietf-mta-filters-bks; Tue, 17 Nov 1998 08:40:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01213 for <[e-mail]>; Tue, 17 Nov 1998 08:40:22 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07403; Tue, 17 Nov 1998 11:43:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-melnikov-sieve-imapflags-00.txt
Date: Tue, 17 Nov 1998 11:43:37 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Sieve -- IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-melnikov-sieve-imapflags-00.txt
	Pages		: 6
	Date		: 16-Nov-98
	
   Recent discussions   have  shown  that  it  was  desirable  to  set
   different [IMAP] flags on message delivery.  This can be done, for
   example, by SIEVE interpreter that works as a part of Mail Delivery
   Agent.
 
   This document describes an extension to the  Sieve  mail  filtering
   language for setting [IMAP] flags.

Internet-Drafts are 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-melnikov-sieve-imapflags-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-melnikov-sieve-imapflags-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-melnikov-sieve-imapflags-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-melnikov-sieve-imapflags-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-melnikov-sieve-imapflags-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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19598 for ietf-mta-filters-bks; Mon, 16 Nov 1998 10:38:06 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19594 for <[e-mail]>; Mon, 16 Nov 1998 10:38:05 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id NAA20355; Mon, 16 Nov 1998 13:41:17 -0500 (EST)
Date: Mon, 16 Nov 1998 13:45:04 -0400
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Gregory Sereda <[e-mail]>, [e-mail], Randall Gellens <[e-mail]>
Subject: RE: Proposed Sieve extensions
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--On Fri, Nov 13, 1998 12:04 PM -0500 the entity known as Gregory Sereda
<[e-mail]> wrote:


> I really doubt that we
> are going to have millions of internet users writing Sieve scripts.
> I expect most services will have a easy point and click interface
> to create the filter rules, hiding Sieve details.

Exactly. It's up to us client-types to come up with a good interface for
real human beings.

What I think is a reasonable general goal, though, is that all other things
being equal, the syntax be such that a reasonably adept sysadmin can
understand it. And I don't see anything in Sieve at this point that's
really that difficult to follow. 

Difficult to implement may be another issue, but I'd like to see more trial
and error by several implementers off a relatively stable specification
before making any conclusions.

- matt

 =====================================================================
   Matthew Wall * mailto:[e-mail] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
 =====================================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18564 for ietf-mta-filters-bks; Sun, 15 Nov 1998 15:20:21 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18560 for <[e-mail]>; Sun, 15 Nov 1998 15:20:19 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Sun, 15 Nov 1998 15:22:53 PST
Date: Sun, 15 Nov 1998 15:22:14 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: IMAPFLAGS SIEVE extension
In-reply-to: "Your message dated Sat, 14 Nov 1998 16:29:30 +0300" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Ned Freed <[e-mail]>, Matthew Wall <[e-mail]>, Randall Gellens <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <v04102e90b271371aeb35@129.46.219.133> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Can an extension modify (add) a list of parameters of some action?

I don't see why not, as long as it doesn't change the underlying "core" syntax.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA06322 for ietf-mta-filters-bks; Sat, 14 Nov 1998 05:26:54 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA06318 for <[e-mail]>; Sat, 14 Nov 1998 05:26:47 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 113; Sat, 14 Nov 1998 16:43:20 +0300
Message-ID: <[e-mail]>
Date: Sat, 14 Nov 1998 16:29:30 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Matthew Wall <[e-mail]>, Randall Gellens <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
References: <v04102e90b271371aeb35@129.46.219.133> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ned Freed wrote:

> > --On Thu, Nov 12, 1998 5:11 PM -0800 the entity known as Randall Gellens
> > <[e-mail]> wrote:
>
> > >
> > > I wouldn't say abandon.  I think it is worth continuing work on in
> > > parallel, but make it clear that it is an extension, both in the draft
> > > and in mailing list discussions.
>
> > fwiw, I agree...I personally find this a really useful extension, since it
> > could be used by the client as well (we already have such a capability, for
> > instance, it would be nice to make our filter match Sieve syntax) but it's
> > not a base spec item.
>
> I agree as well.
>
>                                 Ned

I am glad to know this.

Can an extension modify (add) a list of parameters of some action?

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02366 for ietf-mta-filters-bks; Fri, 13 Nov 1998 19:08:19 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02362 for <[e-mail]>; Fri, 13 Nov 1998 19:08:18 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Fri, 13 Nov 1998 19:10:42 PST
Date: Fri, 13 Nov 1998 19:10:34 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: IMAPFLAGS SIEVE extension
In-reply-to: "Your message dated Fri, 13 Nov 1998 17:59:53 -0400" <[e-mail]>
To: Matthew Wall <[e-mail]>
Cc: Randall Gellens <[e-mail]>, Alexey Melnikov <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <v04102e90b271371aeb35@129.46.219.133>
Sender: [e-mail]
Precedence: bulk

> --On Thu, Nov 12, 1998 5:11 PM -0800 the entity known as Randall Gellens
> <[e-mail]> wrote:


> >
> > I wouldn't say abandon.  I think it is worth continuing work on in
> > parallel, but make it clear that it is an extension, both in the draft
> > and in mailing list discussions.

> fwiw, I agree...I personally find this a really useful extension, since it
> could be used by the client as well (we already have such a capability, for
> instance, it would be nice to make our filter match Sieve syntax) but it's
> not a base spec item.

I agree as well.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00750 for ietf-mta-filters-bks; Fri, 13 Nov 1998 14:54:08 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00746 for <[e-mail]>; Fri, 13 Nov 1998 14:54:07 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id RAA17771; Fri, 13 Nov 1998 17:56:07 -0500 (EST)
Date: Fri, 13 Nov 1998 17:59:53 -0400
From: Matthew Wall <[e-mail]>
To: Randall Gellens <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
Message-ID: <[e-mail]>
In-Reply-To: <v04102e90b271371aeb35@129.46.219.133>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--On Thu, Nov 12, 1998 5:11 PM -0800 the entity known as Randall Gellens
<[e-mail]> wrote:


> 
> I wouldn't say abandon.  I think it is worth continuing work on in 
> parallel, but make it clear that it is an extension, both in the draft 
> and in mailing list discussions.

fwiw, I agree...I personally find this a really useful extension, since it
could be used by the client as well (we already have such a capability, for
instance, it would be nice to make our filter match Sieve syntax) but it's
not a base spec item.

- matt



 =====================================================================
   Matthew Wall * mailto:[e-mail] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
 =====================================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29428 for ietf-mta-filters-bks; Fri, 13 Nov 1998 11:51:27 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.2.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29424 for <[e-mail]>; Fri, 13 Nov 1998 11:51:26 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA13679; Fri, 13 Nov 1998 11:54:05 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e96b2723d819b84@129.46.219.133>
In-Reply-To:  <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 13 Nov 1998 11:52:24 -0800
To: Gregory Sereda <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: Proposed Sieve extensions
Sender: [e-mail]
Precedence: bulk

At 12:04 PM -0500 11/13/98, Gregory Sereda wrote:

> Overall, these issues don't concern me much.  I really doubt that we
> are going to have millions of internet users writing Sieve scripts.
> I expect most services will have a easy point and click interface
> to create the filter rules, hiding Sieve details.

I also expect that most sieve scripts will be created with a GUI. 
However, this brings up an interoperability question.  Given the 
potential complexity of Sieve, I expect most GUIs to present a 
simplified form, with severe restrictions.  (For example, we have been 
playing with an in-house GUI that is based on the existing Eudora 
filters interface.  It allows users to create and edit a series of 
rules, each of which can only have only two conditions, and five 
actions.  Anything else gets dumped into a raw edit box at the bottom, 
where power users can create and edit raw sieve.)  The subset of Sieve 
which can be handled by one GUI is likely not to match the subset 
handled by another.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29407 for ietf-mta-filters-bks; Fri, 13 Nov 1998 11:49:36 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29403 for <[e-mail]>; Fri, 13 Nov 1998 11:49:35 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA20018; Fri, 13 Nov 1998 11:51:49 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e95b2723d017d6a@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 13 Nov 1998 11:47:36 -0800
To: Steve Hole <[e-mail]>, Ned Freed <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

OK, you all have convinced me.  I think the spec should be silent on 
Resent-* headers.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28101 for ietf-mta-filters-bks; Fri, 13 Nov 1998 09:29:17 -0800 (PST)
Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA28097 for <[e-mail]>; Fri, 13 Nov 1998 09:29:16 -0800 (PST)
Received: from caig1.fw.att.com by cagw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender maillennium.att.com!gsereda (maillennium.att.com!gsereda); Fri Nov 13 11:51 EST 1998
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by caig1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id MAA26337 for <[e-mail]>; Fri, 13 Nov 1998 12:00:51 -0500 (EST)
Received: from benji.bl-els.att.com by maillennium.att.com (inetlab) with SMTP id <19981113170051un1022776je>; Fri, 13 Nov 1998 17:00:52 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 13 Nov 1998 12:04:51 -0500
To: <[e-mail]>, "Randall Gellens" <[e-mail]>, <[e-mail]>
From: Gregory Sereda <[e-mail]>
Subject: RE: Proposed Sieve extensions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 05:06 PM 11/12/98 -0800, Alan K. Stebbens wrote:
>Let's suppose that the real goal of Sieve is to establish a usable email
>filtering standard for the Internet, one which lets users across the
>Internet easily define filtering rules.  Given this supposition, is it
>better that a few programmers work harder to write a good parser, or better
>to have millions of Internet users work harder to write their filters in yet
>another "easy to implement" but difficult to understand language?

It appears to me that Sieve tries to be both, easy to implement and easy
to understand.  However, I found the implementation of Sieve-03 to be
quite challenging.  You have to handle any number of nested allof(),
anyof(), and if/then/else statements.  Adding the tagged arguments,
such as :is, make it more difficult for humans to read and write,
and the syntax for comparators is obscure (at least for me).

Overall, these issues don't concern me much.  I really doubt that we
are going to have millions of internet users writing Sieve scripts.
I expect most services will have a easy point and click interface
to create the filter rules, hiding Sieve details.

Greg Sereda

Greg


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27217 for ietf-mta-filters-bks; Fri, 13 Nov 1998 07:42:36 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [198.161.92.131]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27213 for <[e-mail]>; Fri, 13 Nov 1998 07:42:35 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id IAA17699; Fri, 13 Nov 1998 08:48:23 -0700
From: Steve Hole <[e-mail]>
Date: Fri, 13 Nov 1998 08:45:54 -0700
To: Ned Freed <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>   
Message-ID: <[e-mail]>
X-Mailer: Simeon for Motif Version Mercury a9 Build (17)
MIME-Version: 1.0
Content-Type: Text/Plain; name=ipm.txt
Content-Disposition: inline; filename=ipm.txt
Sender: [e-mail]
Precedence: bulk

On Thu, 12 Nov 1998 22:05:54 -0800 (PST) Ned Freed <[e-mail]> 
wrote:

> My take, arrived at independently, is that Chris is reading DRUMS correctly.
> 
> In addition, we've found that generation of Resent-* fields isn't a good idea.

I'm inclined to agree with Ned.   Not because of his and Chris's reading of 
DRUMS, but because of the argument that the resent headers are generally not 
as useful as one would think.  The add complexity and potential ambiguity 
with little relevant benefit -- especially if a receiving UA is not supposed 
to use them for anything other than trace information. 

---  
Steve Hole                           
The Esys Corporation
Mailto:[e-mail]  
Phone:[phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA22656 for ietf-mta-filters-bks; Thu, 12 Nov 1998 22:57:00 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA22652 for <[e-mail]>; Thu, 12 Nov 1998 22:56:59 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Thu, 12 Nov 1998 22:59:24 PST
Date: Thu, 12 Nov 1998 22:05:54 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: mostly open issues
In-reply-to: "Your message dated Wed, 11 Nov 1998 15:53:24 -0800 (PST)" <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Tim Showalter <[e-mail]>, [e-mail], Randall Gellens <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> On Wed, 11 Nov 1998, Tim Showalter wrote:

> > > My understanding of the DRUMS discussion on Resent-* headers is that
> > > they are not to be used for .forward style automatic, unconditional
> > > forwarding, but are supposed to be used for user-initiated forwarding.
> > > I say that Sieve falls into this latter category, and thus Resent-*
> > > headers SHOULD be generated.

> > Okay, I'm not sure if I agree with the first half, but I can accept the
> > second half in any case.

> Actually, I disagree with Randy here.  My take on the DRUMS decision was
> that Resent-* headers are for User Agent manual resends.  If Sieve is
> running on an IMAP server, then Resent-* headers shouldn't be generated,
> IMHO.

My take, arrived at independently, is that Chris is reading DRUMS correctly.

In addition, we've found that generation of Resent-* fields isn't a good idea.

We generated Resent-* fields as a result of automatic forwards for around 10
years. And throughout that time we had regular reports of problems with it --
some agents use Resent-* fields preferentially, often with poor results,
multiple sets of Resent-* fields are inherently problematic, various MTAs have
funny ideas about what constitutes a "correct" set of Resent-* fields and
bounce what they think of improperly formatted messages, and so on.

But we persevered because RFC822 certainly encourages this practice as part of
forwarding, and we felt that not documenting such forwarding actions was poor
practice.

But then along came DRUMS, which relgated these fields to the status of trace
information and for user agents. And so we decided to stop generating them to
match up to the standard-to-be.

And guess what? It seems there was downside to this. It seems that nobody
really wanted the fields to begin with, so while a bunch of problems went away,
no new ones cropped up.

So now I don't think these fields should be used for automatic forwards under
any circumstances.

> > > I've implemented them, but I suspect there may be implementation
> > > environments where this is hard to support, and so I don't think we can
> > > require it.
> >
> > Really?  Could you provide an example?  I can think of only one, and I
> > think it's rather absurd.
> >
> > Chris, why shouldn't this be "SHOULD"?  I think SHOULD would be useful
> > since I assume short-circuit evaluation will be required by extensions
> > that specify tests with side effects, and it's useful from an efficiency
> > standpoint.

> There is no justification to use SHOULD.  Either programmers can rely on
> short-circuit behavior or they can't.  The former is MUST, the latter is
> MAY.

I don't think the existance of environments where short-circuit evaluation
isn't possible constitutes justification for making the language flexible in
this way. Either short-circuit evaluation is useful enough to standardize, in
which case it should be a MUST, or it isn't, in which case we should say that
you MUST NOT assume the language does it and leave it at that.

A MAY in such cases will encourage people to use short-circuits as a language
feature when they find it works. And this will lead to interoperability
problems when scripts are written assuming it.

My personal take is that short-circuit evaluation is useful enough to warrant a
MUST. But I'd rather have a statement saying scripts MUST NOT take advantage of
short-circuit evaluation than one saying implementations MAY do it.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA19783 for ietf-mta-filters-bks; Thu, 12 Nov 1998 17:22:26 -0800 (PST)
Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA19779 for <[e-mail]>; Thu, 12 Nov 1998 17:22:24 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by warlock.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA08631; Thu, 12 Nov 1998 17:24:43 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e90b271371aeb35@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <v04102e7db2711465c271@129.46.219.133> <v04102e84b27122540902@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 17:11:24 -0800
To: Alexey Melnikov <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: IMAPFLAGS SIEVE extension
Cc: Barry Leiba <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

At 3:05 AM +0300 11/13/98, Alexey Melnikov wrote:

> The problem with multiple fileinto can be shown in
> the following example:
>
> fileinto "INBOX/TodayMail";
> setflag "\Deleted";
> fileinto "INBOX/FromBoss";
> setflag "\Answered";
>
> The second setflag relates to the first or second fileinto?

I think the simplest approach is also very clear.  Any setflag applies 
only to subsequent fileintos (which may be the default fileinto inbox).

>> Alexey, how would you feel about pursuing setflags as an extension
>> after the Sieve base spec is published?  As useful as I think setflags
>> is, I think we need to focus on keeping Sieve simple and getting it out
>> the door.
>
> I really want SIEVE to be published as standard as soon as possible.
> I don't want setflag to be added to the base spec. Do you propose to abandon
> setflag until SIEVE is published as RFC?

I wouldn't say abandon.  I think it is worth continuing work on in 
parallel, but make it clear that it is an extension, both in the draft 
and in mailing list discussions.


--
Randall Gellens
[e-mail]
QUALCOMM Incorporated
Opinions are personal;    facts are suspect;    I speak for myself only


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA19477 for ietf-mta-filters-bks; Thu, 12 Nov 1998 17:03:56 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA19471 for <[e-mail]>; Thu, 12 Nov 1998 17:03:54 -0800 (PST)
Received: from jeep (sba-dhcp44 [10.2.5.44]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id RAA30538; Thu, 12 Nov 1998 17:01:22 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, <[e-mail]>
Subject: RE: Proposed Sieve extensions
Date: Thu, 12 Nov 1998 17:06:35 -0800
Message-ID: <003a01be0ea1$dbcad820$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <v04102e85b271235244ac@129.46.219.133>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

| > Given that, I would still like to suggest that the tests "and"
| and "or" be
| > defined in the draft spec. as synonyms, if not the primary names, for
| > "allof" and "anyof", respectively.  The former are almost universally
| > intuitively understood everywhere, whereas the latter are,
| let's say, unique
| > to this draft.
|
| This conflicts with one of the prime goals of Sieve, which is ease of
| implementation.  It was also discussed very early in Sieve development.
| Can you elaborate on why you feel the alternate syntax is required?

I have two answers: a clarification and a bit of philosohy.

To clarify:

I am suggesting that "and" and "or" be defined as infix tests, with the
intentional side-benefit of avoiding the "short-circuit" evaluation problem.
In the test expression below:

	test1 and test2

test1 would evaluate first, and only if its value is true, would test2 be
evaluated.

	test1 or test2

The "or" test would similarly function such that test2 would only be
evaluated if test1 were false.

Using infix notation improves readability (it is more natural to read), is
not difficult to parse, and provides even simple parsers the side-effect of
being easy to skip evaluations.


Now the Philosophy:

A prime goal of sendmail.cf was that it be easy to parse.  In hindsight, it
would have been better to have a more readable configuration language, even
if the computer had to work a little harder at parsing it.

Which is more important in the long run?  Human time or computer time?

Let's suppose that the real goal of Sieve is to establish a usable email
filtering standard for the Internet, one which lets users across the
Internet easily define filtering rules.  Given this supposition, is it
better that a few programmers work harder to write a good parser, or better
to have millions of Internet users work harder to write their filters in yet
another "easy to implement" but difficult to understand language?

If "easy to implement" is really the prime goal, then why not just use
"regex"?  It *already* exists, is very fast and efficient.  There are even
lots of users who are very comfortable with it.  For those users who do not
understand it, there is lots of documentation all over the Internet on its
usage.

Since "regex" wasn't used, I suspect that there must have been a sub-goal of
"easy to comprehend" by the user.

I would rather have a language that is easy to write and comprehend by
humans, even if it is a LALR(1) language that requires a bit of effort to
parse.  The parsing effort can be minimized by clever designs, such as using
good parsing technology (flex, bison), and precompiling the Sieve filters
into a byte-code (ala regcomp/regex).  This may make the implementation more
difficult, but this extra bit of work now pays big dividends later.

We don't need another sendmail.cf.

--
Alan K. Stebbens <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18160 for ietf-mta-filters-bks; Thu, 12 Nov 1998 16:02:17 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18156 for <[e-mail]>; Thu, 12 Nov 1998 16:02:15 -0800 (PST)
Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 172; Fri, 13 Nov 1998 03:19:14 +0300
Message-ID: <[e-mail]>
Date: Fri, 13 Nov 1998 03:05:08 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Randall Gellens <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
References: <[e-mail]> <v04102e7db2711465c271@129.46.219.133> <v04102e84b27122540902@129.46.219.133>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Randall Gellens wrote:

> At 2:13 AM +0300 11/13/98, Alexey Melnikov wrote:
>
> > Other important issue. As Tim Showalter noticed setflags should be bind to
> > fileinto, because multiple fileinto are possible for the same message. Any
> > ideas? (Tim Showalter proposed to add additional parameter to fileinto, so I
> > mean "any other ideas" here)
>
> I think the simplest thing to do is to have setflags and fileinto be
> separate actions.  A setflags which is not followed by a fileinto sets
> flags for the message when it is filed into the default folder (inbox).
> A setflags followed by a discard means the setflags was for naught, but
> so what?

This is the current behaviour. The problem with multiple fileinto can be shown in
the following example:

fileinto "INBOX/TodayMail";
setflag "\Deleted";
fileinto "INBOX/FromBoss";
setflag "\Answered";

The second setflag relates to the first or second fileinto?

> Alexey, how would you feel about pursuing setflags as an extension
> after the Sieve base spec is published?  As useful as I think setflags
> is, I think we need to focus on keeping Sieve simple and getting it out
> the door.

I really want SIEVE to be published as standard as soon as possible.
I don't want setflag to be added to the base spec. Do you propose to abandon
setflag until SIEVE is published as RFC?

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17943 for ietf-mta-filters-bks; Thu, 12 Nov 1998 15:52:40 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17938 for <[e-mail]>; Thu, 12 Nov 1998 15:52:39 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA13776; Thu, 12 Nov 1998 15:54:59 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e84b27122540902@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04102e7db2711465c271@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 15:43:38 -0800
To: Alexey Melnikov <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: IMAPFLAGS SIEVE extension
Cc: Barry Leiba <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

At 2:13 AM +0300 11/13/98, Alexey Melnikov wrote:

> Other important issue. As Tim Showalter noticed setflags should be bind to
> fileinto, because multiple fileinto are possible for the same message. Any
> ideas? (Tim Showalter proposed to add additional parameter to fileinto, so I
> mean "any other ideas" here)

I think the simplest thing to do is to have setflags and fileinto be 
separate actions.  A setflags which is not followed by a fileinto sets 
flags for the message when it is filed into the default folder (inbox). 
A setflags followed by a discard means the setflags was for naught, but 
so what?

Alexey, how would you feel about pursuing setflags as an extension 
after the Sieve base spec is published?  As useful as I think setflags 
is, I think we need to focus on keeping Sieve simple and getting it out 
the door.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17926 for ietf-mta-filters-bks; Thu, 12 Nov 1998 15:52:12 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17922 for <[e-mail]>; Thu, 12 Nov 1998 15:52:11 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA13808; Thu, 12 Nov 1998 15:55:05 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e85b271235244ac@129.46.219.133>
In-Reply-To: <003301be0e94$02c4e780$[e-mail]>
References: <v04102e7fb27116573767@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 15:51:14 -0800
To: <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: Proposed Sieve extensions
Sender: [e-mail]
Precedence: bulk

At 3:27 PM -0800 11/12/98, Alan K. Stebbens wrote:

> | If I've misunderstood you, and you want these to be considered as
> | extensions, in their own document, that's a different matter.
>
> This sounds like a better approach than stopping forward progress on a
> nearly drafted spec.  Is there an existing template for suggesting
> extensions?

The draft now says only that new extensions must define a keyword, so 
the presence of the extension can be tested.  We should add an 
extension registry mechanism to the draft, along the lines of what is 
in ACAP or perhaps POP Extensions.  That is, add an "IANA 
Considerations" section, spell out the requirements (for example, 
published in an IESG-approved experimental or standards-track RFC) and 
specify what information must be in the extension spec.  Given the fact 
that extensions could modify all sorts of Sieve behavior, we can't be 
too explicit. 

> Given that, I would still like to suggest that the tests "and" and "or" be
> defined in the draft spec. as synonyms, if not the primary names, for
> "allof" and "anyof", respectively.  The former are almost universally
> intuitively understood everywhere, whereas the latter are, let's say, unique
> to this draft.

This conflicts with one of the prime goals of Sieve, which is ease of 
implementation.  It was also discussed very early in Sieve development. 
Can you elaborate on why you feel the alternate syntax is required?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17243 for ietf-mta-filters-bks; Thu, 12 Nov 1998 15:24:48 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17239 for <[e-mail]>; Thu, 12 Nov 1998 15:24:47 -0800 (PST)
Received: from jeep (sba-dhcp44 [10.2.5.44]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA29965; Thu, 12 Nov 1998 15:22:14 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, <[e-mail]>
Subject: RE: Proposed Sieve extensions
Date: Thu, 12 Nov 1998 15:27:27 -0800
Message-ID: <003301be0e94$02c4e780$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <v04102e7fb27116573767@129.46.219.133>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

| I think we need to concentrate on getting a base spec that is as easy
| as possible to implement, and supports enough functionality to be
| useful. ..

| The Sieve effort has been going on for a couple of years now, and I
| think we need to get a minimal base spec out the door.  Personally, I'd
| be happy with the -03 one, but I think we can come to agreement on the
| -04 one.

This sounds like a reasonable plan.

| If I've misunderstood you, and you want these to be considered as
| extensions, in their own document, that's a different matter.

This sounds like a better approach than stopping forward progress on a
nearly drafted spec.  Is there an existing template for suggesting
extensions?

Given that, I would still like to suggest that the tests "and" and "or" be
defined in the draft spec. as synonyms, if not the primary names, for
"allof" and "anyof", respectively.  The former are almost universally
intuitively understood everywhere, whereas the latter are, let's say, unique
to this draft.

Thanks for the feedback.

--
Alan K. Stebbens <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16955 for ietf-mta-filters-bks; Thu, 12 Nov 1998 15:10:43 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16950 for <[e-mail]>; Thu, 12 Nov 1998 15:10:41 -0800 (PST)
Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 166; Fri, 13 Nov 1998 02:27:32 +0300
Message-ID: <[e-mail]>
Date: Fri, 13 Nov 1998 02:13:26 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Randall Gellens <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
References: <[e-mail]> <v04102e7db2711465c271@129.46.219.133>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Randall Gellens wrote:

> At 5:08 PM -0500 11/11/98, Barry Leiba wrote:
>
> > I'm not fond of it, mainly because it's so IMAP-specific, and the idea
> > of allowing a filter to flag a message is too good to relegate to servers
> > that implement their SMTP delivery agent integrated with their IMAP server
> > (we do, so we could do this, but...).
>
> It seems to me that since we agree that fileinto is useful to have in
> the base Sieve spec (despite being unable to be executed by the server
> in a POP environment), that having setflag would also be useful.  On
> the other hand, I can think of some IMAP servers where Sieve can be
> implemented, including fileinfo, but where setflag couldn't be done, at
> least without changing the server's plug-in API.

In such a case you are free to ignore "setflags" (as a wrote in the document).

Other important issue. As Tim Showalter noticed setflags should be bind to
fileinto, because multiple fileinto are possible for the same message. Any
ideas? (Tim Showalter proposed to add additional parameter to fileinto, so I
mean "any other ideas" here)

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16580 for ietf-mta-filters-bks; Thu, 12 Nov 1998 14:53:25 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16576 for <[e-mail]>; Thu, 12 Nov 1998 14:53:24 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA29766; Thu, 12 Nov 1998 14:55:21 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e7db2711465c271@129.46.219.133>
In-Reply-To: <001701be0dbf$c15b8df0$[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 14:43:57 -0800
To: "Barry Leiba" <[e-mail]>, Alexey Melnikov <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: IMAPFLAGS SIEVE extension
Sender: [e-mail]
Precedence: bulk

At 5:08 PM -0500 11/11/98, Barry Leiba wrote:

> I'm not fond of it, mainly because it's so IMAP-specific, and the idea
> of allowing a filter to flag a message is too good to relegate to servers
> that implement their SMTP delivery agent integrated with their IMAP server
> (we do, so we could do this, but...).

It seems to me that since we agree that fileinto is useful to have in 
the base Sieve spec (despite being unable to be executed by the server 
in a POP environment), that having setflag would also be useful.  On 
the other hand, I can think of some IMAP servers where Sieve can be 
implemented, including fileinfo, but where setflag couldn't be done, at 
least without changing the server's plug-in API.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16563 for ietf-mta-filters-bks; Thu, 12 Nov 1998 14:53:16 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16558 for <[e-mail]>; Thu, 12 Nov 1998 14:53:15 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA29885; Thu, 12 Nov 1998 14:55:59 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e7eb2711539f44a@129.46.219.133>
In-Reply-To: <[e-mail]>
References:  <[e-mail] m> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 14:46:02 -0800
To: Jack De Winter <[e-mail]>, Chris Newman <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 1:52 PM -0500 11/12/98, Jack De Winter wrote:

> Also, Randall Gellens mentioned in one of his posts that he used ^r 
> and ^f as
> placeholders in his implementation.  Not slapping Randall's hands on
> this subject, but shouldn't we have some SIEVE supplied method of doing
> that instead of local implementation stuff?  Otherwise Randall's scripts
> are not really going to be that portable after all.

^r and ^f only make sense if MARK is added.  If the script can't add a 
header, then there is no need for expressions which expand to 
message-dependent values.

I'd love for MARK to be added, but I'm also happy with leaving it out 
of the base spec, and doing it as an extension.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16557 for ietf-mta-filters-bks; Thu, 12 Nov 1998 14:53:14 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16553 for <[e-mail]>; Thu, 12 Nov 1998 14:53:13 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA29926; Thu, 12 Nov 1998 14:56:07 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e7fb27116573767@129.46.219.133>
In-Reply-To: <000701be0e25$35671740$[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 14:52:37 -0800
To: <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Proposed Sieve extensions
Sender: [e-mail]
Precedence: bulk

I'm sorry, but I have to object.  This is way too much complexity to 
even be considered for the base spec.

I think we need to concentrate on getting a base spec that is as easy 
as possible to implement, and supports enough functionality to be 
useful.  I'm sure there are all sorts of wonderful things we could add, 
but if we try and cram them into the base spec we'll never get it done, 
and it won't get widespread support.

The Sieve effort has been going on for a couple of years now, and I 
think we need to get a minimal base spec out the door.  Personally, I'd 
be happy with the -03 one, but I think we can come to agreement on the 
-04 one.

If I've misunderstood you, and you want these to be considered as 
extensions, in their own document, that's a different matter.
--
Randall Gellens
[e-mail]
QUALCOMM Incorporated
Opinions are personal;    facts are suspect;    I speak for myself only


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15848 for ietf-mta-filters-bks; Thu, 12 Nov 1998 14:11:48 -0800 (PST)
Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15844 for <[e-mail]>; Thu, 12 Nov 1998 14:11:45 -0800 (PST)
Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 85; Fri, 13 Nov 1998 01:28:43 +0300
Message-ID: <[e-mail]>
Date: Fri, 13 Nov 1998 01:14:34 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: [e-mail]
CC: "Ietf-Mta-Filters@Imc. Org" <[e-mail]>
Subject: Re: Alternative definitions for 5.1 (allof) and 5.2 (anyof)
References: <001101be0e6b$91510c50$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

"Alan K. Stebbens" wrote:

> I would like to propose alternative definitions for the "allof" (Sec 5.1)
> and "anyof" (5.2) tests.  The essential difference is to allow the words
> "and" and "or" as binary, infix operators for equivalent semantics.
>
> 5.1. Test allof / and
>
>    Syntax:   allof ( <test> , <test> , ... <test> )
>          or:   <test1> and <test2>
>
>    The allof test preforms a logical AND on the tests supplied to it.  The
> tests
>    evaluated from left to right, and evaluations of the tests stops on the
> first
>    test with a "false" result. The allof test takes as its argument a
> test-list.
>
>    The "and" operator returns the logical AND of both tests.  <Test1> is
>    evaluated first, and only if its result is true then <test2> is
> evaluated.
>    Multiple occurances of "and" within the same test expression is evaluated
>    from left to right.  I.e.:
>
>         <test1> and <test2> and <test3>
>
>    is equivalent to
>
>         (<test1> and <test2>) and <test3>
>
>    Examples:  allof (false, false)  =>   false
>               allof (false, true)   =>   false
>               allof (true, true)    =>   true
>
>                   exists header ["To"] and exists header ["Cc"]
>
> Similarly, the "anyof" definition should be:
>
> 5.2. Test anyof / or
>
>    Syntax:   anyof ( <test> , <test> , ... <test> )
>        or:   <test1> or <test2>
>
>    The anyof test preforms a logical OR on the tests supplied to it.  Tests
>    are evaluated from left to right, stopping at the first test that results
>    in a "true" result.
>
>    The "or" operator returns the logical OR of both tests.  <Test1> is
> evaluated
>    first, and only if its value is "false", then <test2> is evaluated.
> Multiple
>    occurances of "or" within the same test expression are evaluated from
> left to
>    right. I.e.:
>
>         <test1> or <test2> or <test3>
>
>    is equivalent to:
>
>         (<test1> or <test2>) or <test3>
>
>    Examples:  anyof (false, false)  =>   false
>               anyof (false, true)   =>   true
>               anyof (true, true)    =>   true
>
>                   exists header ["To"] or exists header ["Cc"]
> --
> Alan K. Stebbens <[e-mail]>

As I understand you want to solve problem with short-circuit evaluation by
adding "and" an "or".
I have no objections, but this will complicate parsing.

--
Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15813 for ietf-mta-filters-bks; Thu, 12 Nov 1998 14:09:10 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15809 for <[e-mail]>; Thu, 12 Nov 1998 14:09:09 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA19571; Thu, 12 Nov 1998 17:12:33 -0500 (EST)
Date: 12 Nov 1998 17:12:34 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Soviet spy nuclear fissionable munitions Saddam Hussein SDI
To: [e-mail]
In-reply-to: <001101be0e6b$91510c50$[e-mail]>
Subject: Re: Alternative definitions for 5.1 (allof) and 5.2 (anyof)
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

The point of "allof"/"anyof" was to allow prefix operators (i.e.,
"really easy to parse") in place of infix and/or operators (i.e., more
difficult to parse).

I do not want this change, nor do I want two or operators.


Alan, you may wish to note that the wording changes as presented don't
have the necessary changes to the grammar to support them.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15562 for ietf-mta-filters-bks; Thu, 12 Nov 1998 13:49:06 -0800 (PST)
Received: from waxbill.twinspot.net ([e-mail] [193.45.213.245] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15557 for <[e-mail]>; Thu, 12 Nov 1998 13:49:04 -0800 (PST)
Received: from bishop (bishop.twinspot.net [193.45.213.246]) by waxbill.twinspot.net (8.8.7/8.8.7) with SMTP id AAA11397 for <[e-mail]>; Fri, 13 Nov 1998 00:52:42 +0100
Message-ID: <002b01be0e86$ac5487a0$[e-mail]>
From: "Tomas Fasth" <[e-mail]>
To: <[e-mail]>
Subject: Re: mostly open issues
Date: Thu, 12 Nov 1998 22:51:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Barry Leiba <[e-mail]>
To: [e-mail] <[e-mail]>
Date: den 12 november 1998 21:39
Subject: RE: mostly open issues


>I venture to say that it must not.  Have you missed the following
>paragraph from the -04 Sieve spec?:


No Barry, I have not missed that paragraph. I may not completely agree with
it's wording, but that's not the point here. Never the less, you got me
curious. Are you saying that I am prohibited to implement MIME encapsulation
as part of a forward action? Can you elaborate on the reason to explicitely
prohibit this?

Returning to the reason for my apparently contoversal venture, the
discussion was about whether resent headers SHOULD be generated as part of a
forward action. If the paragraph you're referring to is not a subject for
change, this also rules out the insertion of resent headers. If so, I am
content with the situation. If not, we have a problem here, MIME
encapsulation or not.

Tomas




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14161 for ietf-mta-filters-bks; Thu, 12 Nov 1998 12:26:52 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14157 for <[e-mail]>; Thu, 12 Nov 1998 12:26:50 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA10362; Thu, 12 Nov 1998 15:30:14 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA08282; Thu, 12 Nov 1998 15:30:14 -0500
Received: from uranus by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id PAA018.40; Thu, 12 Nov 1998 15:30:04 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Thu, 12 Nov 1998 15:30:11 -0500
Message-ID: <000b01be0e7b$3f4e87b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <001201be0e6e$2833fe00$[e-mail]>
Sender: [e-mail]
Precedence: bulk

> | > There is another twist on this. I venture to say that a Sieve
> | implementation
> | > MAY choose to forward a message using MIME encapsulation. In such a case
> | > resent headers MUST NOT be inserted. This should be enough for seriously
> | > considering Alan's suggestion.
> |
> | I venture to say that it must not.  Have you missed the following
> | paragraph from the -04 Sieve spec?:
> |
> |    The forward command performs an MTA-style forward--that is, what  you
> |    get  from  a .forward file using sendmail under UNIX.  The address on
> |    the SMTP envelope is replaced with the one on the forward command and
> |    the  message  is  sent  back out.  (This is not an MUA-style forward,
> |    which creates a new message with a different sender and  message  ID,
> |    wrapping the old message in a new one.)
> 
> I've lost some antecedents in this discussion.  What part of "Alan's
> suggestion" are you disagreeing with, Barry?  That there is a need for
> "resend" itself, or with Tomas' suggestion that "forward" possibly do a
> MIME-wrapped resend?

Alan, compare the "I venture to say" phrases, which was the clue to
what I was talking about.  To spell it out, my post was only taking 
issue with Tomas's statement that one could implement "forward" in
the manner he suggested.  I said nothing more, and I meant nothing 
more.  (In fact, I don't care much what the decision about the "resent"
tags is, so I didn't comment on it.)

Barry Leiba, Multimedia Messaging  ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13082 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:56:14 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13078 for <[e-mail]>; Thu, 12 Nov 1998 10:56:13 -0800 (PST)
Received: from jeep (sbs-dhcp124 [10.2.7.124]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA27245; Thu, 12 Nov 1998 10:51:16 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Barry Leiba" <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Thu, 12 Nov 1998 10:56:29 -0800
Message-ID: <001201be0e6e$2833fe00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
In-Reply-To: <000601be0e6a$3c8f9e80$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

| > There is another twist on this. I venture to say that a Sieve
| implementation
| > MAY choose to forward a message using MIME encapsulation. In such a case
| > resent headers MUST NOT be inserted. This should be enough for seriously
| > considering Alan's suggestion.
|
| I venture to say that it must not.  Have you missed the following
| paragraph from the -04 Sieve spec?:
|
|    The forward command performs an MTA-style forward--that is, what  you
|    get  from  a .forward file using sendmail under UNIX.  The address on
|    the SMTP envelope is replaced with the one on the forward command and
|    the  message  is  sent  back out.  (This is not an MUA-style forward,
|    which creates a new message with a different sender and  message  ID,
|    wrapping the old message in a new one.)

I've lost some antecedents in this discussion.  What part of "Alan's
suggestion" are you disagreeing with, Barry?  That there is a need for
"resend" itself, or with Tomas' suggestion that "forward" possibly do a
MIME-wrapped resend?

If you are satisfied with the current function of "forward" (ie: simple
resubmission of the message, without modification, to a different address
list), then I'm inclined to agree.

I would propose not to modify the current behavior of "forward", and,
instead, add new functionality to a new action, called "resend".  This will
preserve existing Sieve rulesets while still providing new function.

About the MIME wrapping, I think it makes sense.  Some end-users will want
simple forwarding, which they can already do, while some end-users will
prefer to MIME-wrap and send a new message.  Perhaps, the suggested "resend"
command can be modified with an argument:

	resend :mime <address>

Without the :mime argument, "resend" does a "forward", with the addition of
"Resent-" header insertion.  With the ":mime" argument, a new message is
created, containing the original within a MIME encapsulation.

While we're quoting the -04 spec, let's also look at the abstract:

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

Given this, I would suggest that if the Sieve engine is to be useful for
both "client" and "server" usages, then it should perform functions that are
needed in both contexts.  MIME encapsulation has become an important feature
for both servers and clients.

Also, I would suggest that the text "no variables" be changed to read "no
external variables".  Clearly, `headers["To"]' is a kind of variable.

--
Alan K. Stebbens <[e-mail]>







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12916 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:48:46 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12912 for <[e-mail]>; Thu, 12 Nov 1998 10:48:43 -0800 (PST)
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMail V3.0) with SMTP id 044e0247a4cf.9b07add6.wrm; Thu, 12 Nov 1998 13:53:09 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 12 Nov 1998 13:52:36 -0500
To: Chris Newman <[e-mail]>, Tim Showalter <[e-mail]>
From: Jack De Winter <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:53 PM 11/11/98 -0800, Chris Newman wrote:
>> > > 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
>> > >     must be discussed in case it matters in the future.
>> > 
>> > I've implemented them, but I suspect there may be implementation 
>> > environments where this is hard to support, and so I don't think we can 
>> > require it.

Just bringing these up as it may affect things:

Not to make things more confusing here, but in 2.11 where it is
mentioned that left-to-right evaluation is to be used (implied that
there may be extensions that allow for multiple arguments), it does
not make any indication of anything akin to the ( and ) for expressions
in C.  

Also, Randall Gellens mentioned in one of his posts that he used ^r and ^f as
placeholders in his implementation.  Not slapping Randall's hands on
this subject, but shouldn't we have some SIEVE supplied method of doing
that instead of local implementation stuff?  Otherwise Randall's scripts
are not really going to be that portable after all.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/homepages/jack/


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12829 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:45:08 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12821 for <[e-mail]>; Thu, 12 Nov 1998 10:45:07 -0800 (PST)
Received: from jeep (sbs-dhcp124 [10.2.7.124]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA26996 for <[e-mail]>; Thu, 12 Nov 1998 10:16:42 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: <[e-mail]>
Subject: RE: Proposed Sieve extensions (examples corrected)
Date: Thu, 12 Nov 1998 10:21:55 -0800
Message-ID: <000e01be0e69$5449cbf0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
In-Reply-To: <000701be0e25$35671740$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

The example under the "Action append" definition was incorrect; here is the
correct
example.

 	if allof( header ["To"] :contains "ietf-mta-filters",
 	          not header ["X-Filed"] :contains "ietf")
      {
 		append :new :header "X-Filed" "ietf"
 		fileinto "Lists/IETF"
 		keep
 	}

The example under the "Action replace" definition was also incorrect; it
should read:

 	if allof( header ["To"] :contains "ietf-mta-filters",
                not header ["X-Filed"] :contains "ietf")
      {
		if not header ["Subject"] :contains "[IETF]" {
			replace :header "Subject" "[IETF] $SUBJECT"
		}
		append :header "X-Filed" "ietf"
 		resend "Local-IETF-List"
 	}

	The above example modifies the original Subject header by inserting a list
	identifier into the subject.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12830 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:45:08 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12824 for <[e-mail]>; Thu, 12 Nov 1998 10:45:07 -0800 (PST)
Received: from jeep (sbs-dhcp124 [10.2.7.124]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA26912 for <[e-mail]>; Thu, 12 Nov 1998 10:01:43 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: <[e-mail]>
Subject: RE: Proposed Sieve extensions (replace corrected)
Date: Thu, 12 Nov 1998 10:06:56 -0800
Message-ID: <000d01be0e67$3c1cbfd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
In-Reply-To: <000701be0e25$35671740$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Sorry..

Here's the correct definition of "replace":

Action replace

    Syntax:	replace :header <header> <text>
		replace :body <text>
 		replace :body :file <file>

     The "replace" action replaces a line, or lines, of text in either a
     header field, or the body.  In either case, the "<text>" is one or
     more lines of text used to replace an existing header field or message
     body.  In the case of ":header", if the header field does not exist,
     then it is appended at the end of the header.

     The "replace :header" action replaces an existing header named <header>
     with <text> or the contents of <file>.  If the header doesn't already
     exist, then the action is identical to "append".

     The "replace :body" action replaces the current mail body with the
given
     text or file contents .

     If ":file <file>" is given, then the replacement text is obtained by
     reading the "<file>".

     For alternatives, please see the "insert" or "append" actions.

     Example:

 	if header ["To"] :contains "ietf-mta-filters" and
          not header ["X-Filed"] :contains "ietf"
      {
 		replace :header "X-Filed" "ietf"
 		resend "Local-IETF-List"
 	}



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12441 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:35:09 -0800 (PST)
Received: from nowhere.software.com (sbsg-194.software.com [207.175.94.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12437 for <[e-mail]>; Thu, 12 Nov 1998 10:35:08 -0800 (PST)
Received: from jeep (sbs-dhcp124 [10.2.7.124]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA26953 for <[e-mail]>; Thu, 12 Nov 1998 10:32:44 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Ietf-Mta-Filters@Imc. Org" <[e-mail]>
Subject: Alternative definitions for 5.1 (allof) and 5.2 (anyof)
Date: Thu, 12 Nov 1998 10:37:57 -0800
Message-ID: <001101be0e6b$91510c50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

I would like to propose alternative definitions for the "allof" (Sec 5.1)
and "anyof" (5.2) tests.  The essential difference is to allow the words
"and" and "or" as binary, infix operators for equivalent semantics.

5.1. Test allof / and

   Syntax:   allof ( <test> , <test> , ... <test> )
	 or:   <test1> and <test2>

   The allof test preforms a logical AND on the tests supplied to it.  The
tests
   evaluated from left to right, and evaluations of the tests stops on the
first
   test with a "false" result. The allof test takes as its argument a
test-list.

   The "and" operator returns the logical AND of both tests.  <Test1> is
   evaluated first, and only if its result is true then <test2> is
evaluated.
   Multiple occurances of "and" within the same test expression is evaluated
   from left to right.  I.e.:

	<test1> and <test2> and <test3>

   is equivalent to

	(<test1> and <test2>) and <test3>

   Examples:  allof (false, false)  =>   false
              allof (false, true)   =>   false
              allof (true, true)    =>   true

		  exists header ["To"] and exists header ["Cc"]



Similarly, the "anyof" definition should be:

5.2. Test anyof / or

   Syntax:   anyof ( <test> , <test> , ... <test> )
       or:   <test1> or <test2>

   The anyof test preforms a logical OR on the tests supplied to it.  Tests
   are evaluated from left to right, stopping at the first test that results
   in a "true" result.

   The "or" operator returns the logical OR of both tests.  <Test1> is
evaluated
   first, and only if its value is "false", then <test2> is evaluated.
Multiple
   occurances of "or" within the same test expression are evaluated from
left to
   right. I.e.:

	<test1> or <test2> or <test3>

   is equivalent to:

	(<test1> or <test2>) or <test3>

   Examples:  anyof (false, false)  =>   false
              anyof (false, true)   =>   true
              anyof (true, true)    =>   true

		  exists header ["To"] or exists header ["Cc"]
--
Alan K. Stebbens <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12286 for ietf-mta-filters-bks; Thu, 12 Nov 1998 10:25:04 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12282 for <[e-mail]>; Thu, 12 Nov 1998 10:25:03 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id NAA10034 for <[e-mail]>; Thu, 12 Nov 1998 13:28:28 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id NAA09980 for <[e-mail]>; Thu, 12 Nov 1998 13:28:27 -0500
Received: from uranus by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id NAA018.22; Thu, 12 Nov 1998 13:28:18 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: mostly open issues
Date: Thu, 12 Nov 1998 13:28:25 -0500
Message-ID: <000601be0e6a$3c8f9e80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <00b101be0e4a$529d4580$[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tomas Fasth:
> There is another twist on this. I venture to say that a Sieve implementation
> MAY choose to forward a message using MIME encapsulation. In such a case
> resent headers MUST NOT be inserted. This should be enough for seriously
> considering Alan's suggestion.

I venture to say that it must not.  Have you missed the following 
paragraph from the -04 Sieve spec?:

   The forward command performs an MTA-style forward--that is, what  you
   get  from  a .forward file using sendmail under UNIX.  The address on
   the SMTP envelope is replaced with the one on the forward command and
   the  message  is  sent  back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and  message  ID,
   wrapping the old message in a new one.)

Barry Leiba, Multimedia Messaging  ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA09030 for ietf-mta-filters-bks; Thu, 12 Nov 1998 06:38:42 -0800 (PST)
Received: from waxbill.twinspot.net ([e-mail] [193.45.213.245] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA09024 for <[e-mail]>; Thu, 12 Nov 1998 06:38:38 -0800 (PST)
Received: from bishop (bishop.twinspot.net [193.45.213.246]) by waxbill.twinspot.net (8.8.7/8.8.7) with SMTP id RAA11201; Thu, 12 Nov 1998 17:40:44 +0100
Message-ID: <00b101be0e4a$529d4580$[e-mail]>
From: "Tomas Fasth" <[e-mail]>
To: <[e-mail]>, "Randall Gellens" <[e-mail]>, "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: Re: mostly open issues
Date: Thu, 12 Nov 1998 15:39:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Alan K. Stebbens <[e-mail]>
To: Randall Gellens <[e-mail]>; Tim Showalter
<[e-mail]>; [e-mail] <[e-mail]>
Date: den 12 november 1998 12:05
Subject: RE: mostly open issues


>What is the issue with a "resend" action?  I do not think these definitions
>will confuse users:
>
> Resend -- insert "Resent-" headers and then forward.
> Forward -- forward the message (without modification).
>
>Given these definitions, users have a clear choice of behaviour.

I tend to agree with you, Alan.
There is another twist on this. I venture to say that a Sieve implementation
MAY choose to forward a message using MIME encapsulation. In such a case
resent headers MUST NOT be inserted. This should be enough for seriously
considering Alan's suggestion.

Tomas




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA05362 for ietf-mta-filters-bks; Thu, 12 Nov 1998 02:11:32 -0800 (PST)
Received: from nowhere.software.com (sbsg-226.software.com [207.175.94.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA05358 for <[e-mail]>; Thu, 12 Nov 1998 02:11:31 -0800 (PST)
Received: from jeep (sbs-dhcp20 [10.2.7.20]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id CAA24280 for <[e-mail]>; Thu, 12 Nov 1998 02:09:12 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: <[e-mail]>
Subject: Proposed Sieve extensions
Date: Thu, 12 Nov 1998 02:14:18 -0800
Message-ID: <000701be0e25$35671740$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

The following is a proposal for several new actions, and an extension to the
"forward" action.  We have customers that have expressed interest in these
features within our Sieve implementation, especially for the per-user Sieve
rules.

The extension to the "forward" action is the addtion of a ":file" argument:

    Syntax: forward <addresses>
		forward :file <file>

    It should be possible to forward to multiple addresses.  To make this
    easy, the :file <file> argument causes the contents of <file> to be
    used as a list of addresses.  Each implementation MUST support a file
    syntax of one RFC822 address per line.  Impementations MAY support
    multiple RFC822 addresses per line, separated with ";".  Implementations
    MUST support RFC822 comment syntax, including on otherwise empty lines
    of text.


Action insert

    Syntax:	insert [:new] :header <header> <text>
		insert :body <text>
		insert :body :file <file>

    The "insert" action inserts a line, or lines, of text as either a new
    header or within the body.  In either case, the "<text>" is one or
    more lines of text inserted at the front of the header or body.

    For "insert :header", if the <header> already exists within the message
    header, it is renamed as "Old-<header>", and a new header is inserted,
    with the value of <text>.

    The ":new" argument, taking no arguments itself, causes the header field
    to be inserted, without regard or affect to existing header fields of
    the same name.

    If ":file <file>" is given, then the text to insert within the body is
    obtained by reading the "<file>".

    Whether the text is obtained from a "<text>" argument, or by reading
    the lines of text from a <file> argument, each implmentation SHOULD
    support these variables within the text:

	$NAME		- the user portion of the current email address
	$HOST		- the hostname portion of the current email address
	$SENDER	- the address of the sender of the mail being filtered
	$DATE		- the original "Date:" field of the message being filtered
	$SUBJECT	- the subject string, without leading "Re:" or "FW:"
			  strings.

    Example:

	if header ["To"] :contains "ietf-mta-filters" {
		insert :header "X-Filed" "ietf"
		fileinto "Lists/IETF"
		keep
	}

    The above example will cause a new "X-Filed:" header to be inserted,
    possibly causing any existing similarly-named headers to be renamed as
    "Old-X-Filed:"

	if header ["To", "Cc"] :contains "humor" {
		insert :body "humor-leader.txt"
		resend :file humor-list
	}

    This example is of a "poor man's" mailing list.


Action append

    Syntax:	append [:new] :header <header> <text>
		append :body <text>
		append :body :file <file>

    The "append" action appends a line, or lines, of text to either a
    (possibly new) header field, or to the body.  In either case, the
    "<text>" is one or more lines of text appended at the end of the
    header or body.

    If the ":new" argument is given, then header fields are inserted
    without regard to, or affecting, an existing header field by the
    same name.

    The "append :header" action appends a header field to the header;
    if the header field already exists, it is renamed as "Old-<header>".

    The "append :body" action appends the given text to the end of
    the body.

    If ":file <file>" is given, then the text to append is obtained by
    reading the "<file>".

    For alternatives, please see the "insert" or "replace" actions.

    Examples:

	if header ["To"] :contains "ietf-mta-filters" and
	   not header ["X-Filed"] :contains "ietf" {
		append :new :header "X-Filed: ietf"
		fileinto "Lists/IETF"
		keep
	}

	# implement a personal mailing list
	if header ["To", "Cc"] :contains "humor" {
		append :body "humor-leader.txt"
		resend :file humor-list
	}


Action replace

    Syntax:	replace :header <header> <text>
		replace :body <text>
		replace :body :file <file>

    The "replace" action inserts a line, or lines, of text in either a
    header field, or the body.  In either case, the "<text>" is one or
    more lines of text used to replace an existing header field or message
    body.  In the case of ":header", if the header field does not exist,
    then it is appended at the end of the header.

    The "replace :header" action replaces an existing header named <header>
    with <text> or the contents of <file>.  If the header doesn't already
    exist, then the action is identical to "append".

    The "replace :body" action appends the given text or file contents to
    the end of the body.

    If ":file <file>" is given, then the replacement text is obtained by
    reading the "<file>".

    For alternatives, please see the "insert" or "replace" actions.

    Example:

	if header ["To"] :contains "ietf-mta-filters" and
         not header ["X-Filed"] :contains "ietf"
      {
		replace :header "X-Filed: ietf"
		resend "Local-IETF-List"
	}

Looking for comments!

--
Alan K. Stebbens <[e-mail]>





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04715 for ietf-mta-filters-bks; Thu, 12 Nov 1998 00:40:19 -0800 (PST)
Received: from nowhere.software.com (sbsg-226.software.com [207.175.94.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA04711 for <[e-mail]>; Thu, 12 Nov 1998 00:40:19 -0800 (PST)
Received: from jeep (sbs-dhcp20 [10.2.7.20]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id AAA24169; Thu, 12 Nov 1998 00:37:41 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Thu, 12 Nov 1998 00:42:48 -0800
Message-ID: <000001be0e18$6d739d50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
In-Reply-To: <v04102e72b26fe8a64a99@129.46.219.133>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

| > In any case, my principal point was that the "forward" action should not
| > always insert "Resent-" headers.  I suggested that another
| action, "resend",
| > be defined to apply this semantic.
|
| I would object to that.  Having two different actions, with almost
| identical semantics, seems to me to be a bad idea.  It will lead to
| user confusion, and users will use the wrong one.

If you do not wish to add a new action, then please do not add unwanted
semantics to the existing action.  The "forward" action should do simply
that: forward email; it should not *also* insert headers.  If I want to
insert headers, I'll arrange to do so myself.

If the "forward" action always insert headers, then it cannot be used to
forward mail without modification.  There _are_ users that do not wish to
have additional headers inserted as a part of a forwarding.  So, there must
be an action that provides the "forwarding-without-modification" or the
Sieve rules become useless for this usage.

What is the issue with a "resend" action?  I do not think these definitions
will confuse users:

	Resend -- insert "Resent-" headers and then forward.
	Forward -- forward the message (without modification).

Given these definitions, users have a clear choice of behaviour.

--
Alan K. Stebbens <[e-mail]>







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01917 for ietf-mta-filters-bks; Wed, 11 Nov 1998 17:24:58 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01913 for <[e-mail]>; Wed, 11 Nov 1998 17:24:57 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA28348; Wed, 11 Nov 1998 17:27:44 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e72b26fe8a64a99@129.46.219.133>
In-Reply-To: <003401be0dd9$7fce3f80$[e-mail]>
References: <v04102e5eb26fc451c025@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 17:27:45 -0800
To: <[e-mail]>, "Tim Showalter" <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: mostly open issues
Sender: [e-mail]
Precedence: bulk

At 5:12 PM -0800 11/11/98, Alan K. Stebbens wrote:

> | > Many ISPs run filters on all incoming mail.  Sometimes, forwarding takes
> | > place because of infrastructure changes, system changes, etc., on a
> | > per-domain basis, especially in a managed messaging environment.  Resent
> | > headers should not be inserted because of these system-wide,
> | system-imposed
> | > filtering rules.
> |
> | I would not expect Sieve to be used in these cases.  Existing methods
> | (for example, .forward) would be used.  Sieve is for conditional,
> | message-based actions, during final delivery, on behalf of users.
>
> An example: When one of several domains of users is moved from one mailer to
> another, during the migration phase the former will forward mail to the
> latter, on a system-wide basis.  Using .forward features, or other per-user
> features is neither convenient nor very efficient.

The fact that you use Sieve instead of a .forward file, or a mail 
server configuration change, doesn't change the situation.  Your use of 
Sieve is fine for you, and I'm happy it works for you, but it isn't the 
target for Sieve.  Sieve is intended for user-directed actions during 
final delivery.

>
> Our product uses Sieve as the system-wide mail filter, specifically for SPAM
> filtering, but it is useful to the system administrators for other purposes
> as well.

There are mail servers which permit sites to install filters or custom 
inspection and actions at two different points: message traversal, and 
message delivery.  Sieve operates at message delivery.  If you want to 
use the same syntax at message traversal, that's fine, but I don't 
think it should drive the syntax, especially when it can unnecessarily 
complicate things.

> In any case, my principal point was that the "forward" action should not
> always insert "Resent-" headers.  I suggested that another action, "resend",
> be defined to apply this semantic.

I would object to that.  Having two different actions, with almost 
identical semantics, seems to me to be a bad idea.  It will lead to 
user confusion, and users will use the wrong one.

If your specific product wants to use Sieve at a stage earlier than 
final delivery, and wants to add product-specific extensions, for 
example, a relay action, that's a different matter.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01909 for ietf-mta-filters-bks; Wed, 11 Nov 1998 17:24:53 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01905 for <[e-mail]>; Wed, 11 Nov 1998 17:24:52 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA28343; Wed, 11 Nov 1998 17:27:43 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e70b26fe77001e7@129.46.219.133>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 17:20:43 -0800
To: Chris Newman <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Cc: [e-mail], Randall Gellens <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At 3:53 PM -0800 11/11/98, Chris Newman wrote:

> My take on the DRUMS decision was
> that Resent-* headers are for User Agent manual resends.  If Sieve is
> running on an IMAP server, then Resent-* headers shouldn't be generated,
> IMHO.

As I recall, we didn't discuss cases such as Sieve, only user-agent 
filtering and automatic, .forward style.  The consensus was to generate 
Resent-* on the former, not the latter.

So, where would Sieve fit in?  I say Sieve, being (a) under the direct 
control of the end-user, and (b) acting conditionally based on 
per-message criteria, is essentially an extension of the UA, and thus 
Resent-* headers should be generated.  By comparison, I consider Sieve 
to be equivalent to existing filtering in many clients, which often 
supports a forward action.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01901 for ietf-mta-filters-bks; Wed, 11 Nov 1998 17:24:51 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01897 for <[e-mail]>; Wed, 11 Nov 1998 17:24:50 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA28340; Wed, 11 Nov 1998 17:27:40 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e6fb26fe6dedf6d@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04102e5fb26fc509eb90@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 17:15:51 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft - Forward
Sender: [e-mail]
Precedence: bulk

At 7:01 PM -0500 11/11/98, Tim Showalter wrote:

> Oh, I see.  But fileinto should not stop processing and all fileintos
> should be honored, so you should get four messages in each of four
> mailboxes.

You are right, all fileinto's will be done, so we'd end up with four 
copies of the message in the *last* mailbox, not the first.  In the 
environment in which I first implemented Sieve, "fileinto" changes the 
destination of a message, it does not cause immediate copying.  So 
after Sieve is done with the message, it gets put into whichever folder 
is specified.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01618 for ietf-mta-filters-bks; Wed, 11 Nov 1998 17:09:50 -0800 (PST)
Received: from nowhere.software.com (sbsg-201.software.com [207.175.94.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01614 for <[e-mail]>; Wed, 11 Nov 1998 17:09:48 -0800 (PST)
Received: from jeep (sba-dhcp44 [10.2.5.44]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id RAA23238; Wed, 11 Nov 1998 17:07:09 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Randall Gellens" <[e-mail]>, "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Wed, 11 Nov 1998 17:12:21 -0800
Message-ID: <003401be0dd9$7fce3f80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <v04102e5eb26fc451c025@129.46.219.133>
Sender: [e-mail]
Precedence: bulk

| > Many ISPs run filters on all incoming mail.  Sometimes, forwarding takes
| > place because of infrastructure changes, system changes, etc., on a
| > per-domain basis, especially in a managed messaging environment.  Resent
| > headers should not be inserted because of these system-wide,
| system-imposed
| > filtering rules.
|
| I would not expect Sieve to be used in these cases.  Existing methods
| (for example, .forward) would be used.  Sieve is for conditional,
| message-based actions, during final delivery, on behalf of users.

An example: When one of several domains of users is moved from one mailer to
another, during the migration phase the former will forward mail to the
latter, on a system-wide basis.  Using .forward features, or other per-user
features is neither convenient nor very efficient.

Our product uses Sieve as the system-wide mail filter, specifically for SPAM
filtering, but it is useful to the system administrators for other purposes
as well.

In any case, my principal point was that the "forward" action should not
always insert "Resent-" headers.  I suggested that another action, "resend",
be defined to apply this semantic.

--
Alan K. Stebbens <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA01295 for ietf-mta-filters-bks; Wed, 11 Nov 1998 16:56:53 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA01291 for <[e-mail]>; Wed, 11 Nov 1998 16:56:52 -0800 (PST)
Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-29 #30494) with ESMTPS id <[e-mail]> for [e-mail]; Wed, 11 Nov 1998 15:53:13 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.60]) by elvira.innosoft.com (PMDF V5.2-29 #13579) with SMTP id <[e-mail]> for [e-mail]; Wed, 11 Nov 1998 15:52:18 -0800 (PST)
Date: Wed, 11 Nov 1998 15:53:24 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: mostly open issues
In-reply-to: <[e-mail]>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Tim Showalter <[e-mail]>
Cc: [e-mail], Randall Gellens <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

On Wed, 11 Nov 1998, Tim Showalter wrote:
> > My understanding of the DRUMS discussion on Resent-* headers is that 
> > they are not to be used for .forward style automatic, unconditional 
> > forwarding, but are supposed to be used for user-initiated forwarding. 
> > I say that Sieve falls into this latter category, and thus Resent-* 
> > headers SHOULD be generated.
> 
> Okay, I'm not sure if I agree with the first half, but I can accept the
> second half in any case.

Actually, I disagree with Randy here.  My take on the DRUMS decision was
that Resent-* headers are for User Agent manual resends.  If Sieve is
running on an IMAP server, then Resent-* headers shouldn't be generated,
IMHO.

> > > 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
> > >     must be discussed in case it matters in the future.
> > 
> > I've implemented them, but I suspect there may be implementation 
> > environments where this is hard to support, and so I don't think we can 
> > require it.
> 
> Really?  Could you provide an example?  I can think of only one, and I
> think it's rather absurd.
> 
> Chris, why shouldn't this be "SHOULD"?  I think SHOULD would be useful
> since I assume short-circuit evaluation will be required by extensions
> that specify tests with side effects, and it's useful from an efficiency
> standpoint.

There is no justification to use SHOULD.  Either programmers can rely on
short-circuit behavior or they can't.  The former is MUST, the latter is
MAY.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00241 for ietf-mta-filters-bks; Wed, 11 Nov 1998 15:58:20 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00236 for <[e-mail]>; Wed, 11 Nov 1998 15:58:19 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id TAA00519; Wed, 11 Nov 1998 19:01:21 -0500 (EST)
Date: 11 Nov 1998 19:01:11 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: class struggle Serbian security Noriega Vince Foster strategic Rule Psix
To: [e-mail], Randall Gellens <[e-mail]>
In-reply-to: <v04102e5fb26fc509eb90@129.46.219.133>
Subject: Re: List of expected changes for sieve 05 draft - Forward
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 11 Nov 1998 14:52:27 -0800
> From: Randall Gellens <[e-mail]>

> > Or am I just completely missing something?
> 
> The message may have all four mailing lists in the address headers, in 
> which case all four copies will be filed into the first folder, and 
> none into the others.  [...]

Oh, I see.  But fileinto should not stop processing and all fileintos
should be honored, so you should get four messages in each of four
mailboxes.

(I forgot that under AMS, when I used to do this sort of thing, only one 
message with a given Message-ID could exist in a mailbox, and forgot
that it was going on.)

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29569 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:57:39 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29565 for <[e-mail]>; Wed, 11 Nov 1998 14:57:38 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA02975; Wed, 11 Nov 1998 14:59:59 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e5fb26fc509eb90@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <000e01be0da0$f698cc90$[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 14:52:27 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft - Forward
Sender: [e-mail]
Precedence: bulk

At 3:37 PM -0500 11/11/98, Tim Showalter wrote:

>> (BTW, I find it *much* more useful to use "envelopesender" than to use
>> the document header fields.  Suppose I'm subscribed to the IMAP, ACAP,
>> IMAPEXT, and MTA-FILTERS mailing lists, and someone posts something to
>> all of them.  With "envelopesender" I can sort the four copies into their
>> respective folders.  Without it, there's no way to do that.)
>
> Not true.
>
> if header ["to", "cc"] :contains ["[e-mail]"] {
> 	fileinto "INBOX.mta-filters";
> }
> if header ["to", "cc"] :contains ["[e-mail]"] {
> 	fileinto "INBOX.imap-list";
> }
> [etc.]
>
> Or am I just completely missing something?

The message may have all four mailing lists in the address headers, in 
which case all four copies will be filed into the first folder, and 
none into the others.  I had this problem with IETF announcements that 
were cc'd to the working group lists -- I ended up with two copies in 
one folder, and none in the other.  I fixed this by looking at Sender 
and envelope sender.

Also, a message may have been bcc'd to the list.  For example, here at 
work people often send mail to a large internal list, and in order to 
avoid inadvertent reply-to-alls, the list is actually bcc'd.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29554 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:57:16 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29547 for <[e-mail]>; Wed, 11 Nov 1998 14:57:15 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA02991; Wed, 11 Nov 1998 15:00:01 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e60b26fc5c31739@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04102e50b26fa5f59d0a@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 14:55:17 -0800
To: Tim Showalter <[e-mail]>, [e-mail], Randall Gellens <[e-mail]>, [e-mail], Ned Freed <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Sender: [e-mail]
Precedence: bulk

At 3:58 PM -0500 11/11/98, Tim Showalter wrote:

>> > 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
>> >     must be discussed in case it matters in the future.
>>
>> I've implemented them, but I suspect there may be implementation
>> environments where this is hard to support, and so I don't think we can
>> require it.
>
> Really?  Could you provide an example?  I can think of only one, and I
> think it's rather absurd.

No, I can't provide an example off-hand, but then I am not familiar 
with every environment in which someone might want to implement Sieve. 
Sure, C, AppleScript, and (I think) Perl can all provide this, but 
given that Sieve is likely to be implemented using whatever tools an 
existing mail server provides, I think we should be careful about the 
restrictions we impose.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29546 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:57:13 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29542 for <[e-mail]>; Wed, 11 Nov 1998 14:57:13 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA03022 for <[e-mail]>; Wed, 11 Nov 1998 15:00:03 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e61b26fc6bb5182@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 14:58:33 -0800
To: [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Same Discussion in Multiple Threads
Sender: [e-mail]
Precedence: bulk

Can we please try and limit the instances where the same discussion 
happens in multiple threads?  I tend to read the messages by thread, 
and so I've responded so some (for example, envelope versus header 
filtering) and then find that someone else (Barry, in this case) made 
exactly my points, but in a different thread.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29541 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:57:12 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29537 for <[e-mail]>; Wed, 11 Nov 1998 14:57:11 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA02966; Wed, 11 Nov 1998 14:59:56 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e5eb26fc451c025@129.46.219.133>
In-Reply-To: <002a01be0dc0$c0ea6020$[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 14:47:32 -0800
To: <[e-mail]>, "Tim Showalter" <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: mostly open issues
Sender: [e-mail]
Precedence: bulk

At 2:15 PM -0800 11/11/98, Alan K. Stebbens wrote:

> Many ISPs run filters on all incoming mail.  Sometimes, forwarding takes
> place because of infrastructure changes, system changes, etc., on a
> per-domain basis, especially in a managed messaging environment.  Resent
> headers should not be inserted because of these system-wide, system-imposed
> filtering rules.

I would not expect Sieve to be used in these cases.  Existing methods 
(for example, .forward) would be used.  Sieve is for conditional, 
message-based actions, during final delivery, on behalf of users.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29402 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:39:53 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29398 for <[e-mail]>; Wed, 11 Nov 1998 14:39:51 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 12 Nov 1998 01:43:29 +0300
Message-ID: <[e-mail]>
Date: Thu, 12 Nov 1998 01:42:32 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: IMAPFLAGS SIEVE extension
References: <001701be0dbf$c15b8df0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Barry Leiba wrote:

> > I've recently wrote SIEVE extension that allows to set IMAP flags on
> > delivery. I will appreciate any feedback from the mailing list.
>
> I'm not fond of it, mainly because it's so IMAP-specific, and the idea
> of allowing a filter to flag a message is too good to relegate to servers
> that implement their SMTP delivery agent integrated with their IMAP server
> (we do, so we could do this, but...).

First of all, thank you for spending your time.

> I see little use for setting some of the flags, such as \Deleted and
> \Draft, and other flags might be removed from the IMAP context with a
> little thought.  I'd rather see the idea put in a form that can go into
> the base document.
>
> We could add a "flag" action, the semantics of which are just "flag this
> message in a way that makes sense to the underlying implementation."  That
> would correspond to the IMAP \Flagged flag.

May be you are right.

> I could see some value in providing a way to mark a message as "seen" from
> a script.  The "flag as interesting" and "mark as seen" ideas could be
> pulled away from the IMAP context, and put in as actions that must be
> implemented, but may do nothing if the SMTP delivery agent can't do
> anything with them.  I'm not sure how much I like that either.  I guess
> I'm waffling here.
>
> I don't think there's a way, without being IMAP-specific, to add something
> that will let the user set user-defined IMAP flags (ones that don't begin
> with "\").

You are right. But this is the main use of proposed draft (as it was
intended). I wanted to wrote that this draft was not intended to be used by
SIEVE interpreter that was running on client.

Some flags must be set only in the time of final delivery (for example
$MDNRequired flag for telling IMAP client that it should send Message
Disposition Notification).

Anyway I think that sometimes you should be specific. For this purpose I
wrote, that SIEVE interpreter, that knows nothing about IMAP may ignore
"setflags" action.

> The draft is wrong to say that "forward" doesn't allow the message to be
> kept, so it's wrong to prohibit setting flags on a forwarded message.

Ok, I will correct this.

> Barry Leiba, Multimedia Messaging   ([e-mail])
> http://www.research.ibm.com/people/l/leiba

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29190 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:12:26 -0800 (PST)
Received: from nowhere.software.com (sbsg-201.software.com [207.175.94.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29186 for <[e-mail]>; Wed, 11 Nov 1998 14:12:25 -0800 (PST)
Received: from jeep (sba-dhcp44 [10.2.5.44]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id OAA22236; Wed, 11 Nov 1998 14:10:01 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Wed, 11 Nov 1998 14:15:13 -0800
Message-ID: <002a01be0dc0$c0ea6020$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

| > | 3.  Request: forward adds Resent-* headers.
| >
| > This should be context dependent.  If the Sieve filter is run
| by the system
| > administrator, and forwarding is caused for site administrative reasons,
| > then the Resent headers probably should not be inserted.
| >
| > On the other hand, if the Sieve filter is run by a user, causing a
| > forwarding, then the Resent headers should be added.
|
| I don't understand the difference.  Typically Sieve scripts are run by
| the system at time of mail delivery, which falls into neither of the
| above cases.

Many ISPs run filters on all incoming mail.  Sometimes, forwarding takes
place because of infrastructure changes, system changes, etc., on a
per-domain basis, especially in a managed messaging environment.  Resent
headers should not be inserted because of these system-wide, system-imposed
filtering rules.

On the other hand, when a user forwards a piece of mail, unconditionally or
not, Resent often should be added.

As I said, it depends on the context.

I think defining a "Resend" action with the additional semantics of
inserting headers is better than imposing the headers on "forward".

| I believe the right thing to do is to always add Resent headers, despite
| the possible efficiency gains of not doing so.  I believe the benefit of
| trace informaton outweighs the benefits of efficiency gains, especially
| given that forward is going to cause mail loop headaches.

I view Resent- headers as informational only.  Tracing should rely on
Received headers, not Resent headers.

--
Alan K. Stebbens <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29117 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:04:57 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29113 for <[e-mail]>; Wed, 11 Nov 1998 14:04:56 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id RAA06506 for <[e-mail]>; Wed, 11 Nov 1998 17:08:17 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id RAA14588 for <[e-mail]>; Wed, 11 Nov 1998 17:08:17 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id RAA017.57; Wed, 11 Nov 1998 17:08:09 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: IMAPFLAGS SIEVE extension
Date: Wed, 11 Nov 1998 17:08:04 -0500
Message-ID: <001701be0dbf$c15b8df0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

> I've recently wrote SIEVE extension that allows to set IMAP flags on
> delivery. I will appreciate any feedback from the mailing list.

I'm not fond of it, mainly because it's so IMAP-specific, and the idea 
of allowing a filter to flag a message is too good to relegate to servers 
that implement their SMTP delivery agent integrated with their IMAP server 
(we do, so we could do this, but...).

I see little use for setting some of the flags, such as \Deleted and
\Draft, and other flags might be removed from the IMAP context with a 
little thought.  I'd rather see the idea put in a form that can go into 
the base document.

We could add a "flag" action, the semantics of which are just "flag this 
message in a way that makes sense to the underlying implementation."  That 
would correspond to the IMAP \Flagged flag.

I could see some value in providing a way to mark a message as "seen" from
a script.  The "flag as interesting" and "mark as seen" ideas could be
pulled away from the IMAP context, and put in as actions that must be
implemented, but may do nothing if the SMTP delivery agent can't do
anything with them.  I'm not sure how much I like that either.  I guess
I'm waffling here.

I don't think there's a way, without being IMAP-specific, to add something
that will let the user set user-defined IMAP flags (ones that don't begin
with "\").

The draft is wrong to say that "forward" doesn't allow the message to be
kept, so it's wrong to prohibit setting flags on a forwarded message.

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29087 for ietf-mta-filters-bks; Wed, 11 Nov 1998 14:01:08 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29082 for <[e-mail]>; Wed, 11 Nov 1998 14:01:06 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA22531; Wed, 11 Nov 1998 17:04:17 -0500 (EST)
Date: 11 Nov 1998 17:04:08 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Panama Kibo North Korea Delta Force Saddam Hussein colonel terrorist
To: [e-mail], Tim Showalter <[e-mail]>
In-reply-to: <002201be0dbc$17b56850$[e-mail]>
Subject: Re: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Reply-To: <[e-mail]>
> From: "Alan K. Stebbens" <[e-mail]>
> Date: Wed, 11 Nov 1998 13:41:51 -0800
> 
> | 3.  Request: forward adds Resent-* headers.
> 
> This should be context dependent.  If the Sieve filter is run by the system
> administrator, and forwarding is caused for site administrative reasons,
> then the Resent headers probably should not be inserted.
> 
> On the other hand, if the Sieve filter is run by a user, causing a
> forwarding, then the Resent headers should be added.

I don't understand the difference.  Typically Sieve scripts are run by
the system at time of mail delivery, which falls into neither of the
above cases.

I believe the right thing to do is to always add Resent headers, despite 
the possible efficiency gains of not doing so.  I believe the benefit of 
trace informaton outweighs the benefits of efficiency gains, especially
given that forward is going to cause mail loop headaches.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29058 for ietf-mta-filters-bks; Wed, 11 Nov 1998 13:58:06 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29054 for <[e-mail]>; Wed, 11 Nov 1998 13:58:03 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 12 Nov 1998 01:01:58 +0300
Message-ID: <[e-mail]>
Date: Thu, 12 Nov 1998 01:01:06 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: List of expected changes for sieve 05 draft - Forward
References: <001601be0dbd$47fbd8e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Barry Leiba wrote:

> Alexey...
>
> > (I keep both headers and body of the message in the same file, so I am not
> > delighted with the idea of copying [potentially large] message on delivery just
> > to add Resent-* flags).
>
> You have to add a "received" line anyway, if you do it right.  You can just
> write the "resent-*" lines after the "received" line, and then pipe the rest
> of the message through.

I add received lines *before* receiving message content. Then I perform some delivery
actions on fully received message.

Don't understand me wrong : I am not arguing that my implementation is the best
(because it isn't :-)). I just concerned about the speed of delivery in my
implementation.

> > So I think that adding Resent-* fields should be SHOULD, not MUST.
>
> In any case, I agree with this.
>
> Barry Leiba, Multimedia Messaging   ([e-mail])
> http://www.research.ibm.com/people/l/leiba

I don't mind to have different "forward" and "resent", as proposed by  Alan Stebbens.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28963 for ietf-mta-filters-bks; Wed, 11 Nov 1998 13:47:15 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28959 for <[e-mail]>; Wed, 11 Nov 1998 13:47:14 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id QAA09720 for <[e-mail]>; Wed, 11 Nov 1998 16:50:34 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id QAA17740 for <[e-mail]>; Wed, 11 Nov 1998 16:50:34 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id QAA017.55; Wed, 11 Nov 1998 16:50:26 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft - Forward
Date: Wed, 11 Nov 1998 16:50:22 -0500
Message-ID: <001601be0dbd$47fbd8e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Alexey...

> (I keep both headers and body of the message in the same file, so I am not
> delighted with the idea of copying [potentially large] message on delivery just
> to add Resent-* flags).

You have to add a "received" line anyway, if you do it right.  You can just
write the "resent-*" lines after the "received" line, and then pipe the rest
of the message through.

> So I think that adding Resent-* fields should be SHOULD, not MUST.

In any case, I agree with this.

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28950 for ietf-mta-filters-bks; Wed, 11 Nov 1998 13:44:49 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28946 for <[e-mail]>; Wed, 11 Nov 1998 13:44:47 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id QAA05350 for <[e-mail]>; Wed, 11 Nov 1998 16:48:08 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id QAA17776 for <[e-mail]>; Wed, 11 Nov 1998 16:48:08 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id QAA017.53; Wed, 11 Nov 1998 16:48:00 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft - Forward
Date: Wed, 11 Nov 1998 16:47:55 -0500
Message-ID: <001501be0dbc$f0d97b30$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Tim...
> > (BTW, I find it *much* more useful to use "envelopesender" than to use
> > the document header fields.  Suppose I'm subscribed to the IMAP, ACAP,
> > IMAPEXT, and MTA-FILTERS mailing lists, and someone posts something to
> > all of them.  With "envelopesender" I can sort the four copies into their
> > respective folders.  Without it, there's no way to do that.)
> 
> Not true.
> 
> if header ["to", "cc"] :contains ["[e-mail]"] {
> 	fileinto "INBOX.mta-filters";
> }
> if header ["to", "cc"] :contains ["[e-mail]"] {
> 	fileinto "INBOX.imap-list"; 
> }
> [etc.]
> 
> Or am I just completely missing something?

Trouble with that is that all four copies of the message match all four
tests.  So I wind up with each folder getting four copies of the message.
And that's assuming my implementation supports multiple fileinto.

But if I use 'envelope ["from"]', then each of the four copies of the
message only matches one, and I get exactly what I want.

Barry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28908 for ietf-mta-filters-bks; Wed, 11 Nov 1998 13:39:05 -0800 (PST)
Received: from nowhere.software.com (sbsg-201.software.com [207.175.94.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28904 for <[e-mail]>; Wed, 11 Nov 1998 13:39:04 -0800 (PST)
Received: from jeep (sba-dhcp44 [10.2.5.44]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id NAA21923; Wed, 11 Nov 1998 13:36:39 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: RE: mostly open issues
Date: Wed, 11 Nov 1998 13:41:51 -0800
Message-ID: <002201be0dbc$17b56850$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

| 3.  Request: forward adds Resent-* headers.

This should be context dependent.  If the Sieve filter is run by the system
administrator, and forwarding is caused for site administrative reasons,
then the Resent headers probably should not be inserted.

On the other hand, if the Sieve filter is run by a user, causing a
forwarding, then the Resent headers should be added.

Perhaps a new action "resend", as a synonym to "forward", can be defined, to
cause the additional effect of inserting headers?

	resend  newaddress	# gets "Resent-*" headers added
	forward newaddress	# no "Resent-*" headers

--
Alan K. Stebbens <[e-mail]>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA28652 for ietf-mta-filters-bks; Wed, 11 Nov 1998 13:07:16 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA28648 for <[e-mail]>; Wed, 11 Nov 1998 13:07:12 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 12 Nov 1998 00:11:05 +0300
Message-ID: <[e-mail]>
Date: Thu, 12 Nov 1998 00:10:14 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: List of expected changes for sieve 05 draft - Forward
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> So should forward add Resent-* information?  Pete Resnick told me a long
> time ago it should, but I forgot to write it down.

I think every developer should decide for himself.
(I keep both headers and body of the message in the same file, so I am not
delighted with the idea of copying [potentially large] message on delivery just
to add Resent-* flags).
So I think that adding Resent-* fields should be SHOULD, not MUST.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28579 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:55:59 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28575 for <[e-mail]>; Wed, 11 Nov 1998 12:55:58 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA15655; Wed, 11 Nov 1998 15:58:36 -0500 (EST)
Date: 11 Nov 1998 15:58:27 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: North Korea Semtex ammunition Noriega Qaddafi fissionable nuclear
To: [e-mail], Randall Gellens <[e-mail]>, [e-mail]
In-reply-to: <v04102e50b26fa5f59d0a@129.46.219.133>
Subject: Re: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 11 Nov 1998 12:40:15 -0800
> From: Randall Gellens <[e-mail]>

> My understanding of the DRUMS discussion on Resent-* headers is that 
> they are not to be used for .forward style automatic, unconditional 
> forwarding, but are supposed to be used for user-initiated forwarding. 
> I say that Sieve falls into this latter category, and thus Resent-* 
> headers SHOULD be generated.

Okay, I'm not sure if I agree with the first half, but I can accept the
second half in any case.

> > 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
> >     must be discussed in case it matters in the future.
> 
> I've implemented them, but I suspect there may be implementation 
> environments where this is hard to support, and so I don't think we can 
> require it.

Really?  Could you provide an example?  I can think of only one, and I
think it's rather absurd.

Chris, why shouldn't this be "SHOULD"?  I think SHOULD would be useful
since I assume short-circuit evaluation will be required by extensions
that specify tests with side effects, and it's useful from an efficiency
standpoint.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28551 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:52:33 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28547 for <[e-mail]>; Wed, 11 Nov 1998 12:52:28 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 11 Nov 1998 23:56:19 +0300
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 23:55:28 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: [e-mail]
Subject: IMAPFLAGS SIEVE extension
Content-Type: multipart/mixed; boundary="------------E857AFD6A748452519C860C6"
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.
--------------E857AFD6A748452519C860C6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I've recently wrote SIEVE extension that allows to set IMAP flags on
delivery. I will appreciate any feedback from the mailing list.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------


--------------E857AFD6A748452519C860C6
Content-Type: text/plain; charset=us-ascii;
 name="draft-melnikov-sieve-imapflags-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-melnikov-sieve-imapflags-00.txt"






Network Working Group                                       
Internet Draft: Sieve -- IMAP flag Extension                 A. Melnikov
Document: draft-melnikov-sieve-imapflags-00.txt     Epsylon Technologies
Expires: 22 April 1999                                   22 October 1998


                      Sieve -- IMAP flag Extension


Status of this memo

   This document is an  Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt''  listing  contained  in  the  Internet-Drafts
   Shadow   Directories   on   ftp.is.co.za   (Africa),  ftp.nordu.net
   (Europe),  munnari.oz.au (Pacific Rim),  ds.internic.net  (US  East
   Coast), or ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or  using  this
   protocol  are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright

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

Abstract

   Recent discussions   have  shown  that  it  was  desirable  to  set
   different [IMAP] flags on message delivery.  (This can be done, for
   example, by SIEVE interpreter that works as a part of Mail Delivery
   Agent (MDA)).

   This document describes an extension to the  Sieve  mail  filtering
   language for setting [IMAP] flags.






Melnikov                   Expires April 1999                   [Page 1]

Internet Draft             Sieve -- IMAP flag Extension     October 1998


0. Meta-information on this draft

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

0.1. Discussion

   This draft is intended to be compared with the Sieve mail filtering
   language,  an  Internet-Draft  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. Introduction

   This is an extension to the Sieve language defined by  [SIEVE]  for
   setting [IMAP] flags. It defines new action "setflag".

   This document  doesn't dictate how SIEVE interpreter can set [IMAP]
   flags. In particular, SIEVE interpreter may work as an IMAP client,
   or may have direct access to the mailstore.

   SIEVE interpreters,  that  doesn't  support  integration  with IMAP
   SHOULD ignore this extension.

   Conventions for notations are as in [SIEVE] section 1.1,  including
   use of [KEYWORDS].

2. Capability Identifier

   Sieve implementations   that   implement  setflag  action  have  an
   identifier of "IMAPFLAGS" for use with the capability mechanism.

3. Setflag Action

   Syntax:   setflag <list-of-flags>

   Setflag is used  for  setting  [IMAP]  flags.  It  should  be  used
   together  with  keep  or fileinto.  It MUST be ignored if mailstore
   doesn't support the storing of any flags.

   Flags can be set only for message that is  currently  processed  by
   SIEVE.  When  called  with keep,  setflag sets flags in user's main
   mailbox.  When called with fileinto,  setflag  sets  flags  in  the
   mailbox, indicated by the parameter.




Melnikov                   Expires April 1999                   [Page 2]

Internet Draft             Sieve -- IMAP flag Extension     October 1998


   The order  of  setflag/fileinto or setflag/keep is not important in
   the script.  Multiple occurrences of setflag are treated  additive.
   This mean, that the following two actions

      setflag "\Deleted";
      setflag "\Answered";

   produce the same result as single action

      setflag ["\Deleted", "\Answered"];

   Server MUST ignore all flags that it can't store permanently.  This
   mean,  in  particular,  that if user's main mailbox can't store any
   flags, then the following SIEVE script produces no actions

      Example:  if size over 500K setflag "\Deleted";

   More substantial example is:

      Example:
             if header "from" contains "[e-mail]" {
               setflag "\Flagged";
               fileinto "INBOX.From Boss";
             }

4. Interaction with Other Sieve Actions

   Sieve actions sometimes  prohibit  each  other  in  order  to  make
   filtering scripts less likely to cause serious problems.

   It is  strongly  discouraged  to  use  setflag action together with
   forward,  reject and discard,  because these  actions  don't  allow
   keeping received message.

   SIEVE interpreter MUST ignore setflag command, when it is used with
   forward, reject and discard (or  similar).  SIEVE  verifier  SHOULD
   reject script, which contains setflag together with forward, reject
   and discard (or similar).

5. Other Considerations

   This extension intentionally doesn't allow setting [IMAP] flags  on
   arbitrary message in IMAP store.

6. Security Considerations

   Security considerations are discussed in the [IMAP] and [SIEVE].
   It is belived that this  extension  doesn't  introduce any
   additional security concerns.


Melnikov                   Expires April 1999                   [Page 3]

Internet Draft             Sieve -- IMAP flag Extension     October 1998


6. Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].

   action =/ setflag         ;; "setflag" is now a legal action

   setflag = "setflag" WSP string-list
     ;; a list of [IMAP] flags

7. Author's Address

    Alexey Melnikov
    Epsylon Technologies
    121293, Russia, Moscow, 
    general Ermolov street, 6 - 90

    Email: [e-mail]

































Melnikov                   Expires April 1999                   [Page 4]

Internet Draft             Sieve -- IMAP flag Extension     October 1998


Appendices

Appendix A.  References

   [ABNF] Crocker, D.,  "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.

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language", Carenegie
   Mellon, Work in Progress.

   [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
   University of Washington, RFC 2060, December 1996.


Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1997. 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.














Melnikov                   Expires April 1999                   [Page 5]


--------------E857AFD6A748452519C860C6--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28500 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:44:30 -0800 (PST)
Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28496 for <[e-mail]>; Wed, 11 Nov 1998 12:44:29 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA20396; Wed, 11 Nov 1998 12:46:40 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e50b26fa5f59d0a@129.46.219.133>
In-Reply-To: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 12:40:15 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: mostly open issues
Sender: [e-mail]
Precedence: bulk

At 3:25 PM -0500 11/11/98, Tim Showalter wrote:

> 2.  Request: Reject should be optional.
>
>     (I just want to know that this is consensus.)

I think Reject has to be optional, because some implementation 
environments can't support it (specifically, some environments either 
can't control the DSN generation, or can't alter the text used in it).

> 3.  Request: forward adds Resent-* headers.
>
>     (I just want to know that this is consensus.)

My understanding of the DRUMS discussion on Resent-* headers is that 
they are not to be used for .forward style automatic, unconditional 
forwarding, but are supposed to be used for user-initiated forwarding. 
I say that Sieve falls into this latter category, and thus Resent-* 
headers SHOULD be generated.

> 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
>     must be discussed in case it matters in the future.

I've implemented them, but I suspect there may be implementation 
environments where this is hard to support, and so I don't think we can 
require it.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28495 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:44:25 -0800 (PST)
Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28491 for <[e-mail]>; Wed, 11 Nov 1998 12:44:24 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA20386; Wed, 11 Nov 1998 12:46:36 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e4fb26fa5b58dea@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04102e3db26f97a33f1c@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 12:36:53 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Sender: [e-mail]
Precedence: bulk

At 2:55 PM -0500 11/11/98, Tim Showalter wrote:

> Either we need to change the grammar to allow the extension, or the
> extension to fit the grammar, and I'd like to know which.

Let's use the syntax Barry suggested.  Both Ned and I like it, even 
though each of us has implementations which use different syntax.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28473 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:42:08 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28469 for <[e-mail]>; Wed, 11 Nov 1998 12:42:04 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 11 Nov 1998 23:45:56 +0300
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 23:45:04 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ned Freed wrote:

> > Tim:
> > > > I want to be able to test "envelope-sender" too, and we have that in
> > > > our implementation...
> > >
> > > What does the command look like?  If you've got a working syntax, we
> > > might as well use it.
>
> > } elseif  envelopesender :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {
>
> > I actually like Randy's "envelope.rcpt" and "envelope.from".  If you want
> > to avoid the ".", we could make it like "header":
>
> > } elseif envelope ["from"] :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {
>
> > ...which also allows '["from", "rcpt"]' for more flexibility.
>
> What a great idea! I really like this approach, even though it isn't what
> I implemented.

I like this approach too, because future extensions may add different components to
envelope without changing grammar.

BTW, I think that operations with envelope are quite frequent, so they should be
standardized.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28430 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:34:38 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28426 for <[e-mail]>; Wed, 11 Nov 1998 12:34:36 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA13258; Wed, 11 Nov 1998 15:37:28 -0500 (EST)
Date: 11 Nov 1998 15:37:19 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: nuclear Marxist assassination class struggle spy Croatian explosion
To: [e-mail]
In-reply-to: <000e01be0da0$f698cc90$[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft - Forward
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

So should forward add Resent-* information?  Pete Resnick told me a long 
time ago it should, but I forgot to write it down.

I'm under the impression that it should.

> From: "Barry Leiba" <[e-mail]>
> Date: Wed, 11 Nov 1998 13:27:39 -0500

> > Furthermore, I also would like to see a copy-forward action: instead of 
> > forwarding, deliver the message and send a copy to the specified address. 
> 
> There's nothing wrong with using "forward" and "fileinto" (or "keep") 
> together to accomplish this.

I agree with Barry.

> (BTW, I find it *much* more useful to use "envelopesender" than to use
> the document header fields.  Suppose I'm subscribed to the IMAP, ACAP,
> IMAPEXT, and MTA-FILTERS mailing lists, and someone posts something to
> all of them.  With "envelopesender" I can sort the four copies into their
> respective folders.  Without it, there's no way to do that.)

Not true.

if header ["to", "cc"] :contains ["[e-mail]"] {
	fileinto "INBOX.mta-filters";
}
if header ["to", "cc"] :contains ["[e-mail]"] {
	fileinto "INBOX.imap-list"; 
}
[etc.]

Or am I just completely missing something?

This doesn't work if a mailing list has multiple names.

Simply matching against return-path doesn't work for mailing lists that
do VERPs.  See Dan Bernstein's weekly rant on the subject for more
information, although qmail/ezmlm isn't the only one that does it,
either.  Mostly it works if you do a glob of some kind, I think.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28406 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:31:24 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28402 for <[e-mail]>; Wed, 11 Nov 1998 12:31:21 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 11 Nov 1998 23:35:12 +0300
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 23:34:07 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: List of expected changes for sieve 05 draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> 2.  Question: Should short-circuit evaluation be as is, a MAY, or not
>     discussed at all?

I think that short-circuit evaluation should be MUST (may be some future extensions
will depend on it) or not discussed at all.

> > Date: Mon, 09 Nov 1998 15:52:27 -0800 (PST)
> > From: Chris Newman <[e-mail]>
>
> > > 4.  Question: Should i;ascii-casemap be the default?
> >
> > I'm not sure.  How does this interact with the local-part being
> > case-sensitive and the domain-part being case-insensitive?  Could it lead
> > to confusion?
>
> Hm.  Perhaps we should just canonicalize all domain names to
> (lower/upper)case for compares, then provide primitives (i.e., not
> "header") for looking at to/from/cc like IMAP does for looking at parsed
> address headers.  (That's simpler than anything else I can think of.)
> Then we can make casemap the default.
>
> Making i;ascii the default is more or less a lose for similar arguments,
> so I'd rather not do that.

Adding primitives for dealing with addresses seems good.

Then i;ascii-casemap should be the default.

> 6.  Request: A non-present comparator is considered to be basically a syntax
>     error.

Sounds reasonable.

> 13. Request: Reject should be optional.
>

Will it stay in the main document?

> 2.  Tagged arguments: Some time ago, tagged arguments were proposed and
>     accepted.  I strongly prefer them because they allow keywords to be taken
>     out of the grammar, reducing the number of special cases, and allowing
>     extensions to be added without changes to the grammar.
>
> 2a. Can we keep tagged arguments?

No doubt.

> 2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
>     interspersed in commands.  This was probably a mistake, but I wanted to
>     preserve wordings like this:
>
>        header "From" :contains "tjs"
>
>     What do people want?  The dominant stated opinion is that they should only
>     happen after the keyword, and that's fine with me.

I prefer to have tagged arguments only after keyword.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (San Diego, California): 16198393837
------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28332 for ietf-mta-filters-bks; Wed, 11 Nov 1998 12:22:36 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28328 for <[e-mail]>; Wed, 11 Nov 1998 12:22:34 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA11971; Wed, 11 Nov 1998 15:25:53 -0500 (EST)
Date: 11 Nov 1998 15:25:43 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: security Cocaine Vince Foster supercomputer Croatian FSF terrorist
To: [e-mail]
Subject: mostly open issues
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Here are the things I still believe are unresolved.

1.  Request: Implementations are required to decode header charsets. 

    (Chris and Harald have probably resolved this, but I need to figure
    out wording.)

2.  Request: Reject should be optional. 

    (I just want to know that this is consensus.)

3.  Request: forward adds Resent-* headers. 

    (I just want to know that this is consensus.)

4.  Request: Short-circuit evaluation should be either MAY or MUST, and
    must be discussed in case it matters in the future.

    (I have heard contradictory opinions on this.  Someone (I forget
    who) wanted it removed since it doesn't yet matter.  Chris (and
    probably others) want it in there because it will probably
    eventually matter.  I propose that it has to be discussed, is a MAY
    for implementations, and a MUST if extensions offer tests with side
    effects.)

I have a list of things I expect to change in -05 at
<http://www.contrib.andrew.cmu.edu/~tjs/sieve-changes.html>, which is
the list I posted last week with all the changes I know about.

Thanks!

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27717 for ietf-mta-filters-bks; Wed, 11 Nov 1998 11:57:39 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27713 for <[e-mail]>; Wed, 11 Nov 1998 11:57:38 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA18280; Wed, 11 Nov 1998 12:00:17 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e41b26f9989b17e@129.46.219.133>
In-Reply-To: <005f01be0d92$c11f41b0$[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 11:46:58 -0800
To: Wilbert de Graaf <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft - Forward
Sender: [e-mail]
Precedence: bulk

At 5:45 PM +0100 11/11/98, Wilbert de Graaf wrote:

> I suggest this action [forward] also inserts the Resent-From: header.

My implementation adds Resent-From, Resent-To, Resent-Date, and 
Resent-Message-ID.  If multiple recipients are specified in the Forward 
action, I say "Resent-To: (undisclosed recipients)" to avoid revealing 
the recipients to each other.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27672 for ietf-mta-filters-bks; Wed, 11 Nov 1998 11:52:39 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27665 for <[e-mail]>; Wed, 11 Nov 1998 11:52:37 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA09286; Wed, 11 Nov 1998 14:55:53 -0500 (EST)
Date: 11 Nov 1998 14:55:43 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: NORAD munitions Legion of Doom $400 million in gold bullion Treasury PLO South Africa
To: [e-mail]
In-reply-to: <v04102e3db26f97a33f1c@129.46.219.133>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 11 Nov 1998 11:40:59 -0800
> From: Randall Gellens <[e-mail]>

> >> My Sieve implementation uses "envelope.rcpt" and "envelope.from" as tests.
> >
> > Do we need to add . to the list of legal characters in an identifier?
> > I'd rather not.
> 
> I don't consider "." as part of an identifier.  I treat "envelope.rcpt" 
> as two identifiers: "envelope", which indicates use of the envelope 
> extension, and "rcpt", which is recognized within the envelope 
> extension context.

According to the grammar, you can't have dot outside of a quoted string
or a multi-line.  It can't be part of the identifier, and it can't just
be there.

I'm under the impression that the point of the major grammar changes in
04 were so that extensions didn't have to change the grammar.  I really
don't want to start doing that, because it will get ugly real fast.

To be honest, I don't like dot in that context because it looks like a
structure reference to me.  Then again, I can't think of anything I like
better, but I want a third opinion.

Either we need to change the grammar to allow the extension, or the
extension to fit the grammar, and I'd like to know which.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27640 for ietf-mta-filters-bks; Wed, 11 Nov 1998 11:46:16 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27636 for <[e-mail]>; Wed, 11 Nov 1998 11:46:14 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]> for [e-mail]; Wed, 11 Nov 1998 11:48:31 PST
Date: Wed, 11 Nov 1998 11:47:53 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft
In-reply-to: "Your message dated Wed, 11 Nov 1998 13:20:35 -0500" <000d01be0d9f$f995ae50$[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Tim:
> > > I want to be able to test "envelope-sender" too, and we have that in
> > > our implementation...
> >
> > What does the command look like?  If you've got a working syntax, we
> > might as well use it.

> } elseif  envelopesender :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {

> I actually like Randy's "envelope.rcpt" and "envelope.from".  If you want
> to avoid the ".", we could make it like "header":

> } elseif envelope ["from"] :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {

> ...which also allows '["from", "rcpt"]' for more flexibility.

What a great idea! I really like this approach, even though it isn't what
I implemented.

				Ned



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27611 for ietf-mta-filters-bks; Wed, 11 Nov 1998 11:43:05 -0800 (PST)
Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27607 for <[e-mail]>; Wed, 11 Nov 1998 11:43:04 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA10789; Wed, 11 Nov 1998 11:45:18 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e40b26f9959a63f@129.46.219.133>
In-Reply-To: <000e01be0da0$f698cc90$[e-mail]>
References: <005f01be0d92$c11f41b0$[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 11:43:40 -0800
To: "Barry Leiba" <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft - Forward
Sender: [e-mail]
Precedence: bulk

At 1:27 PM -0500 11/11/98, Barry Leiba wrote:

> In fact, our implementation will do "keep" in addition to any "forward";
> if you want to forward and discard, you must explicitly do it:

My implementation does the same thing.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27606 for ietf-mta-filters-bks; Wed, 11 Nov 1998 11:43:01 -0800 (PST)
Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27602 for <[e-mail]>; Wed, 11 Nov 1998 11:43:00 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA10781; Wed, 11 Nov 1998 11:45:15 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e3fb26f99099369@129.46.219.133>
In-Reply-To: <000d01be0d9f$f995ae50$[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 11 Nov 1998 11:42:39 -0800
To: "Barry Leiba" <[e-mail]>, <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft
Sender: [e-mail]
Precedence: bulk

At 1:20 PM -0500 11/11/98, Barry Leiba wrote:

> } elseif envelope ["from"] :contains :comparator "i;ascii-casemap" 
> ["ietf-sasl"]  {
>
> ...which also allows '["from", "rcpt"]' for more flexibility.

I like using the same form for envelope and header.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26933 for ietf-mta-filters-bks; Wed, 11 Nov 1998 10:24:32 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26929 for <[e-mail]>; Wed, 11 Nov 1998 10:24:31 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id NAA06182 for <[e-mail]>; Wed, 11 Nov 1998 13:27:51 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id NAA13824 for <[e-mail]>; Wed, 11 Nov 1998 13:27:50 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id NAA017.30; Wed, 11 Nov 1998 13:27:43 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft - Forward
Date: Wed, 11 Nov 1998 13:27:39 -0500
Message-ID: <000e01be0da0$f698cc90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <005f01be0d92$c11f41b0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Wilbert de Graaf says...

> Furthermore, I also would like to see a copy-forward action: instead of 
> forwarding, deliver the message and send a copy to the specified address. 

There's nothing wrong with using "forward" and "fileinto" (or "keep") 
together to accomplish this.  I do that in my sieve script:

} elseif  envelopesender :contains :comparator "i;ascii-casemap" [...]  {
    forward "[e-mail]";
    fileinto "Lists";
} ...


In fact, our implementation will do "keep" in addition to any "forward";
if you want to forward and discard, you must explicitly do it:

} elseif  envelopesender :contains :comparator "i;ascii-casemap" ["xagentft"]  {
  if header ["subject"] :contains :comparator "i;ascii-casemap" ["sent to your workstation"] {
    forward "[e-mail]";
    discard;
  } else {
    keep;
  }
} ...


(BTW, I find it *much* more useful to use "envelopesender" than to use
the document header fields.  Suppose I'm subscribed to the IMAP, ACAP,
IMAPEXT, and MTA-FILTERS mailing lists, and someone posts something to
all of them.  With "envelopesender" I can sort the four copies into their
respective folders.  Without it, there's no way to do that.)

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26849 for ietf-mta-filters-bks; Wed, 11 Nov 1998 10:17:33 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26845 for <[e-mail]>; Wed, 11 Nov 1998 10:17:31 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id NAA08186 for <[e-mail]>; Wed, 11 Nov 1998 13:20:47 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id NAA13912 for <[e-mail]>; Wed, 11 Nov 1998 13:20:46 -0500
Received: from mars by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id NAA017.29; Wed, 11 Nov 1998 13:20:39 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft
Date: Wed, 11 Nov 1998 13:20:35 -0500
Message-ID: <000d01be0d9f$f995ae50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

Tim:
> > I want to be able to test "envelope-sender" too, and we have that in
> > our implementation...
> 
> What does the command look like?  If you've got a working syntax, we
> might as well use it.

} elseif  envelopesender :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {

I actually like Randy's "envelope.rcpt" and "envelope.from".  If you want
to avoid the ".", we could make it like "header":

} elseif envelope ["from"] :contains :comparator "i;ascii-casemap" ["ietf-sasl"]  {

...which also allows '["from", "rcpt"]' for more flexibility.

Barry Leiba, Multimedia Messaging   ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26165 for ietf-mta-filters-bks; Wed, 11 Nov 1998 08:42:59 -0800 (PST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26160 for <[e-mail]>; Wed, 11 Nov 1998 08:42:52 -0800 (PST)
Received: from david.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3149) with SMTP id <[e-mail]> for [e-mail]; Wed, 11 Nov 1998 17:45:48 +0100
Received: from l4146 by david.research.kpn.com (SMI-8.6/SMI-SVR4) id RAA16180; Wed, 11 Nov 1998 17:45:57 +0100
Date: Wed, 11 Nov 1998 17:45:55 +0100
From: Wilbert de Graaf <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft - Forward
To: [e-mail]
Message-id: <005f01be0d92$c11f41b0$[e-mail]>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 4.72.3110.5
Content-type: multipart/alternative; boundary="----=_NextPart_000_005C_01BE0D9B.22387590"
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Priority: 3
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01BE0D9B.22387590
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tim,

I want to suggest to add a header to the original message on the action =
'forward'

: Syntax:    forwadrd <address>
: ... . The "forward" action makes no changes to the message body or =
headers, and=20
: only modifies the envelope recipient.

I suggest this action also inserts the Resent-From: header. This header =
is specified
in RFC 822:

+++ rfc 822 snippet +++
4.2 Forwarding

    Some  systems permit  mail recipients  to  forward  a  message,=20
retaining  the  original  headers  by adding  some new fields. This=20
standard  supports such  a service, through the "Resent-" prefix to=20
field names.
+++ rfc 822 snippet +++

Some systems might reject to forward mail, since the MTA could see this =
as a relay=20
from the original sender to some remote address. If the Resent-From: =
<original recipient>
is inserted, this might be suppressed.

Furthermore, I also would like to see a copy-forward action: instead of =
forwarding, deliver
the message and send a copy to the specified address. We use this =
mechanism to send a a copy
to sopme system, which notifies the reciver on their mobile system. I do =
not see another way
how sieve could help me to solve this problem.

- Wilbert


------=_NextPart_000_005C_01BE0D9B.22387590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2>Tim,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>I want to =
suggest to add a=20
header to the original message on the action 'forward'</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>: =
Syntax:&nbsp;&nbsp;&nbsp;=20
forwadrd &lt;address&gt;</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>: ... . The=20
&quot;forward&quot; action makes no changes to the message body or =
headers, and=20
</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>: only modifies =
the envelope=20
recipient.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>I suggest this =
action also=20
inserts the Resent-From: header. This header is specified</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>in RFC 822:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>+++ rfc 822 =
snippet=20
+++</FONT></DIV></FONT><FONT color=3D#000000 face=3D"Courier New" =
size=3D2>4.2=20
Forwarding</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; Some&nbsp; systems =
permit&nbsp;=20
mail recipients&nbsp; to&nbsp; forward&nbsp; a&nbsp; message, =
</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>retaining&nbsp; the&nbsp; =
original&nbsp;=20
</FONT><FONT face=3D"Courier New" size=3D2>headers&nbsp; by adding&nbsp; =
some new=20
fields. This </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>standard&nbsp; supports =
such&nbsp; a=20
service, through </FONT><FONT face=3D"Courier New" size=3D2>the =
&quot;Resent-&quot;=20
prefix to </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>field names.</FONT></DIV>
<DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>+++ rfc 822 =
snippet=20
+++</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</DIV></FONT></DIV></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>Some systems =
might reject to=20
forward mail, since the MTA could see this as a relay </FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" size=3D2>from the </FONT><FONT face=3D"Courier New" =

size=3D2>original sender to some remote address. If the Resent-From: =
&lt;original=20
recipient&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>is inserted, this might be=20
suppressed.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2>Furthermore, I =
also would=20
like to see a copy-forward action: instead of forwarding, =
deliver</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Courier New" size=3D2></FONT><FONT=20
face=3D"Courier New" size=3D2>the message and send a copy to the =
specified address.=20
We use this mechanism to send a a copy</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>to sopme system, which notifies =
the reciver=20
on their mobile system. I do not see another way</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>how sieve could help me to =
solve this=20
problem.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>- Wilbert</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005C_01BE0D9B.22387590--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA06952 for ietf-mta-filters-bks; Tue, 10 Nov 1998 21:34:14 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA06948 for <[e-mail]>; Tue, 10 Nov 1998 21:34:13 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id AAA14959; Wed, 11 Nov 1998 00:37:04 -0500 (EST)
Date: 11 Nov 1998 00:36:56 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: DES cracking militia Delta Force Mossad plutonium Saddam Hussein
To: [e-mail], Randall Gellens <[e-mail]>
In-reply-to: <v04102e29b26e7bfb9c1e@129.46.219.133>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Tue, 10 Nov 1998 15:30:04 -0800
> From: Randall Gellens <[e-mail]>
 
> My Sieve implementation uses "envelope.rcpt" and "envelope.from" as tests.

Do we need to add . to the list of legal characters in an identifier?
I'd rather not.

> I've also implemented "Mark" as an action which adds a header to the 
> message; "^f" and "^r" are expanded to the envelope return-path and 
> recipient, respectively.
> 
> For example (from my test Sieve script):
> 
> 	if envelope.rcpt contains "+"
> 		mark "x-detail: ^r";

Ok.  So what does x-detail signify?

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00302 for ietf-mta-filters-bks; Tue, 10 Nov 1998 15:27:26 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.2.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00298 for <[e-mail]>; Tue, 10 Nov 1998 15:27:26 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA01979; Tue, 10 Nov 1998 15:29:55 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04102e29b26e7bfb9c1e@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <000101be09fa$35bfd170$[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 10 Nov 1998 15:30:04 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Sender: [e-mail]
Precedence: bulk

At 4:29 PM -0500 11/10/98, Tim Showalter wrote:

> Reject, fileinto, and envelope-sender commands all have problems that
> not all systems can actually implement them, so I think we're pretty
> much screwed here, although perhaps reject and envelope-sender need to
> be added to the draft.
>
>> I want to be able to test "envelope-sender" too, and we have that in
>> our implementation...
>
> What does the command look like?  If you've got a working syntax, we
> might as well use it.

My Sieve implementation uses "envelope.rcpt" and "envelope.from" as tests.

I've also implemented "Mark" as an action which adds a header to the 
message; "^f" and "^r" are expanded to the envelope return-path and 
recipient, respectively.

For example (from my test Sieve script):

	if envelope.rcpt contains "+"
		mark "x-detail: ^r";


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29475 for ietf-mta-filters-bks; Tue, 10 Nov 1998 13:26:14 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29471 for <[e-mail]>; Tue, 10 Nov 1998 13:26:08 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA18648; Tue, 10 Nov 1998 16:29:21 -0500 (EST)
Date: 10 Nov 1998 16:29:13 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: class struggle Waco, Texas plutonium Honduras PLO security COSCO
To: [e-mail]
In-reply-to: <000101be09fa$35bfd170$[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> From: "Barry Leiba" <[e-mail]>
> Date: Fri, 6 Nov 1998 21:56:26 -0500

> > 13. Request: Reject should be optional.
> 
> At one level I agree with this, but at another level (and this applies
> to optional "fileinto" also) I think that making the basic features 
> optional hurts interopreability -- that is, it hurts portability of
> scripts.  That said, I understand *why* people want to make "fileinto"
> and "reject" optional.

Reject, fileinto, and envelope-sender commands all have problems that
not all systems can actually implement them, so I think we're pretty
much screwed here, although perhaps reject and envelope-sender need to
be added to the draft.

> I want to be able to test "envelope-sender" too, and we have that in
> our implementation...

What does the command look like?  If you've got a working syntax, we
might as well use it.

> > 1.  "Matches" should be just another comparator, in my opinion.
> 
> Sort of.  The problem with that is that it introduces a whole set
> of comparators: matches-ascii, matches-ascii-casemap, and so on,
> one for each comparator that's used for "contains".

Okay.  I withdraw this, and will put :matches back into the next draft.
That's clearly better than having comparators all over the place.

I think that's probably the general opinion, too.

I think having :changes, :is, and :matches is useful, but we could do it 
all with :matches if people really wanted to.

> > 2a. Can we keep tagged arguments?
> 
> Sure, why not?

There was a complaint about the change from "is" to ":is", but I'm
rather attached to :is for reasons I stated.  

> > 2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
> ...
> >     What do people want?  The dominant stated opinion is that they should 
> >     only happen after the keyword, and that's fine with me.
> 
> Yes, I'm of that opinion.

Ok, I'll plan on changing things this way.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28594 for ietf-mta-filters-bks; Tue, 10 Nov 1998 11:54:29 -0800 (PST)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28590 for <[e-mail]>; Tue, 10 Nov 1998 11:54:27 -0800 (PST)
Received: from alden ([193.216.167.143]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id UAA30733; Tue, 10 Nov 1998 20:55:55 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 10 Nov 1998 20:50:03 +0100
To: Chris Newman <[e-mail]>
From: Harald Tveit Alvestrand <[e-mail]>
Subject: Re: Charset sensitive compares (was Re: List of expected changes ...)
Cc: Tim Showalter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 09:53 10.11.98 -0800, Chris Newman wrote:
>There are three issues to address:
>
>(1) Which charsets are permitted in the scripting language (currently
>only UTF-8).
>
>(2) Which charsets constitute minimal support for RFC 2049 in incoming
>message headers.
>
>(3) What to do when charsets from (1) & (2) mismatch.
>
>I have a strong preference to keep (1) unchanged -- UTF-8 only.  Allowing
>a script to contain embedded data in multiple charsets makes script
>viewing and composition _much_ more complex as well as making the
>cross-charset comparison problem even worse.

Agreed.

>As for (2), I'd say if RFC 2049 decoding is done, support for UTF-8,
>ISO-8859-1, and the ASCII subset of the ISO-8859-* charsets should be the
>minimum required.  UTF-8 is required by RFC 2277 and is easy since it
>matches the charset for the scripting language.  ISO-8859-1 is easy since
>it's a proper subset of UTF-8.  And the other rule (at least the ASCII
>subset of ISO-8859-*) comes directly from RFC 2049. 

Makes sense.

>In the interest of getting Sieve deployed faster, it may be desirable to
>permit implementations which don't support RFC 2049 to be compliant
>(possibly under a SHOULD support RFC 2049 clause).  When RFC 2049 isn't
>supported, I'd say that a comparision string in the script with 8-bit
>content MUST fail to match (we have to hold the line on just-send-8 in
>headers now so we can allow UTF-8 in headers down the road).

Agreeed.
Do you have anything like a "feature test macro" in the language now?
I'm thinking of something like

   require charset iso-2022-jp

to let a script say that unless the server is able to decode this
charset into UTF-8 for comparision, the script should go Boink at once
instead of behaving randomly.

>(3) is nasty and creates the behavior change you noted as servers are
>upgraded to support more charsets.  As long as (1) is fixed at UTF-8, that
>effectively requires translation to UTF-8 to do comparisons.
>
>
>The alternative would be to allow scripts to embed octet strings labelled
>with a charset for comparison purposes.  While that would make Japanese or
>Chinese localization easier, it makes the international problem harder in
>addition to the other drawbacks mentioned above.

OK, let's require that "all actions have the same result as if all
character data was converted to UTF-8 before comparisions are done".
And 2049 strings in unknown charsets don't match anything at all.

Seems to make sense to me.

                  Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27528 for ietf-mta-filters-bks; Tue, 10 Nov 1998 09:50:32 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27524 for <[e-mail]>; Tue, 10 Nov 1998 09:50:31 -0800 (PST)
Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-29 #30494) with ESMTPS id <[e-mail]> for [e-mail]; Tue, 10 Nov 1998 09:53:21 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.60]) by elvira.innosoft.com (PMDF V5.2-29 #13579) with SMTP id <[e-mail]> for [e-mail]; Tue, 10 Nov 1998 09:52:25 -0800 (PST)
Date: Tue, 10 Nov 1998 09:53:30 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Charset sensitive compares (was Re: List of expected changes ...)
In-reply-to: <[e-mail]>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Harald Tveit Alvestrand <[e-mail]>
Cc: Tim Showalter <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

There are three issues to address:

(1) Which charsets are permitted in the scripting language (currently
only UTF-8).

(2) Which charsets constitute minimal support for RFC 2049 in incoming
message headers.

(3) What to do when charsets from (1) & (2) mismatch.

I have a strong preference to keep (1) unchanged -- UTF-8 only.  Allowing
a script to contain embedded data in multiple charsets makes script
viewing and composition _much_ more complex as well as making the
cross-charset comparison problem even worse.

As for (2), I'd say if RFC 2049 decoding is done, support for UTF-8,
ISO-8859-1, and the ASCII subset of the ISO-8859-* charsets should be the
minimum required.  UTF-8 is required by RFC 2277 and is easy since it
matches the charset for the scripting language.  ISO-8859-1 is easy since
it's a proper subset of UTF-8.  And the other rule (at least the ASCII
subset of ISO-8859-*) comes directly from RFC 2049. 

In the interest of getting Sieve deployed faster, it may be desirable to
permit implementations which don't support RFC 2049 to be compliant
(possibly under a SHOULD support RFC 2049 clause).  When RFC 2049 isn't
supported, I'd say that a comparision string in the script with 8-bit
content MUST fail to match (we have to hold the line on just-send-8 in
headers now so we can allow UTF-8 in headers down the road).

(3) is nasty and creates the behavior change you noted as servers are
upgraded to support more charsets.  As long as (1) is fixed at UTF-8, that
effectively requires translation to UTF-8 to do comparisons.


The alternative would be to allow scripts to embed octet strings labelled
with a charset for comparison purposes.  While that would make Japanese or
Chinese localization easier, it makes the international problem harder in
addition to the other drawbacks mentioned above.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA14216 for ietf-mta-filters-bks; Tue, 10 Nov 1998 01:19:43 -0800 (PST)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA14211 for <[e-mail]>; Tue, 10 Nov 1998 01:19:39 -0800 (PST)
Received: from alden ([10.128.1.82]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id KAA24675; Tue, 10 Nov 1998 10:21:27 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 10 Nov 1998 10:21:56 +0100
To: Chris Newman <[e-mail]>, Tim Showalter <[e-mail]>
From: Harald Tveit Alvestrand <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Cc: [e-mail]
In-Reply-To: <[e-mail].c om>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA14212
Sender: [e-mail]
Precedence: bulk

At 15:52 09.11.98 -0800, Chris Newman wrote:
>
>> 7.  Request: Implementations are required to decode header charsets.
>
>I could live with this.  A lighter-weight alternative would be:
>Implementations are required to (a) treat all non-ASCII characters in a
>script as a syntax error or (b) decode MIME header encoding.  That's the
>"you don't have to do it, but if you do it, do it right" approach.
>

Decoding to what?

3 possibilities:

- Decode to octet string (simple, but dangerous)
- Decode to UTF-8 (requires universal charset translation)
- Decode if you recognize the charset, otherwise leave alone, which
  leaves a *slight* incompatibility problem with server upgrades.
 
I'm fine with the decoding being to an octet string, and the expected
charset being implicit in the comparator function, but one needs
to *somehow* get access to the charset name(s?) to be able to detect the
case where "shit happens".
Something like this:

  if subject contains "I ordered a Räksmörgås" then
      if matched charset is iso-8859-1 then
          do something
      else
          don't dare to do something
      fi
  fi

Syntax wildly inventive...haven't read -04, I'm afraid....

Note that Räksmörgås will be represented in UTF-8 in the script while
the script is being moved around. UTF-8 can't represent the octets
of 8859-1 without an escaping mechanism, and a layman user would go
bonkers if asked to use one.

And simply declaring matching on anything that isn't English illegal
forever is Not An Option.

We have a problem.

(Räksmörgås is Swedish for a shrimp open-faced sandwich; popular for
testing because it contains the 3 most important special Swedish letters...)

                     Harald

      

-- 
Harald Tveit Alvestrand, Maxware, Norway
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00871 for ietf-mta-filters-bks; Mon, 9 Nov 1998 19:31:19 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00867 for <[e-mail]>; Mon, 9 Nov 1998 19:31:18 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA07284; Mon, 9 Nov 1998 22:34:25 -0500 (EST)
Date: 9 Nov 1998 22:34:20 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Honduras munitions Craig Livingstone Ortega arrangements Soviet Peking
To: [e-mail]
Cc: Chris Newman <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 09 Nov 1998 15:52:27 -0800 (PST)
> From: Chris Newman <[e-mail]>

> > 4.  Question: Should i;ascii-casemap be the default?
> 
> I'm not sure.  How does this interact with the local-part being
> case-sensitive and the domain-part being case-insensitive?  Could it lead
> to confusion?

Hm.  Perhaps we should just canonicalize all domain names to
(lower/upper)case for compares, then provide primitives (i.e., not
"header") for looking at to/from/cc like IMAP does for looking at parsed
address headers.  (That's simpler than anything else I can think of.)
Then we can make casemap the default.

Making i;ascii the default is more or less a lose for similar arguments,
so I'd rather not do that.

> > 7.  Request: Implementations are required to decode header charsets.
> 
> I could live with this.  A lighter-weight alternative would be:
> Implementations are required to (a) treat all non-ASCII characters in a
> script as a syntax error or (b) decode MIME header encoding.  That's the
> "you don't have to do it, but if you do it, do it right" approach.
> 
> > 10. Bug: Header name compares are always case-insensitive.
> 
> Why is that a bug?  Header names are US-ASCII case insensitive in RFC 822.

Er, that's not necessarily what the draft says, but it should be.  I
don't think it's clear int he draft.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26811 for ietf-mta-filters-bks; Mon, 9 Nov 1998 15:50:29 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26807 for <[e-mail]>; Mon, 9 Nov 1998 15:50:18 -0800 (PST)
Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-29 #30494) with ESMTPS id <[e-mail]> for [e-mail]; Mon, 9 Nov 1998 15:52:15 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.60]) by elvira.innosoft.com (PMDF V5.2-29 #13579) with SMTP id <[e-mail]> for [e-mail]; Mon, 09 Nov 1998 15:51:21 -0800 (PST)
Date: Mon, 09 Nov 1998 15:52:27 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
In-reply-to: <[e-mail]>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

On Fri, 6 Nov 1998, Tim Showalter wrote:
> 1.  Concensus: Short circuit evaluation is a SHOULD, not a MUST.
>
> 2.  Question: Should short-circuit evaluation be as is, a MAY, or not
>     discussed at all?

Short-circuit evaluation should either be a MUST or a MAY.  It needs to be
mentioned, so people know whether or not they can rely on it when writing
code.

> 3.  Concensus: i;ascii-casemap is required.

Yup.

> 4.  Question: Should i;ascii-casemap be the default?

I'm not sure.  How does this interact with the local-part being
case-sensitive and the domain-part being case-insensitive?  Could it lead
to confusion?

> 6.  Request: A non-present comparator is considered to be basically a syntax
>     error.

Sounds reasonable.

> 7.  Request: Implementations are required to decode header charsets.

I could live with this.  A lighter-weight alternative would be:
Implementations are required to (a) treat all non-ASCII characters in a
script as a syntax error or (b) decode MIME header encoding.  That's the
"you don't have to do it, but if you do it, do it right" approach.

> 10. Bug: Header name compares are always case-insensitive.

Why is that a bug?  Header names are US-ASCII case insensitive in RFC 822.

		- Chris



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA17572 for ietf-mta-filters-bks; Fri, 6 Nov 1998 18:53:35 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17568 for <[e-mail]>; Fri, 6 Nov 1998 18:53:34 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id VAA07210 for <[e-mail]>; Fri, 6 Nov 1998 21:56:31 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id VAA19332 for <[e-mail]>; Fri, 6 Nov 1998 21:56:31 -0500
Received: from uranus by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id VAA004.35; Fri, 6 Nov 1998 21:56:27 -0500
From: "Barry Leiba" <[e-mail]>
To: <[e-mail]>
Subject: RE: List of expected changes for sieve 05 draft
Date: Fri, 6 Nov 1998 21:56:26 -0500
Message-ID: <000101be09fa$35bfd170$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 4.  Question: Should i;ascii-casemap be the default?

I vote for that.

> 6.  Request: A non-present comparator is considered to be basically a syntax
>     error.
> 
> 7.  Request: Implementations are required to decode header charsets.

Since these requests came from comments by me, I should state clearly
that I agree with these two.

> 13. Request: Reject should be optional.

At one level I agree with this, but at another level (and this applies
to optional "fileinto" also) I think that making the basic features 
optional hurts interopreability -- that is, it hurts portability of
scripts.  That said, I understand *why* people want to make "fileinto"
and "reject" optional.  I want to be able to test "envelope-sender"
too, and we have that in our implementation... but I understand why
people don't want it as a required function.

> 1.  "Matches" should be just another comparator, in my opinion.

Sort of.  The problem with that is that it introduces a whole set
of comparators: matches-ascii, matches-ascii-casemap, and so on,
one for each comparator that's used for "contains".  In some sense,
though, it's not a problem: "contains xxx" is basically just
"matches *xxx*", but for the fact that "contains x*x" is *not*
the same as "matches *x*x*".  If we put in an escape character for
the wildcards, then we can get rid of "contains" and "is", and 
just use "matches" for everything:
   :is "abc" ...becomes... :matches "abc"
   :contains "abc" ...becomes... :matches "*abc*"
   :is "a*c" ...becomes... :matches "a\*c"
   :contains "a*c" ...becomes... :matches "*a\*c*"

I guess I'm not really stating much of an opinion on this; I think
it's fine the way it is, with "is", "contains", and "matches".  But
if we're going to make a change here, I suppose we should think about
this.

> 2a. Can we keep tagged arguments?

Sure, why not?

> 2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
...
>     What do people want?  The dominant stated opinion is that they should 
>     only happen after the keyword, and that's fine with me.

Yes, I'm of that opinion.


Barry Leiba, Multimedia Messaging  ([e-mail])
http://www.research.ibm.com/people/l/leiba




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15482 for ietf-mta-filters-bks; Fri, 6 Nov 1998 13:37:26 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15477 for <[e-mail]>; Fri, 6 Nov 1998 13:37:25 -0800 (PST)
Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA15848; Fri, 6 Nov 1998 16:40:16 -0500 (EST)
Date: 6 Nov 1998 16:40:13 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Ortega Legion of Doom NSA fissionable Saddam Hussein class struggle arrangements
To: [e-mail]
Subject: List of expected changes for sieve 05 draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I hope to have an 05 draft out real soon now.

Here are the list of things that I know of (and remember) that have been
requested as changes in the next draft.  They're marked as follows:

* "Consensus" indicates something that I believe is consensus, and will change.
* "Bug" indicates something that's just wrong.
* "Request" indicates something that someone has asked for, and will be
  changed if I get confirmation that it's consensus.
* "Question" indicates something that I'm not sure how I'm supposed to word
  it, and would appreciate some more information.

1.  Concensus: Short circuit evaluation is a SHOULD, not a MUST.

2.  Question: Should short-circuit evaluation be as is, a MAY, or not
    discussed at all?

3.  Concensus: i;ascii-casemap is required.

4.  Question: Should i;ascii-casemap be the default?

5.  Consensus: Fileinto is optional; discussion of local mail folders and POP3 
    should be removed.

6.  Request: A non-present comparator is considered to be basically a syntax
    error.

7.  Request: Implementations are required to decode header charsets.

8.  Bug: Section 7, remove reference to "support" and "reply".

9.  Bug: Remove all XXXs (section 2.3, 2.11.1, for instance) and fix all
    examples.

10. Bug: Header name compares are always case-insensitive.
     
11. Bug: 4.2: example is incorrect.  ("From" should be "To"; contains should
    be :contains)

12. Consensus: What happens when an error occurs should be dropped; it should
    not be part of the specification, and is just a quality-of-implementation
    issue.

13. Request: Reject should be optional.

14. Consensus: There should be two namespaces for extension names, one "vnd.", 
    one everything else, just like several other protocols.

I am way overdue for posting the reasons that I made some of the changes to
the draft.  Here they are.  (Some, not all, of these were made in the long
delay between 03 and 04, and were ok with the circa 03 list participants and
not okay with the influx of people after 04.)

1.  "Matches" should be just another comparator, in my opinion.
    (This allows easy addition of regular expressions or globs.)
    I'm not real attached to this.

2.  Tagged arguments: Some time ago, tagged arguments were proposed and
    accepted.  I strongly prefer them because they allow keywords to be taken
    out of the grammar, reducing the number of special cases, and allowing
    extensions to be added without changes to the grammar.

2a. Can we keep tagged arguments?

2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
    interspersed in commands.  This was probably a mistake, but I wanted to
    preserve wordings like this:

       header "From" :contains "tjs"

    What do people want?  The dominant stated opinion is that they should only 
    happen after the keyword, and that's fine with me.

3.  Elsif was added because it removes an ambiguity in the grammar, making
    "else" yet another command.  This is discussed in anything that talks
    about writing C parsers; "else if" is an imbiguity, and many languages
    have an "elsif" as a result.  I have a fairly strong preference for this.

    Note that "else if" is illegal in 04.

4.  The formal grammar was a major change from 03, and I have strong
    reservations against changing it back.  03 had a grammar that was
    over-specified, and under-permissive.  Every extension required a grammar
    change; this seems likely to lead to a horrible grammar when all is said
    and done.

    This has probably left considerable ambiguity in some other places in the
    draft, but I don't beleive that's a good reason to switch back to the
    previous grammar.

-- 
Tim Showalter <[e-mail]>