Subject: sms notification

From: serj <[email-masked]>
Date: Fri, 24 Dec 2004 18:49:21 +0200

does somebody use sms notification in sieve?

---

From: serj <[email-masked]>
Date: Sat, 25 Dec 2004 15:15:25 +0200

yes, i saw it.
but i didnt find sms notification methods even in sieve sources

Alexey Melnikov wrote:

> serj wrote:
> I think some implementations of the Notify Sieve extension 
> (http://www.oceana.com/ftp/drafts/draft-martin-sieve-notify-01.txt) 
> use SMS.
>
>
> .
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 25 Dec 2004 13:13:49 +0000

I think some implementations of the Notify Sieve extension 
(http://www.oceana.com/ftp/drafts/draft-martin-sieve-notify-01.txt) use SMS.

---

From: Tony Hansen <[email-masked]>
Date: Sat, 25 Dec 2004 13:48:05 -0500

Whose sieve sources? Remember, this mailing list is about the sieve 
protocol and its extensions. Individual implementations may or may not 
implement any or all of the extensions. Given that this particular draft 
was never published as an RFC, it's not surprising you didn't find an 
implementation of it in the sources you happened to look at.

	Tony

---

From: Matthew Elvey <[email-masked]>
Date: Sun, 26 Dec 2004 12:32:01 -0800

>>>> does somebody use sms notification in sieve?
Fastmail.fm offers an SMS option that's triggered via non-standard 
SIEVE, IIRC:
http://www.emailaddresses.com/forum/showthread.php?s=&threadid=30843&highlight=SMS

Date: Sun, 26 Dec 2004 12:32:01 -0800
From: Matthew Elvey <[email-masked]>
Cc: serj <[email-masked]>, [email-masked]
Subject: Re: sms notification
Sender: [email-masked]

>>>> does somebody use sms notification in sieve?
Fastmail.fm offers an SMS option that's triggered via non-standard 
SIEVE, IIRC:
http://www.emailaddresses.com/forum/showthread.php?s=&threadid=30843&highlight=SMS

Date: Sat, 25 Dec 2004 13:48:05 -0500
From: Tony Hansen <[email-masked]>
To: serj <[email-masked]>
CC: [email-masked]
Subject: Re: sms notification
Sender: [email-masked]

	Tony

>> (http://www.oceana.com/ftp/drafts/draft-martin-sieve-notify-01.txt) 

Date: Sat, 25 Dec 2004 15:15:25 +0200
From: serj <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: sms notification
Sender: [email-masked]

yes, i saw it.

> (http://www.oceana.com/ftp/drafts/draft-martin-sieve-notify-01.txt) 

Date: Sat, 25 Dec 2004 13:13:49 +0000
From: Alexey Melnikov <[email-masked]>
To: serj <[email-masked]>
CC: [email-masked]
Subject: Re: sms notification
Sender: [email-masked]

Date: Fri, 24 Dec 2004 18:49:21 +0200
From: serj <[email-masked]>
To: [email-masked]
Subject: sms notification
Sender: [email-masked]

Date: Tue, 21 Dec 2004 12:04:31 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Working Group Last Call on draft-ietf-sieve-variables-00.txt
Sender: [email-masked]

I would like to solicit your attention to the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-00.txt

I've sent few editorial suggestions to the author, but I don't think 
they should delay the WGLC any further.
The WGLC starts today. Due to winter holiday season it would last for 4 
weeks, i.e. till January 18th.
And I hope that Tim can submit 3028bis before that, so that the WG has 
time to check if there are any interactions between the two documents.

Alexey
Sieve WG co-chair.

Subject: Re: Checking Status of Other Messages?
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], "Felix E. Klee" <[email-masked]>
Date: Sat, 11 Dec 2004 15:22:26 +0100
Sender: [email-masked]

On lør, 2004-12-11 at 13:07 +0100, Arnt Gulbrandsen wrote:
> Kjetil Torgrim Homme writes:
> > not sure if that is in scope or not, but I don't think a proposal must 
> > be rejected on that basis. however, no other Sieve mechanism depends 
> > on anything but the message itself.
> 
> Doesn't the spamfilter proposal pull in an open-ended set of other data 
> sources?

the location of external data and how it should be used is hardcoded in
the implementation, the script has no influence on this.  that's my
reading of the draft, anyway.

to satisfy pedantry :-), s/depends on/references/
-- 
Kjetil T.

Date: Sat, 11 Dec 2004 13:07:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Checking Status of Other Messages?
Cc: "Felix E. Klee" <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

Kjetil Torgrim Homme writes:
> not sure if that is in scope or not, but I don't think a proposal must 
> be rejected on that basis. however, no other Sieve mechanism depends 
> on anything but the message itself.

Doesn't the spamfilter proposal pull in an open-ended set of other data 
sources?

Arnt

Subject: Re: Checking Status of Other Messages?
From: Kjetil Torgrim Homme <[email-masked]>
To: "Felix E. Klee" <[email-masked]>
Cc: [email-masked]
Date: Sat, 11 Dec 2004 09:30:33 +0100
Sender: [email-masked]

On lør, 2004-12-11 at 03:48 +0100, Felix E. Klee wrote:
> are there any Sieve extensions that allow retrieving information about other
> messages on an IMAP server?  If not, would such extensions be possible.

not sure if that is in scope or not, but I don't think a proposal must
be rejected on that basis.  however, no other Sieve mechanism depends on
anything but the message itself.

> To be specific, I'd like to have an extension that allows me to check whether
> any of the messages mentioned in the "References:"-header are flagged.

that's not a very general feature, is it?

one other obstacle is that Sieve has no method for iterating over the
IDs in References.  (In-Reply-To may be a better header to check.)

-- 
Kjetil T.

Date: Sat, 11 Dec 2004 03:48:34 +0100
From: "Felix E. Klee" <[email-masked]>
To: [email-masked]
Subject: Checking Status of Other Messages?
Sender: [email-masked]

Hi,

are there any Sieve extensions that allow retrieving information about other
messages on an IMAP server?  If not, would such extensions be possible.

To be specific, I'd like to have an extension that allows me to check whether
any of the messages mentioned in the "References:"-header are flagged.

Felix

Subject: Re: possible? Convert inline PGP to MIME with sieve?
From: Kjetil Torgrim Homme <[email-masked]>
To: Denny Schierz <[email-masked]>
Cc: [email-masked]
Date: Thu, 09 Dec 2004 16:39:45 +0100
Sender: [email-masked]

On 2004-12-09 at 12:25 +0100, Denny Schierz wrote:
> we're using a cyrus-postfix-mysql-system and we want to convert the old
> style pgp mails, into the new MIME "standard". Normal, its prossible via
> procmail, but it takes so much power, so i asking, if it is possible to
> do that with sieve.
> 
> is it?

Sieve can't modify messages at all.  (there is an extension for adding
or removing extra headers coming soon, that's it.)

-- 
Kjetil T.

Date: Thu, 09 Dec 2004 07:20:59 -0800 (PST)
From: [email-masked]
Subject: Re: possible? Convert inline PGP to MIME with sieve?
To: Denny Schierz <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> we're using a cyrus-postfix-mysql-system and we want to convert the old
> style pgp mails, into the new MIME "standard". Normal, its prossible via
> procmail, but it takes so much power, so i asking, if it is possible to
> do that with sieve.

> is it?

No. Simply put, this is not what sieve is for. Sieve is a mail filtering
language; it provides various constructs to test various aspects of
messages and various constructs to specify how a message should be handled.
It does not provide mechanisms to modify message content. So, while you
could in theory use sieve to test to see if a message was in the old
pgp format (assuming the yet-to-be-standardized body extension was
present), there's no way to perform the conversion you're after. That's
going to require a special sort of conversion program.

				Ned

Subject: possible? Convert inline PGP to MIME with sieve?
From: Denny Schierz <[email-masked]>
To: [email-masked]
Date: Thu, 09 Dec 2004 12:25:26 +0100
Sender: [email-masked]

--=-ecDhQiqHR/LeJxtJER3K
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

hi,

we're using a cyrus-postfix-mysql-system and we want to convert the old
style pgp mails, into the new MIME "standard". Normal, its prossible via
procmail, but it takes so much power, so i asking, if it is possible to
do that with sieve.

is it?

cu denny

--=20
Denny Schierz <[email-masked]>

--=-ecDhQiqHR/LeJxtJER3K
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-ecDhQiqHR/LeJxtJER3K--

Date: Mon, 6 Dec 2004 10:35:52 +0000
From: Tony Finch <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Kjetil Torgrim Homme <[email-masked]>, Tony Finch <[email-masked]>, [email-masked]
Subject: Re: matching bounce messages
Sender: [email-masked]

On Sun, 5 Dec 2004, Tim Showalter wrote:
>
> I suspect that the brackets are being treated as part of the path.
> (I don't know what Cyrus does in this case.)

No, it doesn't treat the brackets as part of the path, otherwise you
would have to include them if the return path is not null, which is not
the case. As expected, testing shows the following does not work:

        if envelope :is "from" "<>"

Tony.
--
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE: WEST OR SOUTHWEST 3 OR 4 INCREASING 5 OR 6. FAIR. MODERATE OR GOOD.

Date: Sun, 05 Dec 2004 19:56:41 -0800
From: Tim Showalter <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: matching bounce messages
Sender: [email-masked]

Kjetil Torgrim Homme wrote:
> ok, perhaps it should be a bit more careful in use of terminology and
> say "reverse-path address" instead of "FROM address" (to remove all
> doubt about what happens to extra parameters on MAIL FROM).  it also
> would be nice if it was explicit about what to do with the surrounding
> brackets, even though formally, the brackets are not part of
> reverse-path.

I suspect that the brackets are being treated as part of the path.  The 
spec should probably clarify that this is not the desired behavior, and 
the brackets are just decorative parts of the syntax.

(I don't know what Cyrus does in this case.)

Tim

Subject: Re: matching bounce messages
From: Kjetil Torgrim Homme <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Date: Sun, 05 Dec 2004 08:11:48 +0100
Sender: [email-masked]

On man, 2004-11-29 at 18:19 +0000, Tony Finch wrote:
> We're using the CMU Cyrus Sieve implementation. A few of our more advanced
> users have asked how to identify bounce messages in a Sieve script. The
> obvious doesn't work:
> 
> 	if envelope :is "from" ""

seems like a bug to me.

> The best phrasing we have seen is
> 
> 	if not envelope :contains "from" "@"
> 
> which is a rather ugly circumlocution. RFC 3028 doesn't say anything about
> null return paths, which is clearly an omission. As a result the Cyrus
> behaviour is hard to classify as a bug.

I don't see why RFC 3028 needs to mention that case explicitly.

   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL
   command.

ok, perhaps it should be a bit more careful in use of terminology and
say "reverse-path address" instead of "FROM address" (to remove all
doubt about what happens to extra parameters on MAIL FROM).  it also
would be nice if it was explicit about what to do with the surrounding
brackets, even though formally, the brackets are not part of
reverse-path.

-- 

Subject: Re: I-D ACTION:draft-ietf-sieve-variables-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Sun, 05 Dec 2004 08:03:21 +0100
Sender: [email-masked]

On tir, 2004-11-30 at 14:14 +0000, Alexey Melnikov wrote:
> Few comments/questions after reviewing the document:
> 
> 1). Is the first parameter of the STRING test (list of variable names) 
> has to be "expanded"?

yes, it's a list of strings, not a list of variable names.

  test "a" "a"

this doesn't reference any variables, and is always true.

you can exploit this when using a variable as a set, ie. as an
enumeration of properties, "blue important filed".

  test :matches " ${var} " "* filed *"

the added spaces means "filed" will be found even if the property is the
last to be listed.

I'll add an example or two to the draft.

> 2). ABNF (or RFC 3028 "Syntax:" line) for MODIFIER is missing.

good catch.

> Also, I have an editorial suggestion. Section 5. ("Action set") doesn't 
> mention modifiers at all, instead there is a subsection 5.1 for them

(hmm, section 0 seems to have been renumbered to 1 in this draft, I'll
revert that.)

> I would suggest to add the following sentence to section 5:
> 
>    Modifiers are applied on a value before it is stored in the variable.
>    Modifier names are case insensitive. For more information see section 5.1
> 
> And drop the first 2 sentences at the top of 5.1.

I'll give it a go :-)

-- 

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 2 Dec 2004 17:32:27 -0500
To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

On Tue, Nov 30, 2004 at 09:38:15PM -0500, Matthew Elvey wrote:
> In order to move forward since the discussion of this draft at the last BOF:
> 
> I would like to gauge interest. Which SIEVE
> implementations/implementors 'intend' to write code to support some
> IETF-blessed extension in order to provide a "Reject before delivery
> capability" (e.g. draft-elvey-refuse-sieve or a derivative)?  
> Currently, no implementations have this ability.
> 
> Please indicate your interest! (e.g. Edit the wiki page mentioned below 
> (put an "i" in the right place) or reply to me and I'll make the edit for 
> you.)
> 
> ('Intend' just indicates strong interest, it doesn't mean "Guarantee by x 
> date")

I'm quite interested in the capability in SIEVE of indicating refusal at
SMTP time.  My own implementation is not capable of supporting that at
present, since it's not integrated with any SMTP server in a way that
would allow it, but that kind of integration is on the wish list..

As for the details, well, that's where the fun is :-)

mm

Date: Wed, 01 Dec 2004 18:02:51 -0500
From: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt;	http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

On 12/1/2004 10:43 AM, [email-masked] sent forth electrons to 
convey:

>
>
>> In order to move forward since the discussion of this draft at the 
>> last BOF:
>
>
>> I would like to gauge interest. Which SIEVE
>> implementations/implementors 'intend' to write code to support some
>> IETF-blessed extension in order to provide a "Reject before delivery
>> capability" (e.g. draft-elvey-refuse-sieve or a derivative)?
>
>
> We certainly plan to support whatever is standardized.

Great. We = Sun.Innosoft?  What Sieve implementations?

>
>> Currently, no implementations have this ability.
>
>
> Actually, ours already does, abeit through the use of nonstandard 
> actions. I
> have to say I find this capability to be quite valuable in practice.

Cool.  A pointer to or copy of docs of this feature would be nice to have.

>
>> Please indicate your interest! (e.g. Edit the wiki page mentioned 
>> below (put
>> an "i" in the right place) or reply to me and I'll make the edit for 
>> you.)
>
>
> I note in passing that the page you cite doesn't have columns for 
> either the
> PMDF or the Sun sieve implementations. 

You seem to have missed the third column (which was the fourth column 
'till today)

> I certainly can provide information
> about what Sun does or does not implement.

Please do and I'll make the edits for you. (the table is hard to edit.)
Also, do you get that the page is part of a wiki?
http://wiki.fastmail.fm/wiki/index.php/WikiWikiWeb
Please include links.  I don't get whether PDMF is a Sun implementation 
or not; please explain when you email me.  Sun owns innosoft, which made 
PDMF...

Date: Wed, 01 Dec 2004 07:43:13 -0800 (PST)
From: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> In order to move forward since the discussion of this draft at the last BOF:

> I would like to gauge interest. Which SIEVE
> implementations/implementors 'intend' to write code to support some
> IETF-blessed extension in order to provide a "Reject before delivery
> capability" (e.g. draft-elvey-refuse-sieve or a derivative)?

We certainly plan to support whatever is standardized.

> Currently, no implementations have this ability.

Actuaally, ours already does, abeit through the use of nonstandard actions. I
have to say I find this capability to be quite valuable in practice.

> Please indicate your interest! (e.g. Edit the wiki page mentioned below (put
> an "i" in the right place) or reply to me and I'll make the edit for you.)

I note in passing that the page you cite doesn't have columns for either the
PMDF or the Sun sieve implementations. I certainly can provide information
about what Sun does or does not implement.

					Ned