Subject: Re: sieve draft

From: "Chris Bartram" <[email-masked]>
Date: Mon, 27 Oct 1997 16:57:13 -0400

In <[email-masked]> [email-masked] writes:

Hi,

  I'm glad to see this draft coming forward. I do have a few issues with it
though... ;-)

 - first, your draft was attached as a BASE64 encoded text file... That's
   ok, but woulda been nicer if if were text/plain or even quoted-printable.

 - the "required" flag on rules...
   I know several *nix implementations will be reading these on-the-fly, and
   might benefit from such a flag, but those of us who plan to implement GUIs
   where you can't even enter an action or rule that's not valid will have
   no use for such a flag... I'm not quite sure how I'd handle this - I
   suspect that having the spec require something parse the rules file
   before rules are loaded wouldn't go over well? Everyone's gotta "link up"
   the rules at some point though - it seems to me (IMHO) that a parse and
   flagging of actions or tests that aren't supported be flagged at that
   point. I have no desire to "make space" in our already implemented (though
   not standard-compliant --yet) rule system for rules that we don't support.

   I recall some of the debate on this earlier, and if the point is more for
   "storage" of rules, perhaps to be downloaded to clients on demand, then
   I withdraw my protest; though I didn't really get the impression that this
   is what this proposal is about.

 - more importantly, the "bounce" action.
   I have a *real* problem with users being able to "bounce" a message, for
   a couple reasons;

   I deal with spam ALOT, and probably 60-80% of UCE that comes in has
   faked return addresses -either completely bogus names or (happening more
   often) faked names using someone ELSE's domain. Further, many of the
   UCEs received lately have their return addresses merely set to "remove"
   robot addresses -- which tests done by folks on the SPAM-L and net-abuse
   newsgroups have demonstrated repeatedly that responses to these addresses
   does NOT remove you from a list, but merely confirms that the address the
   spammer sent to is a valid address (and in turn yields yet more spam).

   Anyway, my point; while the idea of sending back a "go away spammer"
   seems like a satisfying one, it's NOT going to get to them. Further, it's
   either gonna contribute to a mail-bomb attack on an innocent third-party
   whose from address was forged, confirm their own address for the spammers
   mailing list (which they're all selling/swapping these days), or it's
   gonna clog up your own system's MTA as it tries to deliver to a shut down
   or invalid domain.

   A "bounce", to be effective, needs to take place in the MTA (SMTP Server
   process) - refusing the message before it's actually delivered into any
   local mailboxes (i.e. as the diagram below:

 C:<connect server>
 S:220 server ready
 C:HELO myhost
 S:250 Ok
 C:MAIL FROM:<[email-masked]>
 S:250 Ok
 C:RCPT TO:<postmaster>
 S:250 Ok
 C:DATA
 S:354 Start sending message
 C:<message contents sent>
*********************************
 S:5xx message refused, spammer
*********************************

   This stops the message before it gets into your queues, and forces the
  sender's system to deal with it as an undeliverable message -- using THEIR
  resources, not yours.
   To do this kind of refusing, you have to perform rules globally - not from
  any individual's rule-set (unfortunately); as obviously different users will
  have different rules.

   My proposal would be to drop the "bounce" action, utilizing just the
  "drop"/"delete" action instead. Using bounce is going to put a major load
  on "friendly" mail systems and will almost never have the desired (though
  admirable) effect.

                 -Chris Bartram
                  3k Associates, Inc.

---

From: Tim Showalter <[email-masked]>
Date: Fri, 31 Oct 1997 14:46:30 -0500 (EST)

>  - the "required" flag on rules...

I'm not particularly happy with the way required works out, but it may be
needed; all Internet protocols are required to have an extension mechanism.

I'd like to drop require and rely on support.

>    no use for such a flag...

Your GUI implementation supports an extension Foo.  My server does not.
You use it.  My server rejects it as a syntax error.  So there is a use for
it.

This is how it's supposed to work.  I'm not sure it's good, but it's there.

>    is what this proposal is about.

I'm not sure how that would work, but that's not what it's for.  It's meant
to be a way of moving the scripts around and tag them with the extensions
that the scripts require.

>  - more importantly, the "bounce" action.

With regards to spam:

If one removes the bounce action, one must also remove the reply action
which does the same thing in a different context.

The bounce action is not for spam, it's for refusing delivery of a message.

>    local mailboxes (i.e. as the diagram below:
[snip]
>   sender's system to deal with it as an undeliverable message -- using THEIR

I disagree.  This stops the message while in a relay's queues, forcing them
to generate the same failure notification.  The difference seems rather
marginal to me.

Effectively, this is part of an MTA server process.  I intend to have
sendmail run a program to do the filtering, making the filter part of the
MTA.  These scripts are only intended to be run on messages once, at the
point where they're filtered into the user's mailbox -- this is close enough
to being part of the MTA for me.

>   any individual's rule-set (unfortunately); as obviously different users will

I don't understand this.  I think you're arguing against yourself.

>   on "friendly" mail systems and will almost never have the desired (though

Bounces will never have the desired effect on spam.

Some users will want bounce (and reply); some sites will probably need to
prohibit it.  Can I make the draft reflect that?

-- 
                                           Tim Showalter [email-masked]

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 1 Nov 1997 00:32:32 +0100 (CET)

> I'd like to drop require and rely on support.

I concur.

> You use it.  My server rejects it as a syntax error.  So there is a use for

It might not be suitable to regard a call to an unimplemented extension
as a syntax error. In particular, if one choose to optimize the filtering
for high volume delivery, the script will be parsed and possibly optimized
once at startup but not evaluated until time of delivery later on.
If the unimplemented extension is rejected as a syntax error when parsed,
the whole script would become broken/useless in this environment. On the
other hand, we might instead regard it as a runtime error, and ask our
selves how that would be handled in a nice way. This is what I am aiming
at when I talk about exception handling.

> that the scripts require.

I'm not sure I understand that requirement.
It seems to me that the kind of problems you are discussing here exists
mainly because there is no effective two-way communication between the
creator and the executor.
Now, your talk about moving scripts around seem to me as a kind of
old fashioned way to communicate between networked devices. As a
matter of fact, I think I put out my neck and ask; why not use a
protocol to communicate filtering rules? Really, think about it,
shouldn't that solve a whole bunch of problems???

> which does the same thing in a different context.

No. I strongly disagree with this statement.
You are correct in that bounce and reply is very similar in operation
but belong to different contexts. But that is also why I disagree.
A bounce can, per definition, only be done by the mail transport agent.
A reply can only be done by the end user, or on behalf of the end user
but still in the name of the end user.

The key here is the question; who is doing what for whom?
I regard filtering as effectuated on behalf of the local account
targeted for delivery. It is done as part of the delivery process.
>From the MTA perspective, the message have been delivered.
It's the delivery agent who now try to figure out how the owner want
his message handled, with help from a sieve script for example.
Now, unwanted messages can simply not be bounced, only dropped or
replied (or forwarded). One reason for not allowing bounce as part
of delivery is the requirement from the network community to have
a reliable global mail transport system.

> The bounce action is not for spam, it's for refusing delivery of a message.

I maintain the position that a delivery cannot be refused, only
processed. The delivery process can do many things, but never bounce.

> to generate the same failure notification.  The difference seems rather

No, I maintain my opinion that you are wrong here.
The message is no longer in the relay's queue if it has reached a
point where the end user can affect it's processing, by defining a
sieve script for example.

> to being part of the MTA for me.

Oh-oh. You are very close to break your MTA's integrity. I cannot stop
you from doing it, only ask you to refrain. If nothing else, you will
sooner or later be flamed by sendmail gurus by doing a thing like this.

You have a logical error in your thinking.
You cannot do filtering on behalf for a specific end user before
you have decided who to deliver the message to. You cannot possibly
know what set of filtering rules to execute before the actual point
of delivery. Once you have decided whom to deliver the message to,
you should accept the fact that the message have moved into another
domain of processing. You can't have it both ways.

> I don't understand this.  I think you're arguing against yourself.

I ask you to read it more carefully. There is an important point here.
We are not trying to fool you. We want you to understand that you
have a logical error in your thinking.

> prohibit it.  Can I make the draft reflect that?

I strongly advise to drop the bounce action.
The argument is that an end user should not be allowed to cause a
bounce. The reason for that is simple. Bouncing unwanted messages
is an unfriendly action, only causing yet more traffic on the
network. This is something you should avoid to encourage.

--
Tomas Fasth

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 1 Nov 1997 03:02:56 +0100 (CET)

> The bounce action is not for spam, it's for refusing delivery of a message.

What other than spam would be a subject for delivery refusal?
Before you answer, remember that delivery refusal is not the same
as bounce, and that bounce almost always cost network resources
outside your own domain.

> to being part of the MTA for me.

Are you not mixing up filtering with screening?
A thing that a MTA would want to do is to screen unwanted traffic.
But that kind of processing should only use information that is
available as part of the protocol itself, not the data it is
transporting. At this level CPU time is a delicate resource and
message parsing should be avoided by all means. A good example
of why is the "denial of service" type of attacks.

> Bounces will never have the desired effect on spam.

You are right, simply because spam should always be dropped
silently to minimize use of resources. But then, what other
reason is there to bounce a message once it has been dispatched
for delivery?

I can understand that spam screening should be done at MTA
level if possible. But isn't it more of a function based on
statistical information at the protocol level, rather than
information extracted from the actual message? And if so,
in what way does a scripting language like Sieve improve that
particular kind of processing?

> prohibit it.  Can I make the draft reflect that?

I would like to see some examples on why a user would want to bounce
a message before reflecting such a behavior in the draft.

Actually, can you give examples of any other filtering tools that
allow a bounce action that is distinguishable from a reply action?
I'm not sure you can, you know...

--
Tomas Fasth

---

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 31 Oct 1997 21:35:35 -0800

On Nov 1,  3:02am, Tomas Fasth wrote:
}
} What other than spam would be a subject for delivery refusal?

Some examples:

I run an email customer support service.  Customers with paid support can
legitimately send mail to [email-masked].  All other messages
sent to that address are bounced, with the suggestion that they pay up.
(No, I don't really run such a service.  These are examples.)

I subscribed to the [email-masked] mailing list, but now I don't
want it any more.  I've sent a dozen unsubscribe requests, but nobody
is managing the list and it keeps coming to me.  I want to bounce the
messages back to the (admittedly unresponsive) list admin address and
to the [email-masked] in hopes of getting their attention.  But
that doesn't mean that everyone at my site thinks the fud-list is spam.

I could come up with more, but they're mostly variations on one of those
two themes:  (1) Only messages matching some criteria should be delivered,
and all others should get a bounce explaining why they were not; (2) some
source of mail not normally considered to be spam is for whatever reason
abusing a mailbox, and a bounce should be generated to notify the sender
of this unintentional abuse.

} A thing that a MTA would want to do is to screen unwanted traffic.
} But that kind of processing should only use information that is
} available as part of the protocol itself, not the data it is
} transporting.

