Re: envelope test syntax?

[Michael Haardt <[e-mail]>]

> > > How would you arrange to get an empty set of headers?
> > 
> >   exists [ ]
> > 
> > That's an empty list of headers.
>
> My reading says that a string list has to have at least one string,
> thus the question of how you would get an empty list.  Am I reading
> wrong?

Fascinating.  I managed to get my code right in not allowing empty string
lists, yet I somehow thought they were possible, discussed the problem
and documented the resulting opinion.  The "exists" code could cope with
empty lists, but it will never see any.

Thanks for that hint, I will change the documentation to remove the
paragraph talking about empty string lists.  There are still enough
other points, though.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4QAN4hp093891; Wed, 26 May 2004 03:23:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4QAN4nY093890; Wed, 26 May 2004 03:23:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4QAN1aO093874 for <[e-mail]>; Wed, 26 May 2004 03:23:03 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with asmtp (Exim 4.34) id 1BSvYp-0006vY-Sh for [e-mail]; Wed, 26 May 2004 12:22:59 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33 #3) id 1BSvYp-0003x2-Pm for [e-mail]; Wed, 26 May 2004 12:22:59 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.34 #1) id 1BSvYp-00037X-H1 for [e-mail]; Wed, 26 May 2004 12:22:59 +0200
To: [e-mail]
Subject: Re: envelope test syntax?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 26 May 2004 12:22:59 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > How would you arrange to get an empty set of headers?
> > 
> >   exists [ ]
> > 
> > That's an empty list of headers.
>
> My reading says that a string list has to have at least one string,
> thus the question of how you would get an empty list.  Am I reading
> wrong?

Fascinating.  I managed to get my code right in not allowing empty string
lists, yet I somehow thought they were possible, discussed the problem
and documented the resulting opinion.  The "exists" code could cope with
empty lists, but it will never see any.

Thanks for that hint, I will change the documentation to remove the
paragraph talking about empty string lists.  There are still enough
other points, though.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4K0ETWr081717; Wed, 19 May 2004 17:14:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4K0ETCD081716; Wed, 19 May 2004 17:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4K0ES2p081702 for <[e-mail]>; Wed, 19 May 2004 17:14:28 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (adsl-64-164-137-106.dsl.snfc21.pacbell.net [64.164.137.106]) by mail.apptran.com (8.12.8/8.12.8) with ESMTP id i4K0ESV3028548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 17:14:29 -0700
Message-ID: <[e-mail]>
Date: Wed, 19 May 2004 17:14:29 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: envelope test syntax?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett wrote:

>>  exists [ ]

> My reading says that a string list has to have at least one string,
> thus the question of how you would get an empty list.  Am I reading
> wrong?

I don't think so--the syntax does seem to require at least one.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JNnWT4080339; Wed, 19 May 2004 16:49:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JNnWpc080338; Wed, 19 May 2004 16:49:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4JNnVGf080331 for <[e-mail]>; Wed, 19 May 2004 16:49:31 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 11846 invoked from network); 19 May 2004 19:49:36 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 19 May 2004 19:49:36 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 3562 invoked by uid 101); 19 May 2004 19:49:36 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 19 May 2004 19:49:36 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 19, 2004 at 04:35:49PM +0200, Michael Haardt wrote:

   [ stuff about angels on heads of pins snipped ]


> > > The "exists" test only suceeds if all specified headers exist.  RFC 3028
> > > does not explicitly specify what happens on an empty list of headers.
> > > This implementation evaluates that condition with true, interpreting
> > > the RFC in a strict sense.
> >
> > How would you arrange to get an empty set of headers?
> 
>   exists [ ]
> 
> That's an empty list of headers.

My reading says that a string list has to have at least one string,
thus the question of how you would get an empty list.  Am I reading
wrong?

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEZxSl037563; Wed, 19 May 2004 07:35:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JEZx0R037562; Wed, 19 May 2004 07:35:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEZq7g037554 for <[e-mail]>; Wed, 19 May 2004 07:35:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with asmtp (Exim 4.33) id 1BQSAf-00017e-MD for [e-mail]; Wed, 19 May 2004 16:35:49 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33 #3) id 1BQSAf-00061b-Ia for [e-mail]; Wed, 19 May 2004 16:35:49 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.34 #1) id 1BQSAf-0000hy-Fi for [e-mail]; Wed, 19 May 2004 16:35:49 +0200
To: [e-mail]
Subject: Re: envelope test syntax?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 19 May 2004 16:35:49 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> True, type checking is a semantic issue (some of which can be done at
> parse time), but that isn't what I was getting at.  "typedef" modifies
> the language syntax.  Consider:
>
> /*1*/    typedef unsigned int  myint;
> /*2*/    myint x = 3;
>
> Without line 1, line 2 has an invalid syntax.  This isn't a
> semantic typechecking problem, it's strictly a syntax issue.

To avoid that, C defines "typedef-name" to be an identifier, thus avoiding
a self-modifying grammar by a more generic grammar with semantics checks.

> Relatedly, the SIEVE RFC doesn't really specify whether "require"
> enables an extension syntax or merely use of an extension at run time.

Indeed, the "require" description refers to section 2.10.5:

   If an extension is not enabled with "require", implementations MUST
   treat it as if they did not support it at all.

But it does not say if this is to be understood strictly or lazy.

> For example, given this complete script:
>
>     if false { fileinto "impossible"; }
>     else { keep; }
>
> Is that a syntax error because it is missing the "require"?

It is as much a syntax error as the following:

    if false { foobar "impossible"; }
    else { keep; }

That does not mean the parser must not parse the above.  It may parse
it and during semantic analysis, the Sieve implementation should treat
a disabled "fileinto" the same as "foobar", which is very easy, since no
flag "fileinto-is-fine" was set by a "require".  A strict implementation
would barf, a lazy one wouldn't, because the unknown command is never
executed.  I will update the Exim Sieve implementation notes to cover
this.

To a certain amount, you can move things between syntax and semantics,
as you can move things between scanner and parser.  Usually, you advance
to the higher layer, if the task becomes too hard or even impossible
at the current layer.

A self-modifying grammar is not context free, so it is usually made
generic enough to become context free, moving additional contraints to the
semantic analysis.  The semantic analysis error handler is of course free
to output "syntax error", if the specification says that it should do so.

