Subject: Non-Tech: Sieve article in Network World

From: Matthew Wall <[email-masked]>
Date: Wed, 30 Aug 2000 18:51:17 -0400

http://www.nwfusion.com/news/2000/0828sieve.html

Made the front page in the paper edition, which also has a neato-graphic. 
Some of the usual suspects are quoted.

FYI

- matt

Date: Wed, 30 Aug 2000 18:51:17 -0400
From: Matthew Wall <[email-masked]>
To: [email-masked]
Subject: Non-Tech: Sieve article in Network World
Sender: [email-masked]

http://www.nwfusion.com/news/2000/0828sieve.html

Made the front page in the paper edition, which also has a neato-graphic. 
Some of the usual suspects are quoted.

FYI

- matt

Date: Wed, 30 Aug 2000 18:51:17 -0400
From: Matthew Wall <[email-masked]>
To: [email-masked]
Subject: Non-Tech: Sieve article in Network World
Sender: [email-masked]

http://www.nwfusion.com/news/2000/0828sieve.html

Made the front page in the paper edition, which also has a neato-graphic. 
Some of the usual suspects are quoted.

FYI

- matt

Date: Wed, 30 Aug 2000 15:59:41 +0200
From: Phil Pennock <[email-masked]>
To: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Mail-Followup-To: Phil Pennock <[email-masked]>, [email-masked]
Organisation: Demon Internet Netherlands
Sender: [email-masked]

(First post - I've been lurking)

On 2000-08-29 at 13:28 -0700, Chris Newman wrote:
> Suppose I make a client to compose and upload Sieve scripts.  Either it 
> refuses to allow unqualified local parts, in which case it interoperates 
> with everything, except your "local" server.  Or it permits them, in which 
> case whether (and how) it interoperates with a given server is 
> unpredictable when an unqualified local part is used.

require "domainless";

> Indeed I think it would be quite useful to have a sieve client which can 
> test the script locally by running messages through the script.  But such a 
> client couldn't perform a deterministic test unless unqualified local parts 
> were banned or it had a 100% reliable way to discover what the server would 
> do with unqualified local parts.

If the server accepts them, and you see them, it's passed them to you.
:^)  The server may or may not have chosen to qualify them with a
default; if it doesn't, the installation should allow "domainless".
If this is SHOULD NOT, then there's no need to even code the support for
it.  If someone wants a horrendously broken system, they can hack the
extension in themselves.

So the question is what _you_ do with the messages, because you've
received them.  Specify that ``require "domainless";'' changes the
syntax of addr-spec to not require ``"@" domain'', and note some of the
problems which could arise from simply changing the grammar.

Make it scary enough, and admin will hopefully get a clue, and as part
of their upgrade to support sieve they'll choose to qualify local
addresses automatically in the MTA.

If the MUA doesn't use the MTA for local addresses (???) then the
messages will never reach a sieve filter.

$0.02,
-- 
Phil Pennock                        <[email-masked]> <[email-masked]>
Demon Internet Nederland -- Network Operations Centre -- Systems Administrator
Libertes philosophica.
Sales: +31 20 422 20 00                                Support: 0800 33 6666 8

Date: Tue, 29 Aug 2000 13:28:17 -0700
From: Chris Newman <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

--On Tuesday, August 29, 2000 15:50 -0400 Ken Murchison <[email-masked]> 
wrote:
> Chris Newman wrote:
>> There's an installed base that finds localized 8-bit character sets in
>> headers useful.  That doesn't mean it interoperates or should be blessed
>> in any way by a standard.
>
> I agree, but for sake of argument, lets assume that Sieve is being used
> with an internal MTA which is setup to handle local addresses (no
> domain).  If someone can send intraoffice mail to "ken", then I need to
> be able to put "ken" in the ":addresses" option of my vacation rule.
> Likewise, I should be able to do a redirect to "tjs" in this
> environment.

I fully understand the scenario, and it's almost identical to the 8-bit 
header scenario I mentioned.

> I wouldn't setup my environment this way, but I think what Tim is saying
> is that Sieve might be used in such an environment and should be locally
> adaptable.

We certainly can't stop anyone from doing that if they wish, but neither 
should it be standards-compliant syntax.

> I don't see where there is an interoperability problem because this
> would be a local configuration decision, and the local addresses are
> only going to be useful if the corresponding MTA can handle them.
> Obviously, these addresses would never see the public network.

Here's the interop problem:

Suppose I make a client to compose and upload Sieve scripts.  Either it 
refuses to allow unqualified local parts, in which case it interoperates 
with everything, except your "local" server.  Or it permits them, in which 
case whether (and how) it interoperates with a given server is 
unpredictable when an unqualified local part is used.

Indeed I think it would be quite useful to have a sieve client which can 
test the script locally by running messages through the script.  But such a 
client couldn't perform a deterministic test unless unqualified local parts 
were banned or it had a 100% reliable way to discover what the server would 
do with unqualified local parts.

		- Chris

Date: Tue, 29 Aug 2000 15:50:07 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Chris Newman <[email-masked]>
CC: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