Not true.  For example, there may be a valid reason for some mailboxes
to reject all messages that do not have a digital signature, or that are
not encrypted using a particular public key.  But the protocol doesn't
reveal whether the data is digitally signed or encrypted.

} Actually, can you give examples of any other filtering tools that
} allow a bounce action that is distinguishable from a reply action?

A reply action is typically directed to addresses taken from the RFC822
header of the message, e.g. the "From" or "Reply-To" fields.  A bounce
is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM"
address.  There presently aren't many (if any) tools that are able to
make that distinction, because there are few MTA-level filtering tools;
almost all must run "post-delivery" without access to the SMTP envelope.
One purpose of the sieve language, as I understand it, is to enable the
user to intervene *before* the MTA delivers the message, thus making it
*possible* to have distinguished "bounce" and "reply" actions.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 31 Oct 1997 21:35:35 -0800
Comments: In reply to Tomas Fasth <[email-masked]> "Re: sieve draft" (Nov  1,  3:02am)
To: Tomas Fasth <[email-masked]>, [email-masked] (Tim Showalter)
Subject: Re: sieve draft
Cc: [email-masked]
Sender: [email-masked]

On Nov 1,  3:02am, Tomas Fasth wrote:
}
} What other than spam would be a subject for delivery refusal?

Some examples:

I run an email customer support service.  Customers with paid support can
legitimately send mail to [email-masked].  All other messages
sent to that address are bounced, with the suggestion that they pay up.
(No, I don't really run such a service.  These are examples.)

I subscribed to the [email-masked] mailing list, but now I don't
want it any more.  I've sent a dozen unsubscribe requests, but nobody
is managing the list and it keeps coming to me.  I want to bounce the
messages back to the (admittedly unresponsive) list admin address and
to the [email-masked] in hopes of getting their attention.  But
that doesn't mean that everyone at my site thinks the fud-list is spam.

I could come up with more, but they're mostly variations on one of those
two themes:  (1) Only messages matching some criteria should be delivered,
and all others should get a bounce explaining why they were not; (2) some
source of mail not normally considered to be spam is for whatever reason
abusing a mailbox, and a bounce should be generated to notify the sender
of this unintentional abuse.

} A thing that a MTA would want to do is to screen unwanted traffic.
} But that kind of processing should only use information that is
} available as part of the protocol itself, not the data it is
} transporting.

Not true.  For example, there may be a valid reason for some mailboxes
to reject all messages that do not have a digital signature, or that are
not encrypted using a particular public key.  But the protocol doesn't
reveal whether the data is digitally signed or encrypted.

} Actually, can you give examples of any other filtering tools that
} allow a bounce action that is distinguishable from a reply action?