> > The "exists" test only suceeds if all specified headers exist.  RFC 3028
> > does not explicitly specify what happens on an empty list of headers.
> > This implementation evaluates that condition with true, interpreting
> > the RFC in a strict sense.
>
> How would you arrange to get an empty set of headers?

  exists [ ]

That's an empty list of headers.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4J8bM7B093640; Wed, 19 May 2004 01:37:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4J8bMtP093639; Wed, 19 May 2004 01:37:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.pinkponk.com (mail.pinkponk.com [213.229.249.151]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4J8bKn0093557 for <[e-mail]>; Wed, 19 May 2004 01:37:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.pinkponk.com by mail.pinkponk.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Wed, 19 May 2004 10:37:21 +0200
Received: from mta1 ([213.229.249.151]) by mta1.pinkponk.com with SMTP id <20040519083734.IRBH15237.mta1.pinkponk.com@mta1> for <[e-mail]>; Wed, 19 May 2004 10:37:34 +0200
X-Mailer: Openwave WebEngine, version 2.8.13.1 (webedge20-101-1100-20040114)
From: <[e-mail]>
To: <[e-mail]>
Subject: forwarding problem
Date: Wed, 19 May 2004 10:37:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Message-Id: <20040519083734.IRBH15237.mta1.pinkponk.com@mta1>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

I need one thing and don't know the answer. On one account I've got enabled 
forwarding. Now, I need to enable that forwarding is done in only one case. 
1)If mail comes from IP1; then forward
2)If mail doesn't come from IP1; then discard 

In mta logs I see header "fromhost", but it doesn't work...So, how to set rule 
to achieve that?
thanks in advance

LP




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IKWq3D079574; Tue, 18 May 2004 13:32:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IKWqOj079573; Tue, 18 May 2004 13:32:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IKWp0U079567 for <[e-mail]>; Tue, 18 May 2004 13:32:52 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: QSXu9Uz9+gui4UFp1Db3/w 1084912313
Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 7AF20B99224; Tue, 18 May 2004 16:31:51 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 18 May 2004 13:31:47 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: allow from only one IP
References: <20040518124924.DILD15237.mta1.pinkponk.com@mta1>
In-Reply-To: <20040518124924.DILD15237.mta1.pinkponk.com@mta1>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 5/18/2004 5:49 AM, [e-mail] sent forth electrons to convey:

>hello,
>
>I need one thing and don't know the answer. On one account I've got enabled forwarding. Now, I need to enable that forwarding is done in only one case. 
>1)If mail comes from IP1; then forward
>2)If mail doesn't come from IP1; then discard 
>
>In mta logs I see header "fromhost", but it doesn't work...So, how to set rule to achieve that?
>thanks in advance
>
>LP
>
>  
>
You're posting in the wrong place - this is for defining standards, not 
troubleshooting.  If this were the right place, you'd need to provide 
info on the MTA you're using.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ICn1Sr048230; Tue, 18 May 2004 05:49:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ICn1bR048229; Tue, 18 May 2004 05:49:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.pinkponk.com (mail.pinkponk.com [213.229.249.151]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4ICmxhU048223 for <[e-mail]>; Tue, 18 May 2004 05:49:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.pinkponk.com by mail.pinkponk.com via smtpd (for mail.vpnc.org [208.184.76.50]) with SMTP; Tue, 18 May 2004 14:49:02 +0200
Received: from mta1 ([213.229.249.151]) by mta1.pinkponk.com with SMTP id <20040518124924.DILD15237.mta1.pinkponk.com@mta1> for <[e-mail]>; Tue, 18 May 2004 14:49:24 +0200
X-Mailer: Openwave WebEngine, version 2.8.13.1 (webedge20-101-1100-20040114)
From: <[e-mail]>
To: <[e-mail]>
Subject: allow from only one IP
Date: Tue, 18 May 2004 14:49:24 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Message-Id: <20040518124924.DILD15237.mta1.pinkponk.com@mta1>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

I need one thing and don't know the answer. On one account I've got enabled forwarding. Now, I need to enable that forwarding is done in only one case. 
1)If mail comes from IP1; then forward
2)If mail doesn't come from IP1; then discard 

In mta logs I see header "fromhost", but it doesn't work...So, how to set rule to achieve that?
thanks in advance

LP



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4GN8okm021429; Sun, 16 May 2004 16:08:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4GN8oXl021428; Sun, 16 May 2004 16:08:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4GN8nps021421 for <[e-mail]>; Sun, 16 May 2004 16:08:49 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (adsl-64-164-137-106.dsl.snfc21.pacbell.net [64.164.137.106]) by mail.apptran.com (8.12.8/8.12.8) with ESMTP id i4GN8oV3021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 May 2004 16:08:51 -0700
Message-ID: <[e-mail]>
Date: Sun, 16 May 2004 16:08:51 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [spamtools] Refuse for IMAP Sieve
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm sending this to spamtools in the hopes of explaining why things are 
the way they are.  My apologies if this is inappropriate or late.  I'm 
not on the list, and I haven't seen the discussion.

On 5/14/2004 3:05 AM, Alex van den Bogaerdt wrote:

> There was not enough confusion yet, so let's redefine "reject" and use
> "refuse" for what others call reject?
>
> Why not simply repair the rfc and let reject do what it should do: give
> a 55x error on delivery.

There's a reason why it works that way.  This was judged the suitable 
behavior of a client, which can't issue a 55x error because the message 
has already been delivered.  (Okay, the client could forge a bounce, but 
such things are not good design.)  Sieve could (and has) been 
implemented client-side without IMAP server support.

I can think of two reasons why we shouldn't change this to MUST either 
55x or DSN instead of MUST MDN:

If I can appeal to your sense of architectural purity, it is 
inappropriate for a client to generate a non-delivery report, because 
it's not the client's job to issue such things.  I believe this was the 
argument put forth at the time against either 55x or generating a DSN. 
(I believe one version of the document required either 55x or generation 
of a DSN, and it didn't make it.)

Or, if I can appeal to your sense of practicality, there is no 
performance reason for a client to generate a non-delivery report.  Once 
the final MTA has accepted responsibility for the message, it has to 
write to disk and do a lot of work that you're presumably trying to 
avoid.  If it generates a DSN or an MDN, it doesn't matter, it's not 
going to prevent the spammer from spamming you in the future.

The behavior in the RFC was, in fact, the only choice we could have 
made.  We did talk about it while the document was under development, 
but it wasn't a reasonable choice.

The advantage of "reject" is it allows this weaker behavior which is 
widely implementable.  Making refuse separate allows the best of both 
worlds.  I'm sorry the verbs aren't consistent, but there's nothing we 
could have done.  The damage to consistency was done a long time ago 
with these terms.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EMw5Qp072737; Fri, 14 May 2004 15:58:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EMw5Pp072736; Fri, 14 May 2004 15:58:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4EMw4fI072729 for <[e-mail]>; Fri, 14 May 2004 15:58:05 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 22979 invoked from network); 14 May 2004 18:58:07 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 14 May 2004 18:58:07 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 908 invoked by uid 101); 14 May 2004 18:58:07 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 14 May 2004 18:58:07 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 13, 2004 at 01:37:19PM +0200, Michael Haardt wrote:
  [ skipping much that I have no quibble with ]

>  
> > (That's not as thorny as self-modifying grammar of course.. a la
> > typedef in C)
> 
> Types are usually checked at the semantic layer, probably for just that
> reason.

True, type checking is a semantic issue (some of which can be done at
parse time), but that isn't what I was getting at.  "typedef" modifies
the language syntax.  Consider:

/*1*/    typedef unsigned int  myint;
/*2*/    myint x = 3;

Without line 1, line 2 has an invalid syntax.  This isn't a
semantic typechecking problem, it's strictly a syntax issue.
This is different from, say, function prototypes, because a function
reference whose only error is that it doesn't match a prototype
is still syntactically correct.

Relatedly, the SIEVE RFC doesn't really specify whether "require"
enables an extension syntax or merely use of an extension at run time.
For example, given this complete script:

    if false { fileinto "impossible"; }
    else { keep; }

Is that a syntax error because it is missing the "require"?  (I can't
imagine that it is: my own implementation says it's not.  But that
would be a lesser example of a self-modifying grammar.)



> Exists Test With Empty List Of Headers
> 
> The "exists" test only suceeds if all specified headers exist.  RFC 3028
> does not explicitly specify what happens on an empty list of headers.
> This implementation evaluates that condition with true, interpreting
> the RFC in a strict sense.

How would you arrange to get an empty set of headers?


> That's why I suggest to handle syntactic issues at the syntactic level:
> Easy to use formal specifications exist, that don't leave anything
> to guess, plus it makes an implementation easier.

Still no argument there :-)

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ELg4rq066242; Fri, 14 May 2004 14:42:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ELg4GD066241; Fri, 14 May 2004 14:42:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ELg2ZR066230 for <[e-mail]>; Fri, 14 May 2004 14:42:03 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: gS69S4u7reOec2x0ZL4tgQ 1084570922
Received: from elvey.fastmail.fm (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 26562B789D6; Fri, 14 May 2004 17:42:02 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 14 May 2004 14:42:00 -0700
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: [spamtools] Refuse for IMAP Sieve
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 5/14/2004 3:05 AM, Alex van den Bogaerdt sent forth electrons to convey:

>On Thu, May 13, 2004 at 12:54:15PM -0700, Matthew Elvey (FM) wrote:
>
>  
>
>>Hi. Just thought I'd let folks know that the IETF has published an
>>Internet Draft to reduce blowback from Sieve-generated bounces.
>>http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt
>>Feedback (here or, preferably, on the ietf-mta-filters list) appreciated.
>>
>>Abstract
>>
>>   With "refuse", Sieve gains the ability to simply not accept an
>>   email during the SMTP transaction (instead of accepting it and then
>>   sending an MDN [MDN] back to the alleged sender using "reject").
>>   ...
>>   With "reject", MDNs contribute to
>>   the flood of Joe-job spam to victims of Joe-jobs; SMTP level
>>   refusals usually don't.  So "refuse" provides users the latter
>>   method to handle unwanted email.
>>
>>Sieve [RFC3028] is a language for filtering mail at the time of final
>>delivery.
>>    
>>
>
>Argh.
>
>There was not enough confusion yet, so let's redefine "reject" and use
>"refuse" for what others call reject?
>
>Why not simply repair the rfc and let reject do what it should do: give
>a 55x error on delivery.
>  
>
That was discussed on the list.  It was a tough call. 
(Points made by cyrus, kristin, ned, myself, around 13-25Feb04.)
Perhaps I gave posts from Ned (then Area Director, I think) too much 
weight, but I think not.
Thanks for the feedback. 
(Crossposting to make the mta-filters list aware of the feedback.  
Followups to one list, please.)

>Alex
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DDe365022130; Thu, 13 May 2004 06:40:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4DDe3Vv022129; Thu, 13 May 2004 06:40:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DDe2S6022123 for <[e-mail]>; Thu, 13 May 2004 06:40:03 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4DDcm1F005615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2004 09:38:49 -0400
Date: Thu, 13 May 2004 09:40:00 -0400
From: Cyrus Daboo <[e-mail]>
To: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Michael,

--On Thursday, May 13, 2004 1:37 PM +0200 Michael Haardt 
<[e-mail]> wrote:

> How about another ABNF extension, e.g.
> /=?
>
>   rule             =  a
>   rule             /= b

ABNF (RFC 2234) already has that - see section 3.3 in that document. The 
syntax is a little different from what you have above:

    rule            =/ b

The one thing that is missing from ABNF in my opinion is an operator to 
specify a list of items that can appear in any order. Tagged arguments in 
SIEVE is a good example of where that would be useful - also iCal (RFC 
2445) where properties within components can occur in any order.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DBbMXN011144; Thu, 13 May 2004 04:37:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4DBbMD2011143; Thu, 13 May 2004 04:37:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DBbKNQ011134 for <[e-mail]>; Thu, 13 May 2004 04:37:21 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with asmtp (Exim 4.33) id 1BOEWd-0004gm-BO for [e-mail]; Thu, 13 May 2004 13:37:19 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33 #3) id 1BOEWd-0000EV-9z for [e-mail]; Thu, 13 May 2004 13:37:19 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.34 #1) id 1BOEWd-0001We-0p for [e-mail]; Thu, 13 May 2004 13:37:19 +0200
To: [e-mail]
Subject: Re: envelope test syntax?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 13 May 2004 13:37:19 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I assume you're referring to the confusing text that includes things
> like "else" being a separate command, and "'elsif' must only follow
> 'if'" which is obviously incorrect.  OTOH I think the incorrectness
> there is not due to the documentation method, but in errors in the
> description.  i.e. the description could be corrected.  

IMHO, the documentation method asks for such problems.  When I first
read the paragraph, it sounded a little odd, but I probably assumed
that it was meant to describe the common "if elsif else" structure.

Later, when I worked on code and tried to find the grammar for the
structure, the mistake became obvious.

> > The ABNF
> > 
> >   if-command       = "if" test block *( "elsif" test block ) [ else block ]
> > 
> > is short and (hopefully:) correct.
>
>     closer when "else" is quoted :-)