Chris Newman wrote:
> 
> --On Monday, August 28, 2000 17:52 -0700 Tim Showalter <[email-masked]>
> wrote:
> > I'm not advocating MUST or SHOULD here.  It's got to be optional, and
> > will clearly be useless for enlightened implementations that always use
> > FQDNs.  Unfortunately there's an installed base that might find local
> > addresses useful.
> 
> There's an installed base that finds localized 8-bit character sets in
> headers useful.  That doesn't mean it interoperates or should be blessed in
> any way by a standard.

I agree, but for sake of argument, lets assume that Sieve is being used
with an internal MTA which is setup to handle local addresses (no
domain).  If someone can send intraoffice mail to "ken", then I need to
be able to put "ken" in the ":addresses" option of my vacation rule. 
Likewise, I should be able to do a redirect to "tjs" in this
environment.

I wouldn't setup my environment this way, but I think what Tim is saying
is that Sieve might be used in such an environment and should be locally
adaptable.

I don't see where there is an interoperability problem because this
would be a local configuration decision, and the local addresses are
only going to be useful if the corresponding MTA can handle them. 
Obviously, these addresses would never see the public network.

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

Date: Tue, 29 Aug 2000 11:59:51 -0700
From: Chris Newman <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

--On Monday, August 28, 2000 17:52 -0700 Tim Showalter <[email-masked]> 
wrote:
> I'm not advocating MUST or SHOULD here.  It's got to be optional, and
> will clearly be useless for enlightened implementations that always use
> FQDNs.  Unfortunately there's an installed base that might find local
> addresses useful.

There's an installed base that finds localized 8-bit character sets in 
headers useful.  That doesn't mean it interoperates or should be blessed in 
any way by a standard.

Unqualified local parts are not legal by 821 or 822.  They should always be 
treated as a Sieve syntax error.  Perhaps the protocol used to upload a 
Sieve script could provide a domain which clients may choose to append to 
unqualified local parts.

		- Chris

To: Ken Murchison <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 21:30:12 -0700
Lines: 21
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:

> Chris Newman wrote:
> > 
> > --On Tuesday, August 22, 2000 19:08 -0700 Tim Showalter <[email-masked]>
> > wrote:
> > >> What about local addresses like "tjs" or "ken"?  Is this going to be a
> > >> MAY?
> > >
> > > It probably should be.  I will try and come up with wording real soon.
> > 
> > Actually, I'd say MUST NOT (but could live with SHOULD NOT).  Every time
> > I've seen "local" addresses used anywhere it caused problems down the road.
> 
> I wasn't advocating local addresses.  I'd rather see FQDNs.  Tim had
> mentioned this before, and I was just clarifying what he was thinking so
> I can make the appropriate (if any) changes in cmu-sieve.

okay, okay, let's just drop 'em.  :-)

Tim

Date: Mon, 28 Aug 2000 23:59:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Chris Newman <[email-masked]>
CC: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

Chris Newman wrote:
> 
> --On Tuesday, August 22, 2000 19:08 -0700 Tim Showalter <[email-masked]>
> wrote:
> >> What about local addresses like "tjs" or "ken"?  Is this going to be a
> >> MAY?
> >
> > It probably should be.  I will try and come up with wording real soon.
> 
> Actually, I'd say MUST NOT (but could live with SHOULD NOT).  Every time
> I've seen "local" addresses used anywhere it caused problems down the road.

I wasn't advocating local addresses.  I'd rather see FQDNs.  Tim had
mentioned this before, and I was just clarifying what he was thinking so
I can make the appropriate (if any) changes in cmu-sieve.

Actually, since there had been literally no traffic on this topic, I
thought Tim and I were having a private discussion :^)

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

Date: Mon, 28 Aug 2000 22:38:56 -0400
From: Lawrence Greenfield <[email-masked]>
To: Chris Newman <[email-masked]>, Tim Showalter <[email-masked]>
Cc: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

   Cc: Ken Murchison <[email-masked]>, [email-masked]
   From: Tim Showalter <[email-masked]>
   Date: 28 Aug 2000 17:52:16 -0700

   > in the same mailstore.  In short, the concept of "local" is
   > meaningless to me.  The only concept that might have meaning is
   > "same domain as in RCPT TO being processed", but for a given
   > sieve script, that might have many different values.

   I'm not advocating MUST or SHOULD here.  It's got to be optional, and
   will clearly be useless for enlightened implementations that always use
   FQDNs.  Unfortunately there's an installed base that might find local
   addresses useful.

As a server implementor, I'd love to tell clients to not throw this
unqualified names at me.  I'd like to stick this work with the client
and I think the client is more than capable of doing this.  I'd rather
not guess what the client is going to do.

I'm not sure what functionality is added by the extension---clients
should be able to throw a domain on the RHS.

Larry

To: Chris Newman <[email-masked]>
Cc: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 17:52:16 -0700
Lines: 58
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

> I was using shorthand.  I was suggesting a scenario where <[email-masked]>
> goes to my mailbox, as does any message with a domain part of
> "cnewman.isp.com" (regardless of the local part).

I'm sorry; I got a bit confused there.

