Subject: Re: Updated regex and subaddress drafts

From: Peder Stray <[email-masked]>
Date: Sat, 30 Nov 2002 10:02:56 +0100 (MET)

On Fri, 31 Aug 2001, Simon Josefsson wrote:

> On Thu, 30 Aug 2001, Ken Murchison wrote:
>
> > I just submitted updates of the following drafts:
> >
> > http://www.oceana.com/ftp/drafts/draft-murchison-sieve-regex-04.txt
> > http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-03.txt
>
> A comment to both of these drafts:
>
> Back references!
>
> If I receive mail to [email-masked], I may want to file it
> into INBOX.lists.foobar.  I don't want explicit rules for each and every
> foobar.
>
> Same thing goes for regexp, I want to write a regexp that match a header
> "Mailing-Id: (.*)" and file that into "INBOX.lists.\1"

I have to agree... the exim filters has this type of backreferences, and
even though the possibility of a DoS, the benefits from such a constuct is
too great for it to not be included.

I myself would prefer $1, $2 and such insted of \1, \2...

It would also be approptiate to have a construct like $[...] that would
only expand if every variable within the brackets would expand.

For example, if i use " <?([^@>]+)@?([^ \n\t\r>]*)" to mach on the
X-Mailing-List header, $2 may or may not be set, and since i want the
message saved to list.$1.$2 if it is set, or list.$1 if it is not. This
could then be written as "list.$1$[.$2]".

> (The added complexity would be that `fileinto' need to be changed, I
> think.)

It would possibly be easier to just do variable expansion on all strings,
using the variables from the last successful match of a regexp.

If back references are implemented, it would be possible to reduse the
size of filters drastically. I myself use 4 rules in my exim-filter to
deliver into 54 different folders at the moment.

-- 
  Peder Stray

Date: Sat, 30 Nov 2002 10:02:56 +0100 (MET)
From: Peder Stray <[email-masked]>
To: [email-masked]
Subject: Re: Updated regex and subaddress drafts
Sender: [email-masked]

On Fri, 31 Aug 2001, Simon Josefsson wrote:

> On Thu, 30 Aug 2001, Ken Murchison wrote:
>
> > I just submitted updates of the following drafts:
> >
> > http://www.oceana.com/ftp/drafts/draft-murchison-sieve-regex-04.txt
> > http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-03.txt
>
> A comment to both of these drafts:
>
> Back references!
>
> If I receive mail to [email-masked], I may want to file it
> into INBOX.lists.foobar.  I don't want explicit rules for each and every
> foobar.
>
> Same thing goes for regexp, I want to write a regexp that match a header
> "Mailing-Id: (.*)" and file that into "INBOX.lists.\1"

I have to agree... the exim filters has this type of backreferences, and
even though the possibility of a DoS, the benefits from such a constuct is
too great for it to not be included.

I myself would prefer $1, $2 and such insted of \1, \2...

It would also be approptiate to have a construct like $[...] that would
only expand if every variable within the brackets would expand.

For example, if i use " <?([^@>]+)@?([^ \n\t\r>]*)" to mach on the
X-Mailing-List header, $2 may or may not be set, and since i want the
message saved to list.$1.$2 if it is set, or list.$1 if it is not. This
could then be written as "list.$1$[.$2]".

> (The added complexity would be that `fileinto' need to be changed, I
> think.)

It would possibly be easier to just do variable expansion on all strings,
using the variables from the last successful match of a regexp.

If back references are implemented, it would be possible to reduse the
size of filters drastically. I myself use 4 rules in my exim-filter to
deliver into 54 different folders at the moment.

-- 
  Peder Stray

Date: Wed, 06 Nov 2002 16:44:25 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: I-D ACTION:draft-daboo-sieve-spamtest-01.txt (fwd)
Sender: [email-masked]

FYI Announcement below for an update to the spamtest draft. The major 
change in this is a switch to a syntax that allows use of the relational 
extension for numerical comparisons.

------------ Forwarded Message -----------
Date: Wednesday, November 06, 2002 06:29:25 AM -0500
From: [email-masked]
To: IETF-Announce
cc:
Subject: I-D ACTION:draft-daboo-sieve-spamtest-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: SIEVE spamtest and virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-spamtest-01.txt
	Pages		: 6
	Date		: 2002-11-5
	
The SIEVE [SIEVE] 'spamtest' and 'virustest' extensions permit users
to use simple, portable commands for spam and virus tests on email
messages.  Each extension provides a new test using matches against
numeric 'scores'.  It is the responsibility of the underlying SIEVE
implementation to do the actual checks that result in values
returned by the tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-spamtest-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-spamtest-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---------- End Forwarded Message ----------

-- 
Cyrus Daboo