headers
Ken Murchison | 8 Aug 2000 18:10

draft-melnikov-sieve-imapflags-03.txt

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" "boss <at> company.com"
>                       {
>                       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";
>            }
>
(Continue reading)

Permalink | Reply | 22 comments |
headers
Alexey Melnikov | 9 Aug 2000 06:00

Re: draft-melnikov-sieve-imapflags-03.txt

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" "boss <at> company.com"
> >                       {
> >                       addflag "\\Flagged $Big";
>
> This should be: addflag ["\\Flagged", "$Big"];

Right.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Showalter | 12 Aug 2000 01:24

does vacation need to define what an address looks like?

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 <at> domain) should be significant.

Ot's probably necessary to allow just user (i.e., no  <at> 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
(Continue reading)

Permalink | Reply | 16 comments |
headers
Ken Murchison | 12 Aug 2000 04:16

Re: does vacation need to define what an address looks like?


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
<ietf-mta-filters <at> imc.org>").  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
(Continue reading)

Permalink | Reply | 15 comments |
headers
Cyrus Daboo | 17 Aug 2000 20:16

sieve upload/download mechanisms

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
Permalink | Reply | 2 comments |
headers
Simon Josefsson | 17 Aug 2000 21:36
Favicon
Gravatar

Re: sieve upload/download mechanisms

Cyrus Daboo <daboo <at> cyrusoft.com> 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. :-/
Permalink | Reply | 0 comments |
headers
Randall Gellens | 18 Aug 2000 18:58

Re: sieve upload/download mechanisms

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Showalter | 22 Aug 2000 23:37

Re: does vacation need to define what an address looks like?

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
Permalink | Reply | 14 comments |
headers
Tim Showalter | 23 Aug 2000 02:13

Re: draft-melnikov-sieve-imapflags-03.txt

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:*" {
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ken Murchison | 23 Aug 2000 02:56

Re: does vacation need to define what an address looks like?


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
(Continue reading)

Permalink | Reply | 13 comments |

Gmane