> > In some implementations, I can unfortunately imagine the local-part
> > being the only information available.
> >
> > Suppose we consider "local" to mean domain of "", with the @ left out
> > since there's no domain.
> 
> That means the address can't be resolved, because there could be 200
> different mailboxes which receive mail addressed to the local part "cnewman"
> in the same mailstore.  In short, the concept of "local" is meaningless to
> me.  The only concept that might have meaning is "same domain as in RCPT TO
> being processed", but for a given sieve script, that might have many
> different values.

I'm not advocating MUST or SHOULD here.  It's got to be optional, and
will clearly be useless for enlightened implementations that always use
FQDNs.  Unfortunately there's an installed base that might find local
addresses useful.

> > I don't want vacation to trigger because I was
> > bcc'ed on a message also to [email-masked].  If
> > I instruct vacation that "tjs" is an alias for me, I want it to trigger
> > only when the mail is to <tjs>,
> > i.e., no domain at all.
> 
> It sounds like you need a distinguished syntax for "any recipient address
> associated with this sieve script".  So add that (perhaps "<>" would work
> for that).  Then supporting subaddresses, vanity domains and their ilk
> becomes an implementation detail rather than a scripting nightmare.

"Any recipient address associated with this script" is built-in and
already there.

> > I don't think virtual domains are a problem; however, vanity domains may
> > be.
> 
> If [email-masked] and [email-masked] are two different users, then which
> one does "tjs" refer to?

I would expect that "tjs" would refer to the tjs in the SMTP server's
canonical hostname.  If the server is called mail.domain1.com, it refers
to the former; if the server is called vdom.isp.com, "tjs" refers to
neither address.  If the box doesn't have a canonical hostname, or the
box doesn't ever support local email addresses, the script can be
rejected, or the address can be ignored (one of these behaviors should
be specified, and it should be the latter).

If virtual domains are involved, then it is unlikely that anyone can
refer to me as local user "tjs" anyway.

Tim

Date: Mon, 28 Aug 2000 17:16:50 -0700
From: Chris Newman <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

--On Monday, August 28, 2000 16:29 -0700 Tim Showalter <[email-masked]> 
wrote:
> Chris Newman <[email-masked]> writes:
>> Suppose I have the addresses <[email-masked]> and <[email-masked]>
>> which share the same Sieve script?  Does the resolution of a "local"
>> address act differently depending upon which address the message being
>> filtered was sent to?
>
> I don't understand what those addresses indicate in either redirect or
> vacation.  vacation doesn't currently specify that addresses are
> supposed to be wildcards, and that wasn't my intent when I wrote it.

I was using shorthand.  I was suggesting a scenario where <[email-masked]> 
goes to my mailbox, as does any message with a domain part of 
"cnewman.isp.com" (regardless of the local part).

> In some implementations, I can unfortunately imagine the local-part
> being the only information available.
>
> Suppose we consider "local" to mean domain of "", with the @ left out
> since there's no domain.

That means the address can't be resolved, because there could be 200 
different mailboxes which receive mail addressed to the local part 
"cnewman" in the same mailstore.  In short, the concept of "local" is 
meaningless to me.  The only concept that might have meaning is "same 
domain as in RCPT TO being processed", but for a given sieve script, that 
might have many different values.

> I don't want vacation to trigger because I was
> bcc'ed on a message also to [email-masked].  If
> I instruct vacation that "tjs" is an alias for me, I want it to trigger
> only when the mail is to <tjs>,
> i.e., no domain at all.

It sounds like you need a distinguished syntax for "any recipient address 
associated with this sieve script".  So add that (perhaps "<>" would work 
for that).  Then supporting subaddresses, vanity domains and their ilk 
becomes an implementation detail rather than a scripting nightmare.

> I don't think virtual domains are a problem; however, vanity domains may
> be.

If [email-masked] and [email-masked] are two different users, then which 
one does "tjs" refer to?

		- Chris

To: Chris Newman <[email-masked]>
Cc: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: does vacation need to define what an address looks like?
From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 16:29:28 -0700
Lines: 41
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

> --On Tuesday, August 22, 2000 19:08 -0700 Tim Showalter <[email-masked]>
> wrote:
> 
> >> What about local addresses like "tjs" or "ken"?  Is this going to be a
> >> MAY?
> >
> > It probably should be.  I will try and come up with wording real soon.
> 
> Actually, I'd say MUST NOT (but could live with SHOULD NOT).  Every time
> I've seen "local" addresses used anywhere it caused problems down the road.
> 
> 
> What happens when the MTA is upgraded to support multiple virtual domains?
> What about vanity domains?
> 
> 
> Suppose I have the addresses <[email-masked]> and <[email-masked]> which
> share the same Sieve script?  Does the resolution of a "local" address act
> differently depending upon which address the message being filtered was sent
> to?

I don't understand what those addresses indicate in either redirect or
vacation.  vacation doesn't currently specify that addresses are
supposed to be wildcards, and that wasn't my intent when I wrote it.

In some implementations, I can unfortunately imagine the local-part
being the only information available.

Suppose we consider "local" to mean domain of "", with the @ left out
since there's no domain.  I don't want vacation to trigger because I was
bcc'ed on a message also to [email-masked].  If
I instruct vacation that "tjs" is an alias for me, I want it to trigger
only when the mail is to <tjs>,
i.e., no domain at all.

