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 simon+foobar(_at_)josefsson(_dot_)org, 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