Subject: Re: envelope test syntax?

From: Michael Haardt <[email-masked]>
Date: Wed, 26 May 2004 12:22:59 +0200

> > > 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

To: [email-masked]
Subject: Re: envelope test syntax?
From: Michael Haardt <[email-masked]>
Date: Wed, 26 May 2004 12:22:59 +0200
Sender: [email-masked]

> > > 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

Date: Wed, 19 May 2004 17:14:29 -0700
From: Tim Showalter <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 19 May 2004 19:49:36 -0400
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: envelope test syntax?
From: Michael Haardt <[email-masked]>
Date: Wed, 19 May 2004 16:35:49 +0200
Sender: [email-masked]

> 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

From: <[email-masked]>
To: <[email-masked]>
Subject: forwarding problem
Date: Wed, 19 May 2004 10:37:34 +0200
Sender: [email-masked]

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

Date: Tue, 18 May 2004 13:31:47 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: allow from only one IP
Sender: [email-masked]

On 5/18/2004 5:49 AM, [email-masked] 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.

From: <[email-masked]>
To: <[email-masked]>
Subject: allow from only one IP
Date: Tue, 18 May 2004 14:49:24 +0200
Sender: [email-masked]

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

Date: Sun, 16 May 2004 16:08:51 -0700
From: Tim Showalter <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [spamtools] Refuse for IMAP Sieve
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 14 May 2004 18:58:07 -0400
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

Date: Fri, 14 May 2004 14:42:00 -0700
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spamtools] Refuse for IMAP Sieve
Sender: [email-masked]

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

Date: Thu, 13 May 2004 09:40:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

Hi Michael,

--On Thursday, May 13, 2004 1:37 PM +0200 Michael Haardt 
<[email-masked]> 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

To: [email-masked]
Subject: Re: envelope test syntax?
From: Michael Haardt <[email-masked]>
Date: Thu, 13 May 2004 13:37:19 +0200
Sender: [email-masked]

> 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

Date: Wed, 12 May 2004 17:44:11 -0700
From: Matthew Elvey <[email-masked]>
To: Tim Showalter <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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).

Date: Wed, 12 May 2004 17:30:30 -0700
From: Matthew Elvey <[email-masked]>
To: Matthew Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
Sender: [email-masked]

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>

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 12 May 2004 13:11:27 -0400
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 12 May 2004 12:36:57 -0400
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

On Wed, May 12, 2004 at 12:30:38AM -0400, Cyrus Daboo wrote:
> Hi [email-masked],
> 
> --On Tuesday, May 11, 2004 9:01 PM -0700 [email-masked] 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

Date: Wed, 12 May 2004 07:18:18 -0700 (PDT)
From: [email-masked]
Subject: Re: envelope test syntax?
To: Tim Showalter <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Virus-test: FALSE
Sender: [email-masked]

> 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

Date: Mon, 10 May 2004 09:05:33 -0400
From: Matthew Carpenter <[email-masked]>
To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
Sender: [email-masked]

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:[email-masked]>) 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.
>
>

To: [email-masked]
Subject: Re: envelope test syntax?
From: Michael Haardt <[email-masked]>
Date: Wed, 12 May 2004 11:35:22 +0200
Sender: [email-masked]

> > 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

Date: Wed, 12 May 2004 00:50:21 -0700
From: Tim Showalter <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

Date: Wed, 12 May 2004 00:30:38 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], "Mark E. Mallett" <[email-masked]>
cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

Hi [email-masked],

--On Tuesday, May 11, 2004 9:01 PM -0700 [email-masked] 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

Date: Tue, 11 May 2004 21:01:57 -0700 (PDT)
From: [email-masked]
Subject: Re: envelope test syntax?
To: "Mark E. Mallett" <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

> 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

Date: Tue, 11 May 2004 17:26:21 -0700
From: Tim Showalter <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 11 May 2004 18:43:02 -0400
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: envelope test syntax?
Sender: [email-masked]

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

Date: Tue, 11 May 2004 18:09:26 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: envelope test syntax?
Sender: [email-masked]

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

Date: Sat, 08 May 2004 15:46:34 -0700
From: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
Sender: [email-masked]

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:[email-masked]>) 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.

Date: Thu, 06 May 2004 11:56:58 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexandros Vellis <[email-masked]>, [email-masked]
Subject: Re: Sieve Extension I-Ds(not)  becoming RFCs and IANA assignments   (e.g. refuse, and older ones, like vacation(!), regex, imapflags.
Sender: [email-masked]

Hi Alexandros,

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

|> I guess the Sieve homepage at cyrussoft is sorely out of date (I emailed
|> the maintainer (sieve%cyrusoft.com <mailto:[email-masked]>) 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:[email-masked]>. 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

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" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Matthew Elvey (FM) wrote:

> I guess the Sieve homepage at cyrussoft is sorely out of date (I emailed
> the maintainer (sieve%cyrusoft.com <mailto:[email-masked]>) 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
[email-masked]         Network Operations Centre
Public Key: http://www.noc.uoa.gr/~avel/gpgkey.asc