Oops! Thanks for spotting that, the next Exim release will have a
fixed version.

> However there's still the issue of extensions: the syntax varies
> depending on what extensions are enabled.  Each extension can probably
> be specified via BNF, but how would you address optional grammar (i.e.
> as distinct from grammar that includes optional elements)?

Now I see your point: Each implementation contains the base grammar
plus all extensions, but an implementation that contains new tests
had to add the "test" rule.  How about another ABNF extension, e.g.
/=?

  rule             =  a
  rule             /= b

is equivalent to

  rule             =  a / b

The RFC would then contain:

  test             =  address-test / allof-test / anyof-test / exists-test
                      / false-test / true-test / header-test / not-test
                      / size-test / envelope-test

and extensions could specify:

  test             /= extension-test

If you took the rules from the RFC plus the rules for all extensions,
you had a correct grammar for the implementation.
 
> (That's not as thorny as self-modifying grammar of course.. a la
> typedef in C)

Types are usually checked at the semantic layer, probably for just that
reason.  Any set of extensions plus the base grammar yields a constant
grammar, so no problem there.  The generic Sieve grammar generates a
larger language than any implementation grammar, but it is only used to
ensure that extensions fit into Sieve.

> Do you think that SIEVE is unimplementable based on RFC3028?

I had to ask Tim several times for details.  "Unimplementable" is too
strong; I think of it as "incomplete in minor aspects".  Two examples
from the same README:

----------
Strings Containing Header Names

RFC 3028 does not specify what happens if a string denoting a header
field does not contain a valid header name, e.g. it contains a colon.
This implementation generates an error instead of ignoring the header
field in order to ease script debugging, which fits in the common
picture of Sieve.


Exists Test With Empty List Of Headers

The "exists" test only suceeds if all specified headers exist.  RFC 3028
does not explicitly specify what happens on an empty list of headers.
This implementation evaluates that condition with true, interpreting
the RFC in a strict sense.
----------

The above can but guessed by common sense, but a specification should not
leave anything to guess.  These things are clearly semantic, so again
the RFC shows how hard semantics are to describe with natural language
without leaving things out.

That's why I suggest to handle syntactic issues at the syntactic level:
Easy to use formal specifications exist, that don't leave anything
to guess, plus it makes an implementation easier.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D0kK4H074957; Wed, 12 May 2004 17:46:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4D0kKhN074956; Wed, 12 May 2004 17:46:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D0kJV0074948 for <[e-mail]>; Wed, 12 May 2004 17:46:19 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: 7nwsRwPRF5zb/Q0JTJvUqg 1084409054
Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id BBD33B6257C; Wed, 12 May 2004 20:44:13 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 17:44:11 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Subject: Re: envelope test syntax?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 5/12/2004 12:50 AM, Tim Showalter sent forth electrons to convey:

>
> Cyrus Daboo wrote:
>
>> That said, I have wondered for a while whether it would not be better 
>> to have a formal ABNF syntax for the commands and tests. Would that 
>> actually be possible or useful?
>
I wrote some "Tips for reading the RFC 
<http://www.ietf.org/rfc/rfc3028.txt?number=3028>:"
http://www.elvey.com/it/sieve/#_Toc9582052
some time ago (apologies for the sucky formatting; I redid the page and 
lost the new version somehow became demotivated).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D0UiMu073918; Wed, 12 May 2004 17:30:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4D0UiLt073917; Wed, 12 May 2004 17:30:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D0UhbW073911 for <[e-mail]>; Wed, 12 May 2004 17:30:43 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: yvIujbMgAnw+ZyyAz+vbHw 1084408233
Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 1BE05B61AD4; Wed, 12 May 2004 20:30:31 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 17:30:30 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew Carpenter <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 5/10/2004 6:05 AM, Matthew Carpenter sent forth electrons to convey:

> Is this a good place to post a sieve script 

Not really.
http://wiki.fastmail.fm/wiki/index.php/SieveExamples has some info, 
including a link to a page I set up.
Also your posting etiquette is poor - what does this have to do with 
"Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. 
refuse, and older ones, like vacation(!), regex, imapflags." ... ?  
http://www.albany.edu/its/accounts_email/websieve/ or 
http://www.emailaddresses.com/forum/ could be useful, but a mailing list 
specifically for sieve end-users is lacking. 

> that is failing or would that be too implementation-specific?  I'm 
> trying to learn Sieve, coming from a Procmail background, and using 
> websieve as a user interface.  I have a few scripts which seem to 
> simply not execute, and it seems to be related to what WebSieve calls 
> "Continue processing rules".  It is running on a Cyrus IMAP server
>
> Thanks,
> Matt
>
<unrelated post snipped>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CHBgSN038691; Wed, 12 May 2004 10:11:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CHBgtp038690; Wed, 12 May 2004 10:11:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4CHBdHs038681 for <[e-mail]>; Wed, 12 May 2004 10:11:39 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 11459 invoked from network); 12 May 2004 13:11:29 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 12 May 2004 13:11:38 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 29759 invoked by uid 101); 12 May 2004 13:11:27 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 12 May 2004 13:11:27 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 12, 2004 at 11:35:22AM +0200, Michael Haardt wrote:
> 
> There is no reason not to specify tests and actions at the syntax layer
> as subsets of the language generated by the generic syntax.  That way
> you move their syntax from the semantics analysis back to the syntax
> analysis, where it belongs to.  It is easier to understand a formal
> syntax definition than a formal semantic definition, and you see what
> you get from the current approach when looking at the "if" command.
> The current section describing is it rather long, but not correct.