I don't think virtual domains are a problem; however, vanity domains may
be.

Tim

Date: Mon, 28 Aug 2000 16:08:48 -0700
From: Chris Newman <[email-masked]>
To: Tim Showalter <[email-masked]>, Ken Murchison <[email-masked]>
cc: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

--On Tuesday, August 22, 2000 19:08 -0700 Tim Showalter <[email-masked]> 
wrote:
>> What about local addresses like "tjs" or "ken"?  Is this going to be a
>> MAY?
>
> It probably should be.  I will try and come up with wording real soon.

Actually, I'd say MUST NOT (but could live with SHOULD NOT).  Every time 
I've seen "local" addresses used anywhere it caused problems down the road.

What happens when the MTA is upgraded to support multiple virtual domains? 
What about vanity domains?

Suppose I have the addresses <[email-masked]> and <[email-masked]> 
which share the same Sieve script?  Does the resolution of a "local" 
address act differently depending upon which address the message being 
filtered was sent to?

		- Chris

Date: Sun, 27 Aug 2000 15:19:07 -0600
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Ken Murchison <[email-masked]>, [email-masked], Tim Showalter <[email-masked]>
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

I am in favour of keeping both syntaxes, because Ken showed usability of glabal
variable use.

Cyrus Daboo wrote:

> --On 08/24/00 12:12:10 -0400 Ken Murchison <[email-masked]> wrote:
>
> > Ooh, I kind of like this!  So the flags specified with :flags would be
> > the only ones set for that message (as opposed to the union of :flags
> > and the globals), correct?  What if we have some global flags set, but
> > want to fileinto/keep WITHOUT any flags?  Would we do this with
> > something like:
> >
> > keep :flags [];               or
> > keep :flags "";               or
> > keep :flags "None";
>
> We could opt for an IMAP like syntax here:
>
> keep :flags+ [...]  - stored flags are global flags with additional flags
>
> keep :flags- [...]  - stored flags are global flags with some removed
>
> keep :flags [...]   - stored flags are only those listed - global flags are
> ignored

Sometimes you want to use only global flags, so I would rather the following:

keep :globalflags+ [...]  - stored flags are global flags with additional flags

keep :globalflags- [...]  - stored flags are global flags with some removed

keep :globalflags   - use only global flags

keep :flags [...]   - stored flags are only those listed - global flags are
ignored

Alexey

Date: Thu, 24 Aug 2000 17:13:57 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

   From: Tim Showalter <[email-masked]>
   Date: 24 Aug 2000 13:08:24 -0700

[...]
   I believe that if we can choose between setting the default/global flags
   and setting flags on a single keep/fileinto, we should go with a single
   keep/fileinto, and discuss global flags later.

I agree with this.  Variables are the Right way to go on this.

Larry

To: [email-masked]
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
From: Tim Showalter <[email-masked]>
Date: 24 Aug 2000 13:08:24 -0700
Lines: 29
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> > it is conceivable for "library" macros to set flags that there is no
> > reliable way to clear.
> 
> You can always unset all known flags. This is ugly but works.
> I miss test for set flags :-(.

That isn't work; if an include system has set a global flag like
"Youll-never-guess-the-name-of-this-flag-Bz28QzBNF", you can't really
reliably unset it.  This is a degenrate case, but it's still kinda bad.

So the other thing that occurred to me is this, and it kinda scares me:
if we're going to go down the path of global variables, we might as well
have a $default_flags global variable and use that along with :flags.
Something tells me that the operations on lists of stuff are going to be
reasonably constant.

I am not convinced of this, but in light of some comments Patrik
Fältström made, we might want to go down the path of variables anyway.
If we're going to, basic list operations are going to be essential as
well.

I believe that if we can choose between setting the default/global flags
and setting flags on a single keep/fileinto, we should go with a single
keep/fileinto, and discuss global flags later.

Tim

Date: Thu, 24 Aug 2000 13:23:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: [email-masked], Tim Showalter <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

--On 08/24/00 12:12:10 -0400 Ken Murchison <[email-masked]> wrote:

> Ooh, I kind of like this!  So the flags specified with :flags would be
> the only ones set for that message (as opposed to the union of :flags
> and the globals), correct?  What if we have some global flags set, but
> want to fileinto/keep WITHOUT any flags?  Would we do this with
> something like:
>
> keep :flags [];		or
> keep :flags "";		or
> keep :flags "None";

We could opt for an IMAP like syntax here:

keep :flags+ [...]  - stored flags are global flags with additional flags

keep :flags- [...]  - stored flags are global flags with some removed

keep :flags [...]   - stored flags are only those listed - global flags are 
ignored

-- 
Cyrus Daboo

Date: Thu, 24 Aug 2000 12:12:10 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], Tim Showalter <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> --On 08/24/00 09:54:38 -0400 Ken Murchison <[email-masked]> wrote:
> 
> > The upshot of this is that with only one test at the top of my script, I
> > can flag all of the *extremely* important messages from Tim regardless
> > of where they get filed/kept.  If we move the imapflags to an optional
> > argument, I would have to to a test for "tjs" for every fileinto/keep.
> 
> I agree with Ken on this. I think it is useful to be able to set flags
> globally. I also think its useful to be able to set flags on a one-time
> basis for keep and fileinto commands as well. So I would actually argue for
> both forms of imapflags to be available: as a global command and as a
> parameter for fileinto and keep!