A reply action is typically directed to addresses taken from the RFC822
header of the message, e.g. the "From" or "Reply-To" fields.  A bounce
is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM"
address.  There presently aren't many (if any) tools that are able to
make that distinction, because there are few MTA-level filtering tools;
almost all must run "post-delivery" without access to the SMTP envelope.
One purpose of the sieve language, as I understand it, is to enable the
user to intervene *before* the MTA delivers the message, thus making it
*possible* to have distinguished "bounce" and "reply" actions.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

From: Tomas Fasth <[email-masked]>
Subject: Re: sieve draft
To: [email-masked] (Tim Showalter)
Date: Sat, 1 Nov 1997 03:02:56 +0100 (CET)
Cc: [email-masked]
Sender: [email-masked]

--
Tomas Fasth

From: Tomas Fasth <[email-masked]>
Subject: Re: sieve draft
To: [email-masked]
Date: Sat, 1 Nov 1997 01:47:43 +0100 (CET)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Any protocol that used sieve to describe filters would have to be
> extensible, of course.  For example, if IMAP or ACAP or whatever were
> extended to allow a user to set up filters, then the client could
> attempt to pass a filter that used a certain feature..  A server that
> didn't understand that feature might return with a parse error.  If
> the parse error were specific enough, the client could restate the
> filter without using that feature if possible.  This could be automated
> so that human intervention isn't required.

Hmm, a very interesting idea, indeed.
I had a similar idea of having a more detailed protocol where client
and server could exchange not only capabilities and general parsing
errors, but also ok/no responses on individual lines of filtering
rules. My idea is not very different from the ipfw command in
FreeBSD, if you happen to know about it, although message filtering
will require more sofisticated conditional expressions.

> If you keep "require", and make it processed at parse time, and then
> make some standard way for a server to report require failures, then
> the client could easily use extensions if they are there, and fall back
> to more basic constructs if they're not.  So, it's extensible.

But then, why would "require" be part of the script?
If you have established a two-way communication to the server,
wouldn't it be better to exchange the requirements, or capabilities,
as part of the protocol and not as part of the script?

> Either that have some standard way of describing revisions of
> sieve.  Then the server could just tell the client what revision it
> supports, and the client could form the text accordingly.

No, I don't like the version style.
Versions is something that should be coordinated.
Extensions or capabilities is, at least as I view it, a method to 
extend a base spec without the need of coordination. Which I think
was the idea for Sieve.

> So I don't think the sieve language itself needs to support an
> extension mechanism, necessarily.

To that I can concur. Thank you for pointing out the difference in
this regard between a protocol and a language.

--
Tomas Fasth