I assume you're referring to the confusing text that includes things
like "else" being a separate command, and "'elsif' must only follow
'if'" which is obviously incorrect.  OTOH I think the incorrectness
there is not due to the documentation method, but in errors in the
description.  i.e. the description could be corrected.  

> 
> The ABNF
> 
>   if-command       = "if" test block *( "elsif" test block ) [ else block ]
> 
> is short and (hopefully:) correct.

    closer when "else" is quoted :-)


>  An ABNF extension for tagged
> commands would solve the current specification problem.  From
> exim-4.33/doc/README.SIEVE:
> 
> ----------
> The grammar is specified in ABNF with an extension to describe tagged
> arguments that can be reordered: { } denotes a sequence of symbols that
> may appear in any order.  Example:
> 
>   start -> { a b c }
> 
> is equivalent to:
> 
>   start -> ( a b c ) / ( a c b ) / ( b a c ) / ( b c a ) / ( c a b ) / ( c b a )
> 
> [...]
> 
>   address-test     = "address" { [address-part] [comparator] [match-type] }
>                      string-list string-list

That's all very good and very clear.  I'm not arguing against it.
However there's still the issue of extensions: the syntax varies
depending on what extensions are enabled.  Each extension can probably
be specified via BNF, but how would you address optional grammar (i.e.
as distinct from grammar that includes optional elements)?  Particulary
when the syntax doesn't change when a capability is enabled, but it
depends on whether a capability is supported (whether enabled or not).

(That's not as thorny as self-modifying grammar of course.. a la
typedef in C)



> Sieve is really great, but it should not be neccessary to write
> an addition to the RFC, that specifies a bunch of things, before
> implementing it.

Do you think that SIEVE is unimplementable based on RFC3028?  I won't
disagree that there are narrative errors, but I don't think there is
anything that truly isn't understandable.  Again I'm not arguing against
a formal syntax specification: I'm just wondering about the claim that
the RFC is unusable.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CGbMBs036275; Wed, 12 May 2004 09:37:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CGbMhl036274; Wed, 12 May 2004 09:37:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4CGbLHX036268 for <[e-mail]>; Wed, 12 May 2004 09:37:21 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20377 invoked from network); 12 May 2004 12:36:58 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 12 May 2004 12:37:24 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 16532 invoked by uid 101); 12 May 2004 12:36:57 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 12 May 2004 12:36:57 -0400
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 12, 2004 at 12:30:38AM -0400, Cyrus Daboo wrote:
> Hi [e-mail],
> 
> --On Tuesday, May 11, 2004 9:01 PM -0700 [e-mail] wrote:
> 
> >>OTOH perhaps I am missing the point :-)
> >
> >Me too, perhaps...
> 
> It turns out that I fooled myself into believing the SIEVE implementation I 
> am using was treating the tagged arguments as order dependent in envelope. 
> In actual fact there is a configuration issue with the local mailer that 
> means envelope is getting the local part of the actual RCPT TO's and not 
> the domain and as a result the test is failing.

BTW I sent you an entry the other day for the 'sieve implementations'
page, in response to your note to the list.  Not trying to nag, but
I'm wondering if the message got to you.  OK, maybe I'm trying to nag. 

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEM4P7025725; Wed, 12 May 2004 07:22:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CEM4rY025724; Wed, 12 May 2004 07:22:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEM47b025717 for <[e-mail]>; Wed, 12 May 2004 07:22:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 12 May 2004 07:22:03 -0700 (PDT)
Date: Wed, 12 May 2004 07:18:18 -0700 (PDT)
From: [e-mail]
Subject: Re: envelope test syntax?
In-reply-to: "Your message dated Wed, 12 May 2004 00:50:21 -0700" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Virus-test: FALSE
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Cyrus Daboo wrote:

> > That said, I have wondered for a while whether it would not be better to
> > have a formal ABNF syntax for the commands and tests. Would that
> > actually be possible or useful?

> I don't think so.  Programming languages are typically specified as
> Sieve is, in terms of tokens, a formal grammar, and a standard library.

I concur. The problem with fully specifying ABNF for
commands and tests is that it tends to imply that's all there is, which
then clashes with future extensions.

>   We could do what you suggest--in fact, the early drafts did so.  It
> was not very readable or particularly helpful.

We tried this with MIME as well - we had ABNF for the initial
set of content-types. It did much more harm than good.

> Extensions would have to
> extend the grammar, and that's error-prone and not at all in line with
> what programming languages usually do.  Worse, you wouldn't be able to
> parse the general language without knowing all the extensions a
> particular script used.