Ooh, I kind of like this!  So the flags specified with :flags would be
the only ones set for that message (as opposed to the union of :flags
and the globals), correct?  What if we have some global flags set, but
want to fileinto/keep WITHOUT any flags?  Would we do this with
something like:

keep :flags [];		or
keep :flags "";		or
keep :flags "None";

Hmmm...  By allowing both types (local and global) we're kind of getting
into scopes here, is this going to get too messy?

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

Date: Thu, 24 Aug 2000 11:16:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, [email-masked]
cc: Tim Showalter <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

--On 08/24/00 09:54:38 -0400 Ken Murchison <[email-masked]> wrote:

> The upshot of this is that with only one test at the top of my script, I
> can flag all of the *extremely* important messages from Tim regardless
> of where they get filed/kept.  If we move the imapflags to an optional
> argument, I would have to to a test for "tjs" for every fileinto/keep.

I agree with Ken on this. I think it is useful to be able to set flags 
globally. I also think its useful to be able to set flags on a one-time 
basis for keep and fileinto commands as well. So I would actually argue for 
both forms of imapflags to be available: as a global command and as a 
parameter for fileinto and keep!

-- 
Cyrus Daboo

Date: Thu, 24 Aug 2000 09:54:38 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: Tim Showalter <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

Tim Showalter wrote:
> 
> I may have voiced this before, but I don't remember.
> 
> I believe that the right way to set IMAP flags is by an optional
> argument on the keep and fileinto commands, not a side effect that
> effectively munges a global variable.
> 
> My primary problem with the current approach that this is the first
> Sieve command to have a side effect that affects another action (other
> than the reject vs. keep interaction stuff, which is somewhat more
> minor).  The way this stuff interacts is potentially annoying.  Given
> the existance of tagged optional arguments in the document as is, I
> would prefer a different approach.

I agree with this in principal, and would not be opposed to this change.

However, having implemented the current draft in cmu-sieve and being a
user of the functionality, I'll try to make a (possibly weak) case for
why the global variable concept can be advantageous.  Below is a subset
of a script that I currently use:

require ["fileinto", "imapflags", "subaddress"];

# mark (flag) all messages from Tim Showalter
if address :user "from" "tjs" {
  mark;
}

# file mailing list stuff
if address :localpart :is ["to", "from", "cc", "resent-to"]
"ietf-mta-filters" {
  fileinto "INBOX.ietf.mta-filters";
}
elsif address :localpart :is ["to", "from", "cc", "resent-to"]
"ietf-imapext" {
  fileinto "INBOX.ietf.imapext";
}
elsif address :user :is ["to", "from", "cc", "resent-to"] "info-cyrus" {
  fileinto "INBOX.cyrus";
}

The upshot of this is that with only one test at the top of my script, I
can flag all of the *extremely* important messages from Tim regardless
of where they get filed/kept.  If we move the imapflags to an optional
argument, I would have to to a test for "tjs" for every fileinto/keep.

This is the only use of the global variable concept that I have come
across, so if the consensus is to make the change to an optional
argument, I would be inconvenienced, but not overly disappointed.

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

Date: Thu, 24 Aug 2000 00:22:08 -0600
From: Alexey Melnikov <[email-masked]>
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

Tim Showalter wrote:

> I may have voiced this before, but I don't remember.

> I believe that the right way to set IMAP flags is by an optional
> argument on the keep and fileinto commands, not a side effect that
> effectively munges a global variable.

I like this better but I remeber some objections.
Also it is extremely difficult to explain this "global variable" concept to
non-programmers.

> ...

> Until now, it has always been safe to add code to the bottom of a script
> and assume that that code can stand alone.  However, arbitrary flags can
> be added, and there's no way to figure out what flags are set,

Correct.

> it is conceivable for "library" macros to set flags that there is no
> reliable
> way to clear.