From: Tomas Fasth <[email-masked]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
To: [email-masked]
Date: Sat, 1 Nov 1997 01:29:16 +0100 (CET)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>   I'm not sure what a link error would be in a language like sieve;
> was thinking that all implementations would be heavily based on a
> lisp-like engine of some sort, but perhaps I misunderstand it.  I
> agree that syntax errors should not be exceptions.  Further, I think
> syntax errors should be caught before interpretation begins.

My personal view is that syntax errors should be caught before the
script is put to work. I am not willing to equal this particular
situation with avarage execution of command shell scripts.
These scripts are about to execute in batch mode as part of a
delivery process.
An good example is aliases as used by sendmail. The aliases file
have to be processed before being put into the message dispatch
process. Syntax errors are reported to the operator. The alias
lookup mechanism in sendmail does not have to deal with
syntactical errors.
Why not apply a similar requirement on filtering?

>   Hmm, perhaps I wasn't clear; I'm not advocating the adoption of a
> Python-like syntax for sieve.  I was just trying to clarify the point
> about Python syntax.  (Which is not to say that I think
> indentation-based syntax is bad; I like it.  It's just not that
> important for something like sieve.)

I tend to agree, with one exception(!):
I thought of Sieve as potentially being exposed to the end user.
In that case, indentation based syntax can make a difference.
Otherwise I agree, it's not that important.

--
Tomas Fasth

From: Tomas Fasth <[email-masked]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
To: [email-masked] (Tim Showalter)
Date: Sat, 1 Nov 1997 01:05:14 +0100 (CET)
Cc: [email-masked]
Sender: [email-masked]

> So I should point out that this isn't a working group, just for the sake of
> completeness; it's just a mailing list, despite the name.

Sorry, I think I was the one that mixed this up.
I understand the difference, but still hope the opinions expressed
on this list are considered in the process of making a public spec
on Sieve.

> Regarding exceptions, I'm against them.

In the context of the sieve language, I can understand this.
Still, there might occur error conditions that may have to be
handled in some way, as an exception or something else. But I
am not in a position to give examples so I will shut my mouth.
:)

> Those are the only exceptional cases I can think of that can come up.
> Having exception handling in a language without loops, subroutines, or
> variables seems like overkill.

Yes, you have a point there.

> Regarding Python-style indents, I'm one of the people who doesn't think it's
> "clean" and am against it.

Oh, I see. I have done C-programming as long as I can remember.
The curly brackets offered a formatting freedom, but also allowed
some programmers to abuse the de facto style of programming,
sometimes making the code close to unreadable.

The beauty of Python is that the code is always readable, regardless
of the programmer's personal style.
Also, dropping the programmer hat and putting on the non-technical
hat (my mother is a good example), Python style is more consistent.
It is less intuitive for my mother to understand why curly brackets
is sometimes missing and sometimes required.

Anyway, I'm not arguing to change Sieve's programming style.
Regard my comment about curly brackets as a personal reflecton.

--
Tomas Fasth

From: Tomas Fasth <[email-masked]>
Subject: Re: sieve draft
To: [email-masked] (Tim Showalter)
Date: Sat, 1 Nov 1997 00:32:32 +0100 (CET)
Cc: [email-masked]
Sender: [email-masked]

I concur.

--
Tomas Fasth

From: "Paul Falstad" <[email-masked]>
Date: Fri, 31 Oct 1997 13:50:14 -0800
Reply-To: Paul Falstad <[email-masked]>
To: Tim Showalter <[email-masked]>
Subject: Re: sieve draft
Cc: MTA Filters <[email-masked]>
Sender: [email-masked]

| I'm not particularly happy with the way required works out, but it may be
| needed; all Internet protocols are required to have an extension mechanism.
|
| I'd like to drop require and rely on support.