Bingo.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEAurw024965; Wed, 12 May 2004 07:10:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CEAumk024964; Wed, 12 May 2004 07:10:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bigblock1.eisgr.com ([167.23.241.182]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEAsOX024954 for <[e-mail]>; Wed, 12 May 2004 07:10:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by bigblock1.eisgr.com (bigmail) with ESMTP id D104928541; Mon, 10 May 2004 09:05:40 -0400 (EDT)
Received: from  by localhost (amavisd-new, port ) id XX8UIU11; Mon, 10 May 2004 09:05:37 -0400 (EDT)
Received: from eisgr.com (mgcxp.intranet.local [172.16.21.21]) by bigblock1.eisgr.com (bigmail) with ESMTP id F39BB2820D; Mon, 10 May 2004 09:05:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 10 May 2004 09:05:33 -0400
From: Matthew Carpenter <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at eisgr.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is this a good place to post a sieve script that is failing or would 
that be too implementation-specific?  I'm trying to learn Sieve, coming 
from a Procmail background, and using websieve as a user interface.  I 
have a few scripts which seem to simply not execute, and it seems to be 
related to what WebSieve calls "Continue processing rules".  It is 
running on a Cyrus IMAP server

Thanks,
Matt

Matthew Elvey wrote:

>
>
>
> On 4/29/04 8:08 PM, Matthew Elvey (FM) sent forth electrons to convey:
>
>>
>> Wow, things have been quiet on this list.
>> Anyone considering implementing draft-elvey-refuse-sieve-01.txt?
>
>
> :(
>
>> I just noticed draft-daboo-sieve-spamtest-01.txt became an RFC:
>> http://www.faqs.org/rfcs/rfc3685.html - good, because the draft had 
>> expired, and someone wants to reference it in another doc not as a 
>> work-in-progress.
>> I guess the Sieve homepage at cyrussoft is sorely out of date (I 
>> emailed the maintainer (sieve%cyrusoft.com 
>> <mailto:[e-mail]>) a while back and didn't hear back - see 
>> below.)
>
>
> Cyrus/CyruSoft has updated their sieve page considerably - looks good 
> now.
>
>> http://www.iana.org/assignments/sieve-extensions is presumably an 
>> up-to-date listing of SIEVE extensions that have reached RFC status.
>> RFC 3598 is the subaddress extension,
>> RFC 3431 is the relational test,
>>
>> There aren't IANA assignments for the extensions vacation, regex, or 
>> imapflags.
>> Are their authors interested in progressing them to RFC status or 
>> getting IANA assignments?  If I don't hear back, I'll take this up.
>
>
> I created a page to track what Sieve implementations support what 
> extensions here:
> http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix.  
> Edits, links welcome (DIY-Do It Yourself; it's a wiki).
>
>>
>> Any comments before I email iana%iana.org with the RFC # for 
>> spamtest, and a reservation for "refuse"?
>
>
> Emailed.
>
>>
>> On 4/14/2004 9:41 PM, Matthew Elvey sent forth electrons to 
>> sieve%cyrusoft.com to convey:
>>
>>> Hi.  I was wondering if you'd add a list of links to sieve 
>>> extensions.  None are officially beyond the I-D stage yet [wrong], 
>>> but they are often at the <multiple implementations exist> stage.  
>>> If you'd like to, e.g. link to 
>>> http://www.cyrusoft.com/sieve/#implementations, I'll put up a page 
>>> there.
>>> Hope you guys push Sieve along in the standardization process too, 
>>> or if you're not doing that, make changes to improve it, like the 
>>> one I suggest in my I-D for the 'refuse' extension.
>>
>>
> No comment?
>
> notes:
>
> vacation, per
>
> draft-showalter-sieve-vacation-05.txt
>
>
>  imapflags - I-D still valid, but IANA section is missing.
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9ZWfr000644; Wed, 12 May 2004 02:35:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C9ZW0N000643; Wed, 12 May 2004 02:35:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9ZU1O000601 for <[e-mail]>; Wed, 12 May 2004 02:35:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with asmtp (Exim 4.33) id 1BNq94-0007hR-P5 for [e-mail]; Wed, 12 May 2004 11:35:22 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.33 #3) id 1BNq94-0000v3-NO for [e-mail]; Wed, 12 May 2004 11:35:22 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.33 #3) id 1BNq94-0004wd-4i for [e-mail]; Wed, 12 May 2004 11:35:22 +0200
To: [e-mail]
Subject: Re: envelope test syntax?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 12 May 2004 11:35:22 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > That said, I have wondered for a while whether it would not be better to 
> > have a formal ABNF syntax for the commands and tests. Would that 
> > actually be possible or useful?
>
> I don't think so.  Programming languages are typically specified as 
> Sieve is, in terms of tokens, a formal grammar, and a standard library. 

Not to forget semantics.  Sieve (as defined by the RFC) uses a generic
syntax, and specifies the semantics for particularly formed words.
Despite labelled "Syntax", e.g. tests are really describing semantics.
It is common practice to define semantics very unformal and even with
natural language, so does the RFC.

Despite the RFC confusing syntax and semantics of the Sieve language,
the concept is easy to understand, but it asks for specification errors.

>   We could do what you suggest--in fact, the early drafts did so.  It 
> was not very readable or particularly helpful.  Extensions would have to 
> extend the grammar, and that's error-prone and not at all in line with 
> what programming languages usually do.  Worse, you wouldn't be able to 
> parse the general language without knowing all the extensions a 
> particular script used.

The generic syntax is fine as it is, but it is not enough.

There is no reason not to specify tests and actions at the syntax layer
as subsets of the language generated by the generic syntax.  That way
you move their syntax from the semantics analysis back to the syntax
analysis, where it belongs to.  It is easier to understand a formal
syntax definition than a formal semantic definition, and you see what
you get from the current approach when looking at the "if" command.
The current section describing is it rather long, but not correct.

The ABNF

  if-command       = "if" test block *( "elsif" test block ) [ else block ]

is short and (hopefully:) correct.  An ABNF extension for tagged
commands would solve the current specification problem.  From
exim-4.33/doc/README.SIEVE:

----------
The grammar is specified in ABNF with an extension to describe tagged
arguments that can be reordered: { } denotes a sequence of symbols that
may appear in any order.  Example:

  start -> { a b c }

is equivalent to:

  start -> ( a b c ) / ( a c b ) / ( b a c ) / ( b c a ) / ( c a b ) / ( c b a )

[...]

  address-test     = "address" { [address-part] [comparator] [match-type] }
                     string-list string-list
----------

Sieve is really great, but it should not be neccessary to write
an addition to the RFC, that specifies a bunch of things, before
implementing it.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C7oCgZ061575; Wed, 12 May 2004 00:50:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C7oCSw061574; Wed, 12 May 2004 00:50:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eddie.psaux.com (dsl093-166-101.sfo2.dsl.speakeasy.net [66.93.166.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C7o9mh061528 for <[e-mail]>; Wed, 12 May 2004 00:50:11 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (krikkit.psaux.com [66.92.250.136]) by eddie.psaux.com (Postfix) with ESMTP id 6843B23DB5; Wed, 12 May 2004 00:50:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 00:50:21 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Subject: Re: envelope test syntax?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

> That said, I have wondered for a while whether it would not be better to 
> have a formal ABNF syntax for the commands and tests. Would that 
> actually be possible or useful?

I don't think so.  Programming languages are typically specified as 
Sieve is, in terms of tokens, a formal grammar, and a standard library. 
  We could do what you suggest--in fact, the early drafts did so.  It 
was not very readable or particularly helpful.  Extensions would have to 
extend the grammar, and that's error-prone and not at all in line with 
what programming languages usually do.  Worse, you wouldn't be able to 
parse the general language without knowing all the extensions a 
particular script used.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C4Ub0i092648; Tue, 11 May 2004 21:30:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C4UbgS092647; Tue, 11 May 2004 21:30:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C4UaYo092641 for <[e-mail]>; Tue, 11 May 2004 21:30:37 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (pool-68-162-174-101.pitt.east.verizon.net [68.162.174.101]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4C4Te5J001062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2004 00:29:42 -0400
Date: Wed, 12 May 2004 00:30:38 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], "Mark E. Mallett" <[e-mail]>
cc: [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi [e-mail],

--On Tuesday, May 11, 2004 9:01 PM -0700 [e-mail] wrote:

>> OTOH perhaps I am missing the point :-)
>
> Me too, perhaps...

It turns out that I fooled myself into believing the SIEVE implementation I 
am using was treating the tagged arguments as order dependent in envelope. 
In actual fact there is a configuration issue with the local mailer that 
means envelope is getting the local part of the actual RCPT TO's and not 
the domain and as a result the test is failing.

That said, I have wondered for a while whether it would not be better to 
have a formal ABNF syntax for the commands and tests. Would that actually 
be possible or useful?

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C42UpM090720; Tue, 11 May 2004 21:02:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C42UTJ090719; Tue, 11 May 2004 21:02:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C42TPp090712 for <[e-mail]>; Tue, 11 May 2004 21:02:29 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 11 May 2004 21:02:33 -0700 (PDT)
Date: Tue, 11 May 2004 21:01:57 -0700 (PDT)
From: [e-mail]
Subject: Re: envelope test syntax?
In-reply-to: "Your message dated Tue, 11 May 2004 18:43:02 -0400" <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Tue, May 11, 2004 at 06:09:26PM -0400, Cyrus Daboo wrote:
> > The envelope test syntax in RFC3028 is given as:
> >
> >   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
> >             <envelope-part: string-list> <key-list: string-list>
> >
> > But that is different than the address test syntax:
> >
> >   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
> >             <header-list: string-list> <key-list: string-list>
> >
> > [COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a tests
> > that are so similar.
> >
> > The example for the envelope test uses the same syntax as the address test.
> >
> > What is the correct syntax for the envelope test? Either the example is
> > wrong, or the syntax definition is wrong.

> Tagged arguments can be given in any order; my impression was that
> the variations in those paragraphs simply illustrated that fact.

That was my interpretation as well.

>   From 2.6.2:

>       Tagged arguments must appear before positional arguments, but
>       they may appear in any order with other tagged arguments.  For
>       simplicity of the specification, this is not expressed in the
>       syntax definitions with commands, but they still may be
>       reordered arbitrarily provided they appear before positional
>       arguments.  Tagged arguments may be mixed with optional
>       arguments.

>   and 2.6.3:

>       Optional arguments are exactly like tagged arguments except that
>       they may be left out, in which case a default value is implied.

> OTOH perhaps I am missing the point :-)

Me too, perhaps...

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0QNsm075408; Tue, 11 May 2004 17:26:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C0QNln075407; Tue, 11 May 2004 17:26:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0QKnh075399 for <[e-mail]>; Tue, 11 May 2004 17:26:23 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (adsl-64-164-137-106.dsl.snfc21.pacbell.net [64.164.137.106]) by mail.apptran.com (8.12.8/8.12.8) with ESMTP id i4C0QLV3002206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2004 17:26:23 -0700
Message-ID: <[e-mail]>
Date: Tue, 11 May 2004 17:26:21 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: [e-mail]
Subject: Re: envelope test syntax?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:
> 
>   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>             <envelope-part: string-list> <key-list: string-list>

>   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
>             <header-list: string-list> <key-list: string-list>
> 
> [COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a 
> tests that are so similar.

This is a slight oversight.  I never noticed it because arguments may 
appear in any order.  (2.6.2 says this for tagged arguments; 2.6.3 says 
optional arguments are exactly like tagged arguments.)  Obviously this 
was not written by cut-and-paste.

I'm pretty sure I can convince myself that this is what it says, but 
then, I can probably do that for a lot of my mistakes.

I'll try to improve this part in the future.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BMh7LH069441; Tue, 11 May 2004 15:43:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BMh7mY069440; Tue, 11 May 2004 15:43:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4BMh68E069431 for <[e-mail]>; Tue, 11 May 2004 15:43:06 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 8589 invoked from network); 11 May 2004 18:43:02 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 11 May 2004 18:43:08 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 14905 invoked by uid 101); 11 May 2004 18:43:02 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 11 May 2004 18:43:02 -0400
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Subject: Re: envelope test syntax?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 11, 2004 at 06:09:26PM -0400, Cyrus Daboo wrote:
> The envelope test syntax in RFC3028 is given as:
> 
>   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>             <envelope-part: string-list> <key-list: string-list>
> 
> But that is different than the address test syntax:
> 
>   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
>             <header-list: string-list> <key-list: string-list>
> 
> [COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a tests 
> that are so similar.
> 
> The example for the envelope test uses the same syntax as the address test.
> 
> What is the correct syntax for the envelope test? Either the example is 
> wrong, or the syntax definition is wrong.

Tagged arguments can be given in any order; my impression was that
the variations in those paragraphs simply illustrated that fact.

  From 2.6.2:

      Tagged arguments must appear before positional arguments, but
      they may appear in any order with other tagged arguments.  For
      simplicity of the specification, this is not expressed in the
      syntax definitions with commands, but they still may be
      reordered arbitrarily provided they appear before positional
      arguments.  Tagged arguments may be mixed with optional
      arguments.

  and 2.6.3:

      Optional arguments are exactly like tagged arguments except that
      they may be left out, in which case a default value is implied.

OTOH perhaps I am missing the point :-)

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BM9ODb066897; Tue, 11 May 2004 15:09:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BM9OWQ066896; Tue, 11 May 2004 15:09:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BM9Ncc066890 for <[e-mail]>; Tue, 11 May 2004 15:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4BM8S22025997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 May 2004 18:08:30 -0400
Date: Tue, 11 May 2004 18:09:26 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: envelope test syntax?
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The envelope test syntax in RFC3028 is given as:

   Syntax:   envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <envelope-part: string-list> <key-list: string-list>

But that is different than the address test syntax:

   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
             <header-list: string-list> <key-list: string-list>

[COMPARATOR] and [ADDRESS-PART] being switched, which seems odd for a tests 
that are so similar.

The example for the envelope test uses the same syntax as the address test.

What is the correct syntax for the envelope test? Either the example is 
wrong, or the syntax definition is wrong.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i48MpO4K049354; Sat, 8 May 2004 15:51:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i48MpOJj049353; Sat, 8 May 2004 15:51:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i48MpNIR049345 for <[e-mail]>; Sat, 8 May 2004 15:51:23 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: LR90C+bhYm4Ya3pmIH1DOg 1084056389
Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 633F5B2E71A; Sat,  8 May 2004 18:46:29 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 08 May 2004 15:46:34 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 4/29/04 8:08 PM, Matthew Elvey (FM) sent forth electrons to convey:

>
> Wow, things have been quiet on this list.
> Anyone considering implementing draft-elvey-refuse-sieve-01.txt?

:(

> I just noticed draft-daboo-sieve-spamtest-01.txt became an RFC:
> http://www.faqs.org/rfcs/rfc3685.html - good, because the draft had 
> expired, and someone wants to reference it in another doc not as a 
> work-in-progress.
> I guess the Sieve homepage at cyrussoft is sorely out of date (I 
> emailed the maintainer (sieve%cyrusoft.com 
> <mailto:[e-mail]>) a while back and didn't hear back - see 
> below.)

Cyrus/CyruSoft has updated their sieve page considerably - looks good now.

> http://www.iana.org/assignments/sieve-extensions is presumably an 
> up-to-date listing of SIEVE extensions that have reached RFC status.
> RFC 3598 is the subaddress extension,
> RFC 3431 is the relational test,
>
> There aren't IANA assignments for the extensions vacation, regex, or 
> imapflags.
> Are their authors interested in progressing them to RFC status or 
> getting IANA assignments?  If I don't hear back, I'll take this up.

I created a page to track what Sieve implementations support what 
extensions here:
http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix.  
Edits, links welcome (DIY-Do It Yourself; it's a wiki).

>
> Any comments before I email iana%iana.org with the RFC # for spamtest, 
> and a reservation for "refuse"?

Emailed.

>
> On 4/14/2004 9:41 PM, Matthew Elvey sent forth electrons to 
> sieve%cyrusoft.com to convey:
>
>> Hi.  I was wondering if you'd add a list of links to sieve 
>> extensions.  None are officially beyond the I-D stage yet [wrong], 
>> but they are often at the <multiple implementations exist> stage.  If 
>> you'd like to, e.g. link to 
>> http://www.cyrusoft.com/sieve/#implementations, I'll put up a page 
>> there.
>> Hope you guys push Sieve along in the standardization process too, or 
>> if you're not doing that, make changes to improve it, like the one I 
>> suggest in my I-D for the 'refuse' extension.
>
No comment?

notes:

vacation, per

draft-showalter-sieve-vacation-05.txt

 
  imapflags - I-D still valid, but IANA section is missing.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Fu6Wg079488; Thu, 6 May 2004 08:56:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46Fu6pj079487; Thu, 6 May 2004 08:56:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Fu5OJ079481 for <[e-mail]>; Thu, 6 May 2004 08:56:06 -0700 (PDT) (envelope-from [e-mail])
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i46Ftwme005963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 May 2004 11:55:59 -0400
Date: Thu, 06 May 2004 11:56:58 -0400
From: Cyrus Daboo <[e-mail]>
To: Alexandros Vellis <[e-mail]>, [e-mail]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments   (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
Message-ID: <[e-mail]>
In-Reply-To: <41050.195.134.100.40.1083858061.squirrel@195.134.100.40>
References: <[e-mail]>    <[e-mail]> <41050.195.134.100.40.1083858061.squirrel@195.134.100.40>
X-Mailer: Mulberry/3.2.0a1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Alexandros,

--On Thursday, May 06, 2004 6:41 PM +0300 Alexandros Vellis 
<[e-mail]> wrote:

|> I guess the Sieve homepage at cyrussoft is sorely out of date (I emailed
|> the maintainer (sieve%cyrusoft.com <mailto:[e-mail]>) a while
|> back and didn't hear back - see below.)
|
| On a side note, things have been a bit more active active in programs
| starting to support SIEVE, such as DBMail and Exim4. When I submitted my
| humble 'avelsieve' to get on Cyrussoft's implementations list, I didn't
| hear back either. That list can probably do with some of the new software
| that supports SIEVE.

Please send any comments/suggestions for our SIEVE site direct to me at 
<mailto:[e-mail]>. Ironically, the email address for that site 
gets more spam than any of our others and so legitimate messages may get 
filtered out accidentally. I will try and make sure the documents page is 
up to date with the latest drafts etc

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FfAOP078238; Thu, 6 May 2004 08:41:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FfAtE078237; Thu, 6 May 2004 08:41:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Ff7Wb078197 for <[e-mail]>; Thu, 6 May 2004 08:41:10 -0700 (PDT) (envelope-from [e-mail])
Received: from webmail.noc.uoa.gr (webmail.noc.uoa.gr [195.134.100.73]) by msa.uoa.gr (8.12.11/8.12.11) with SMTP id i46Ff1xe016836 for <[e-mail]>; Thu, 6 May 2004 18:41:01 +0300 (EEST)
Received: from 195.134.100.40 (SquirrelMail authenticated user avel); by webmail.uoa.gr with HTTP; Thu, 6 May 2004 18:41:01 +0300 (EEST)
Message-ID: <41050.195.134.100.40.1083858061.squirrel@195.134.100.40>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 6 May 2004 18:41:01 +0300 (EEST)
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments  (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
From: "Alexandros Vellis" <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.2 [email.uoa.gr]
X-Mailer: SquirrelMail/1.4.2 [email.uoa.gr]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-7
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matthew Elvey (FM) wrote:

> I guess the Sieve homepage at cyrussoft is sorely out of date (I emailed
> the maintainer (sieve%cyrusoft.com <mailto:[e-mail]>) a while
> back and didn't hear back - see below.)

On a side note, things have been a bit more active active in programs
starting to support SIEVE, such as DBMail and Exim4. When I submitted my
humble 'avelsieve' to get on Cyrussoft's implementations list, I didn't
hear back either. That list can probably do with some of the new software
that supports SIEVE.

-- 
Alexandros Vellis       University of Athens
[e-mail]         Network Operations Centre
Public Key: http://www.noc.uoa.gr/~avel/gpgkey.asc