You can always unset all known flags. This is ugly but works.
I miss test for set flags :-(.

> ...

> Incidentially, among the nits in v03, the grammar at the end of the
> document should be removed entirely.  It doesn't match the Sieve grammar
> at all (which doesn't define action, for instance).  It is not
> necessary; the existing Sieve grammar encompasses everything represented
> here.  However, the "Syntax" lines in the base document need to be
> on each command to clarify the types.

I will look at this.

Alexey

Date: Wed, 23 Aug 2000 09:23:37 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

Tim Showalter wrote:
> 
> Ken Murchison <[email-masked]> writes:
> 
> > So are you saying that you want to allow the FULL RFC822 'address' which
> > includes 'group' and 'route', or the modified version that we talked
> > about earlier and I posted previously in this thread?  I ask because
> > when we visited this before IETF you explicitly didn't want to allow
> > groups.
> 
> Uh, let's forbid group and route, and limit it to a single address.  I
> don't remember how to say it in RFC822.

Here's what I came up with and is currently used in Cyrus:

sieve-address   = addr-spec
                / phrase "<" addr-spec ">"

where addr-spec and phrase are as defined in RFC822.

Since I posted this earlier with no comment from anyone, its either
complete shit, nobody read it or nobody has any objections.  Let's
assume the latter :)

> > What about local addresses like "tjs" or "ken"?  Is this going to be a
> > MAY?
> 
> It probably should be.  I will try and come up with wording real soon.

If you want to throw a grammar element at it, it might be something
like:

addr-spec       /= local-part

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

To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
From: Tim Showalter <[email-masked]>
Date: 22 Aug 2000 19:08:45 -0700
Lines: 26
Sender: [email-masked]

Ken Murchison <[email-masked]> writes:

> So are you saying that you want to allow the FULL RFC822 'address' which
> includes 'group' and 'route', or the modified version that we talked
> about earlier and I posted previously in this thread?  I ask because
> when we visited this before IETF you explicitly didn't want to allow
> groups.

Uh, let's forbid group and route, and limit it to a single address.  I
don't remember how to say it in RFC822.  I don't want a single string
containing multiple addresses.

We ignored groups for address (I think) and I believe that's the right
way to go here.

> What about local addresses like "tjs" or "ken"?  Is this going to be a
> MAY?

It probably should be.  I will try and come up with wording real soon.

> Are we going to use the same format for both vacation and redirect?

I've submitted the Sieve spec for last call; I suppose I can take this
as a comment on the draft, and fix the vacation draft to point to it.

Tim

Date: Tue, 22 Aug 2000 20:56:31 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

Tim Showalter wrote:
> 
> The following is not a troll:
> 
> I thought about the format for addresses at some time and I believe that
> we should allow full RFC822 addresses because Sieve implementations are
> required to parse RFC822 addresses anyway.  Anyone who has implmented or
> considered implenting otherwise, please speak up now.  I don't
> particularly care about error handling in this case; anyone who has an
> opinion, please speak up now.

So are you saying that you want to allow the FULL RFC822 'address' which
includes 'group' and 'route', or the modified version that we talked
about earlier and I posted previously in this thread?  I ask because
when we visited this before IETF you explicitly didn't want to allow
groups.

I personally don't care either way, since all I have to do is just
change the start state in the cmu-sieve yacc grammar for addresses :)

What about local addresses like "tjs" or "ken"?  Is this going to be a
MAY?

Are we going to use the same format for both vacation and redirect?

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

To: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
From: Tim Showalter <[email-masked]>
Date: 22 Aug 2000 17:13:27 -0700
Lines: 42
Sender: [email-masked]

I may have voiced this before, but I don't remember.

I believe that the right way to set IMAP flags is by an optional
argument on the keep and fileinto commands, not a side effect that
effectively munges a global variable.

My primary problem with the current approach that this is the first
Sieve command to have a side effect that affects another action (other
than the reject vs. keep interaction stuff, which is somewhat more
minor).  The way this stuff interacts is potentially annoying.  Given
the existance of tagged optional arguments in the document as is, I
would prefer a different approach.

Assume for a moment the existance of either functions or a preprocessor,
both things that have been discussed and are likely to be developed
later.  In either case (they're more or less the same without varibles,
anyway), addflag/removeflag/setflag affect global state, and it may not
be obvious how these things interact.

Until now, it has always been safe to add code to the bottom of a script
and assume that that code can stand alone.  However, arbitrary flags can
be added, and there's no way to figure out what flags are set, it is
conceivable for "library" macros to set flags that there is no reliable
way to clear.

I would prefer if fileinto and keep were extended to take an optional
:flags argument which would describe the flags to be added to the
message, i.e.,

        if header :matches "Subject" "ADV:*" {
                keep :flags "\\Deleted" ;
        }