Well, sieve is a language rather than a protocol...  There's no way
to negotiate what features are supported, without introducing something
like a preprocessor (#ifdef FEATURE_X...) and that's not a particularly
attractive way to do it.

Any protocol that used sieve to describe filters would have to be
extensible, of course.  For example, if IMAP or ACAP or whatever were
extended to allow a user to set up filters, then the client could
attempt to pass a filter that used a certain feature..  A server that
didn't understand that feature might return with a parse error.  If
the parse error were specific enough, the client could restate the
filter without using that feature if possible.  This could be automated
so that human intervention isn't required.

If you keep "require", and make it processed at parse time, and then
make some standard way for a server to report require failures, then
the client could easily use extensions if they are there, and fall back
to more basic constructs if they're not.  So, it's extensible.

Or, you could drop "require" from the language itself, and rely on
something like it being present in whatever protocol is used to pass
filters back and forth.

Either that have some standard way of describing revisions of
sieve.  Then the server could just tell the client what revision it
supports, and the client could form the text accordingly.

So I don't think the sieve language itself needs to support an
extension mechanism, necessarily.

--
Paul Falstad                                 Software.com, Inc.
[email-masked]                    805-957-1790 x520
http://www.ttinet.com/pjf/                   http://www.software.com/

Date: Fri, 31 Oct 1997 15:52:27 -0500
From: "Fred L. Drake" <[email-masked]>
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
Reply-To: "Fred L. Drake, Jr." <[email-masked]>
Sender: [email-masked]

Tim Showalter writes:
 > * Syntax/link errors shouldn't be exceptions.

  I'm not sure what a link error would be in a language like sieve;
was thinking that all implementations would be heavily based on a
lisp-like engine of some sort, but perhaps I misunderstand it.  I
agree that syntax errors should not be exceptions.  Further, I think
syntax errors should be caught before interpretation begins.

 > Having exception handling in a language without loops, subroutines, or
 > variables seems like overkill.

  Ok, this makes sense.

 > Regarding Python-style indents, I'm one of the people who doesn't think it's
 > "clean" and am against it.

  Hmm, perhaps I wasn't clear; I'm not advocating the adoption of a
Python-like syntax for sieve.  I was just trying to clarify the point
about Python syntax.  (Which is not to say that I think
indentation-based syntax is bad; I like it.  It's just not that
important for something like sieve.)

  -Fred

--
Fred L. Drake, Jr.
[email-masked]
Corporation for National Research Initiatives
1895 Preston White Drive
Reston, VA    20191-5434

Date: Fri, 31 Oct 1997 14:55:53 -0500 (EST)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
Sender: [email-masked]

So I should point out that this isn't a working group, just for the sake of
completeness; it's just a mailing list, despite the name.

Regarding exceptions, I'm against them.

* Syntax/link errors shouldn't be exceptions.

* Can't-write-to-mail-spool errors (i.e., user is over quota) should be
  handled by not filtering messages if the user is over quota, or otherwise
  having a temporary failure, waiting until the user isn't over quota, and
  then filing the message.

Those are the only exceptional cases I can think of that can come up.
Having exception handling in a language without loops, subroutines, or
variables seems like overkill.

Regarding Python-style indents, I'm one of the people who doesn't think it's
"clean" and am against it.

Date: Fri, 31 Oct 1997 14:46:30 -0500 (EST)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: Re: sieve draft
Sender: [email-masked]

With regards to spam:

[snip]

Date: Wed, 29 Oct 1997 17:25:21 +0100
From: Tomas Fasth <[email-masked]>
Organization: EuroNetics
To: [email-masked]
Subject: Re: Comment on draft-showalter-sieve-02.txt
Sender: [email-masked]

Fred L. Drake wrote:

>   Wow, I didn't expect to hear Python mentioned here, but that's great
> with me!
>   I would like to point out that really only the layout and try/except
> lines are legal Python.  I'd expect a Python translation to look more
> like:
> 
>   if string.find(string.lower(header["subject"]), "the secret message") > -1:

You're right. I wasn't using pure Python syntax. But this mistake became
deliberate as I copied the example from the draft to modify it. I
realized how similar the syntax really was, part from your correction
above, so I left much of it as is, as a slight attempt to provoke. :)

>   I like the idea of exceptions in a "normal" programming language,
> but am not convinced that they are appropriate here.  Perhaps all
> exception-like conditions should be handled by the implementation as
> keep commands; this seems to be in the spirit of the proposal.

I tend to agree, sorry for the diversion.
My real mission was rather to question the overall existence of the
"require" declaration. Is it correct to call it a declaration, by the
way? It just felt like not doing any good in the spec and might, as Tim
was expressing concerns about in the open paragraph, cause trouble when
implementing a parser/evaluator/executor.

Someone willing to stand up and defend "require"?

BTW, Tim and others, I was pleased to discover this workgroup and what
it tries to achieve. Very much needed, IMHO. It is my intention to use
the final proposal as part of a IMAP-based filtering agent.

- Tomas

Date: Wed, 29 Oct 1997 10:42:45 -0500
From: "Fred L. Drake" <[email-masked]>
To: Tomas Fasth <[email-masked]>
Cc: [email-masked]
Subject: Re: Comment on draft-showalter-sieve-02.txt
Reply-To: "Fred L. Drake, Jr." <[email-masked]>
Sender: [email-masked]

Tomas Fasth writes:
 > it's not a programming language in that sense. But I cannot restrain
 > myself from giving you an example of exception handling, using the
 > excellent programming language called Python:
 > 
 > if header ("subject") contains-nocase ("the secret message")
 >   try:
 >     dwim blurdybloop body
 >   except ActionNotFound:
 >     keep # leave it alone

  Wow, I didn't expect to hear Python mentioned here, but that's great
with me!
  I would like to point out that really only the layout and try/except
lines are legal Python.  I'd expect a Python translation to look more
like:

  if string.find(string.lower(header["subject"]), "the secret message") > -1:
    try:
      dwim.blurdybloop(body)
    except ActionNotFound:
      keep()

  ;-)

  I like the idea of exceptions in a "normal" programming language,
but am not convinced that they are appropriate here.  Perhaps all
exception-like conditions should be handled by the implementation as
keep commands; this seems to be in the spirit of the proposal.

  -Fred

--
Fred L. Drake, Jr.
[email-masked]
Corporation for National Research Initiatives
1895 Preston White Drive
Reston, VA    20191-5434

Date: Wed, 29 Oct 1997 15:49:34 +0100
From: Tomas Fasth <[email-masked]>
Organization: EuroNetics
To: [email-masked]
Subject: Comment on draft-showalter-sieve-02.txt
Sender: [email-masked]

I have a comment on draft-showalter-sieve-02.txt chapter 3.2. Require,
Page 15:

Is there a good reason why the the "require" declaration exists?
Can someone provide a good argument or two?
I have some arguments for removing it.

1. Terminating a script because it may or may not use an extension later
on seem to be a rather exotic need. Too exotic for requiring (!) a
separate declaration?

2. The "require" declaration can become an unecessary source of
confusion when debugging a faulty script. The relation, or perhaps the
connection, between the "require" declaration and the extension call is
not that obvious.

3. For a programmer (like me :-), a better approach to address problems
like extensions is by introducing a basic exception handling. I know,
it's not a programming language in that sense. But I cannot restrain
myself from giving you an example of exception handling, using the
excellent programming language called Python:

if header ("subject") contains-nocase ("the secret message")
  try:
    dwim blurdybloop body
  except ActionNotFound:
    keep # leave it alone

Note that Python is indentation sensitive, an alternative to "{}". Some
may regard it cleaner, other's may not. Anyway, the try-except
(try-catch in C++) mechanism is a powerful tool for providing clean
programming in modern programming languages.

4. The "support" conditional test seem adequate in most cases. May be
that is sufficient for our needs.

regards,

Tomas Fasth

From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Date: Mon, 27 Oct 1997 16:57:13 -0400
Subject: Re: sieve draft
To: [email-masked]
Sender: [email-masked]

Hi,

 C:<connect server>
 S:220 server ready
 C:HELO myhost
 S:250 Ok

                 -Chris Bartram
                  3k Associates, Inc.

Date: Fri, 24 Oct 1997 22:54:55 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: sieve draft
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--41976867-1720278692-877748095=:5558
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm about to submit this as a new sieve draft.  I'm sorry for the long
delay.

Thanks to Chris Newman for abnf.c and nroff help and Rob Earhart for even
more nroff help.

--41976867-1720278692-877748095=:5558
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sieve.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 

--41976867-1720278692-877748095=:5558--