Incidentially, among the nits in v03, the grammar at the end of the
document should be removed entirely.  It doesn't match the Sieve grammar
at all (which doesn't define action, for instance).  It is not
necessary; the existing Sieve grammar encompasses everything represented
here.  However, the "Syntax" lines in the base document need to be
on each command to clarify the types.

Tim

To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
From: Tim Showalter <[email-masked]>
Date: 22 Aug 2000 14:37:55 -0700
Lines: 22
Sender: [email-masked]

After some conversation, Ken and I have agreed on the following format
for addresses:

All of RFC822 must be parsed; supirous comments are mandatory; phrases
must be specified in Esperanto; all ASCII text must be in ROT-13, and
all non-ASCII text must be in modified UTF-7 with all the letters
printed in the reverse order that they are expected to be displayed in.

I hope this isn't a problem for anyone.

The following is not a troll:

I thought about the format for addresses at some time and I believe that
we should allow full RFC822 addresses because Sieve implementations are
required to parse RFC822 addresses anyway.  Anyone who has implmented or
considered implenting otherwise, please speak up now.  I don't
particularly care about error handling in this case; anyone who has an
opinion, please speak up now.

Tim

Date: Fri, 18 Aug 2000 09:58:45 -0700
To: Cyrus Daboo <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: sieve upload/download mechanisms
Sender: [email-masked]

At 2:16 PM -0400 8/17/00, Cyrus Daboo wrote:

>  I'd like to know what mechanisms server vendors have implemented 
> for sieve script upload/download.

Our prototype code uses the Sieve ACAP profile, which is very easy to 
implement in clients and servers (and upwards-compatible with full 
ACAP).  I've got preliminary code to integrate this into Qpopper.

>
>  I'm aware of systems that use ACAP, HTTP, FTP, LDAP, and CMU's 
> managesieve. Are there any other means of doing this? Would it be 
> possible for server vendors to describe in some detail how their 
> implementations work for interoperability? I wonder if there should 
> be some BCP document about this?

You left out email, which I've been told will be supported in some servers.

I think this should be standardized.  A BCP would work if the 
mechanism is an unmodified existing one, otherwise I think a 
standards-track document is needed.

>
>  The problem is that as a client vendor I need to know how to get 
> scripts uploaded/downloaded to the various servers. I'd rather not 
> have half-a-dozen variants to deal with, but that looks as if it is 
> the case right now.

Exactly.

>  --
>  Cyrus Daboo

To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: sieve upload/download mechanisms
From: Simon Josefsson <[email-masked]>
Date: 17 Aug 2000 21:36:10 +0200
Lines: 18
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:

> I'd like to know what mechanisms server vendors have implemented for
> sieve script upload/download.
> 
> I'm aware of systems that use ACAP, HTTP, FTP, LDAP, and CMU's
> managesieve. Are there any other means of doing this? 

My (unreleased) sieve support for a mail client I'm working on uses
CMU's "installsieve".  I'm not sure if that's the same as managesieve.

(http://www.nada.kth.se/datorer/e-post/sieve-at-nada.shtml describes
usage of installsieve to some detail)

> I'd rather not have half-a-dozen variants to deal with, but that
> looks as if it is the case right now.

Yes. :-/

Date: Thu, 17 Aug 2000 14:16:48 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: sieve upload/download mechanisms
Sender: [email-masked]

I'd like to know what mechanisms server vendors have implemented for sieve 
script upload/download.

I'm aware of systems that use ACAP, HTTP, FTP, LDAP, and CMU's managesieve. 
Are there any other means of doing this? Would it be possible for server 
vendors to describe in some detail how their implementations work for 
interoperability? I wonder if there should be some BCP document about this?

The problem is that as a client vendor I need to know how to get scripts 
uploaded/downloaded to the various servers. I'd rather not have 
half-a-dozen variants to deal with, but that looks as if it is the case 
right now.

-- 
Cyrus Daboo

Date: Fri, 11 Aug 2000 22:16:21 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: does vacation need to define what an address looks like?
Sender: [email-masked]

Tim Showalter wrote:
> 
> Hi.  Ken Murchison pointed out that vacation doesn't define what an
> address is supposed to look like beyond a string.

More specifically, section 2.4.2.3 of [SIEVE] states that addresses must
be compliant with RFC822, but doesn't state what part(s) of RFC822
addresses are accepted (ie, 'address', 'mailbox', 'addr-spec', etc)

BTW, I think this same discussion applies to redirect addresses. 
Hopefully we can decide on a syntax that is consistent for both.

> I am inclined to forbid comments, and define that an address is supposed
> to be only the stuff between the <>s.  I would like to add verbage to
> the draft and state that this is all that's allowed.  Ken thought the
> phrase part might be interesting for GUIs, and I'm not sure how to
> handle that.

My point on this was that some user-friendly script creation tool might
simply pull addresses out of an addressbook (LDAP, MySQL, proprietary,
etc) which most likely would contain a phrase (ie, "Sieve Mailing List
<[email-masked]>").  Since this is what most modern MUAs do, I
don't think we want to prohibit this in scripts.

> Should address allow for a phrase part, or worse, comments?

IMHO, Yes.

> If so, I
> believe only the useful parts (i.e., user@domain) should be significant.

For determining vacation behavior, I agree.

> Ot's probably necessary to allow just user (i.e., no @domain) for
> OSes/MTAs that have concepts of local mail.  I will probably make this a
> SHOULD since it might not be appropriate for some implementations.

I agree.

> If an address is syntactically or semantically bogus, I think the right
> thing to do is to just ignore it, and we probably need text that says
> that, too.

In the context of vacation, this might be a good thing.  But for
redirect, I think the script should be kicked out so that the user knows
that mail can't/won't be redirected to the address(es) in question.  The
problem with two different semantics however is that when parsing a
script we would have to determine address validity based on context.  So
I'd like to use the same semantics for both, if possible.

> I'm looking for a second opinion, especially on the question as to
> whether phrases should be allowed/forbidden.

FWIW, here's what cmu-sieve currently does based on preliminary
discussions Tim and I had before IETF.

-  The grammar for addresses allowed in vacation and redirect is the
following:

sieve-address	= addr-spec
		/ phrase "<" addr-spec ">"

where addr-spec and phrase are as defined in 822.  Note that like 822,
this grammar does NOT prohibit comments.  For those without 822 handy,
this removes the groups and routes.

-  The syntax of the these addresses are checked at parse-time, and if
incorrect, causes the sieve engine to stop processing just like any
other syntax error.

-  When determining whether a message was addressed directly to the
recipient, only the addr-spec part of the :addresses are compared
against the To, Cc, and Bcc headers.

If we want to allow for local addresses as Tim mentions, I would simply
augment the grammar above as follows:

addr-spec	/= local-part

Personally, I think the CMU implementation (shameless plug) provides for
the most flexibility with the least amount of insanity.  This being
said, I'm willing to concede any and all points :^)

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

Date: 11 Aug 2000 16:24:06 -0700
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: does vacation need to define what an address looks like?
Sender: [email-masked]

Hi.  Ken Murchison pointed out that vacation doesn't define what an
address is supposed to look like beyond a string.

I am inclined to forbid comments, and define that an address is supposed
to be only the stuff between the <>s.  I would like to add verbage to
the draft and state that this is all that's allowed.  Ken thought the
phrase part might be interesting for GUIs, and I'm not sure how to
handle that.

Should address allow for a phrase part, or worse, comments?  If so, I
believe only the useful parts (i.e., user@domain) should be significant.

Ot's probably necessary to allow just user (i.e., no @domain) for
OSes/MTAs that have concepts of local mail.  I will probably make this a
SHOULD since it might not be appropriate for some implementations.

If an address is syntactically or semantically bogus, I think the right
thing to do is to just ignore it, and we probably need text that says
that, too.

I'm looking for a second opinion, especially on the question as to
whether phrases should be allowed/forbidden.

Incidentially, I said in Pittsburgh that I had sent in sieve-12 and
vacation-04.  I was wrong; I had sent sieve-12 to myself, and didn't
realize it until way too late.  I may have maligned the I-D editor, but
they were doing a great job as usual.  sieve-12 and vacation-04 are now
in an I-D repository near you.

Tim

Date: Tue, 08 Aug 2000 22:00:04 -0600
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

Ken Murchison wrote:

> Alexey,
>
> A couple nits/comments/questions on your latest draft:
>
> Where's the page breaks and page headers?  :^)

I've decided to add them at the later stage.

> >    #
> >    # Example Sieve Filter
> >    # Declare any optional features or extension used by the script
> >    #
> >    require ["fileinto", "reject", "imapflags"];
>
> Any reason why "reject" is required and mentioned below, but never used?
>
> >    #
> >    # Reject any large messages
> >    #
> >    if size :over 1M
> >            {
> >            if header :is "From" "[email-masked]"
> >                       {
> >                       addflag "\\Flagged $Big";
>
> This should be: addflag ["\\Flagged", "$Big"];

Right.

> >    # The message will be marked as "\Flagged $Big" when filed into mailbox "Big messages"
> >                       }
> >            fileinto "Big messages";
> >            }
> >
> >    if header :is "From" "[email-masked]"
> >            {
> >            addflag ["\\Answered", "$MDNSent"];
> >    # If the message is bigger than 1Mb it will be marked as "\Flagged $Big \Answered $MDNSent"
>
> Unless I'm completely off the mark (and my cmu-sieve implementation is
> incorrect), "\Flagged $Big" will never be set on these messages, because
> these flags are only set 'if header :is "From" "[email-masked]"'.

Correct. Message will be filed into "Big messages" in all cases and only if "from" is
"[email-masked]" two flags will be set.

>  I think you want the first test in the script to be something like:
>
> if size :over 1M
>            {
>            addflag "\\Flagged $Big";
>            if header :is "From" "[email-masked]"
>                       {
>    # The message will be marked as "\Flagged $Big" when filed into
> mailbox "Big messages"
>                       fileinto "Big messages";
>                       }
>            }

Alexey

Date: Tue, 08 Aug 2000 12:10:24 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: draft-melnikov-sieve-imapflags-03.txt
Sender: [email-masked]

Alexey,

A couple nits/comments/questions on your latest draft:

Where's the page breaks and page headers?  :^)

>    #
>    # Example Sieve Filter
>    # Declare any optional features or extension used by the script
>    #
>    require ["fileinto", "reject", "imapflags"];

Any reason why "reject" is required and mentioned below, but never used?

>    #
>    # Reject any large messages
>    #
>    if size :over 1M
>            {
>            if header :is "From" "[email-masked]"
>                       {
>                       addflag "\\Flagged $Big";

This should be: addflag ["\\Flagged", "$Big"];

>    # The message will be marked as "\Flagged $Big" when filed into mailbox "Big messages"
>                       }
>            fileinto "Big messages";
>            }
> 
>    if header :is "From" "[email-masked]"
>            {
>            addflag ["\\Answered", "$MDNSent"];
>    # If the message is bigger than 1Mb it will be marked as "\Flagged $Big \Answered $MDNSent" 

Unless I'm completely off the mark (and my cmu-sieve implementation is
incorrect), "\Flagged $Big" will never be set on these messages, because
these flags are only set 'if header :is "From" "[email-masked]"'.  I
think you want the first test in the script to be something like:

if size :over 1M
           {
           addflag "\\Flagged $Big";
           if header :is "From" "[email-masked]"
                      {
   # The message will be marked as "\Flagged $Big" when filed into
mailbox "Big messages"
                      fileinto "Big messages";
                      }
           }

>    # when filed into mailbox "grandma". If the message is shorter than 1Mb it will be marked as
>    # "\Answered $MDNSent"
>            fileinto "GrandMa";  # move to "GrandMa" folder
>            }
> 

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