Mailing List Archive

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #14 from kjetilho@ifi.uio.no 2007-02-09 16:28 -------
I think it is fine that addresses extracts the actual addresses. if we need to
access display name etc., we can add an full_addresses when the need arises?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #15 from holmgren@lysator.liu.se 2007-02-09 20:13 -------
Created an attachment (id=67)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=67&action=view)
New "addresses" operator

This version calls parse_extract_address() for each address.

I don't know if it is really necessary to be able to change the separator when
we take care to double it inside addresses (the dnsdb lookup does in fact *not*
double its separator inside list items).

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #16 from bugzilla.exim.simon@arlott.org 2007-02-10 19:44 -------
I'd like a ${map{<string1>}{<string2>}} to convert a list of recipients to a
list of numbers, and then a way to find the minimum/maximum of that list... so
I can avoid this mess:

set acl_m1 = \
# figure out the maximum score
${perl{compute_score}{\
# convert the list of recipients into a list of spam rejection
scores
${expand:\
# <start>
\N${sg{\N\
# </start>
${sg{${lc:$recipients}}{, }{\\N\
# <end>
\N}{^(.*)@(.*)\$}{\N\

\N\$\{lookup\{\$2\}lsearch\{/etc/exim/conf/domains\}\{\N\

\N\$\{lookup\{\$1\}partial0-lsearch\{/etc/exim/conf/\$2/acls\}\{\N\

\N\$\{lookup\{\$value\}lsearch*\{/etc/exim/conf/acls/spam\}\{\N\

\N\$\{extract\{reject\}\{\$value\}\{\$value\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N}}\N\
# </end>
\N \N\
# <start>
\N${sg{\N\
# </start>
\\N}}\
# <end>
\N}{^(.*)@(.*)\$}{\N\
\N\$\{lookup\{\$2\}lsearch\{/etc/exim/conf/domains\}\{\N\

\N\$\{lookup\{\$1\}partial0-lsearch\{/etc/exim/conf/\$2/acls\}\{\N\

\N\$\{lookup\{\$value\}lsearch*\{/etc/exim/conf/acls/spam\}\{\N\

\N\$\{extract\{reject\}\{\$value\}\{\$value\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N\}\{0\}\}\N\
\N}}\N\
# </end>
}\
}}

I wouldn't suggest trying to understand that, but it does work. It uses lsearch
to find the acl name for a recipient spam score and then finds the reject score
to use. I had to resort to perl to figure out which value was the maximum.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #17 from holmgren@lysator.liu.se 2007-02-10 19:55 -------
Created an attachment (id=68)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=68&action=view)
An attempt at map and filter (should perhaps be called map_list and
filter_list)

${map {<list>}{<expression>}} iterates over <list>, setting $item to each list
element, and returns a list consisting of the results of the expansions of
<expression>. Forced expansion failure causes the element to be simply deleted.

${filter {<list>}{<condition>}} similarly iterates over <list>, keeping those
elements for which <condition> evaluates true.

The new list uses the same separator as the original one (but with no "<;" at
the beginning).

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458


holmgren@lysator.liu.se changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #68 is|0 |1
obsolete| |




------- Comment #18 from holmgren@lysator.liu.se 2007-02-10 23:27 -------
Created an attachment (id=69)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=69&action=view)
Now with "reduce" too.

${reduce {<list>}{<start>}{<expr>}} reduces a list to a scalar value by
combining two values at a time. I borrow $value for the running value; it is
initially set to <start>, then for each list element, $item is set to it like
before, and then $value is updated to the value of <expr>. If expansion of
<expr> is forced to fail, the item is simply skipped. Summation can be
implemented as ${reduce {<list>}{0}{${eval:$value+$item}}} and "max" as
${reduce {<list>}{0}{${if >{$item}{$value}{$item}{$value}}}} (if all items are
positive).

Now to solve Simon's problem...

${reduce
{${map {${addresses:$recipients}}
{${lookup {${domain:$item}}lsearch{/etc/exim/conf/domains}
{${lookup {${local_part:$item}}partial0-lsearch
{/etc/exim/conf/${domain:$item}/acls}
{${lookup {$value}lsearch*
{/etc/exim/conf/acls/spam}
{${extract
{reject}{$value}{$value}{0}}}
{0}}}
{0}}}
{0}}}
}}
{0}
{${if >{$item}{$value}{$item}{$value}}}
}

(Line-continuation backslashes omitted.)

Slightly better, I'd say, if it works.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #19 from kjetilho@ifi.uio.no 2007-02-11 03:46 -------
I like map/filter/reduce very much!

(In reply to comment #18)

> {${map {${addresses:$recipients}}

so ${addresses:} will accept space delimited addresses? looks like it from a
quick glance at the patch. I'm a bit worried about syntactically incorrect
headers being misparsed, e.g.:

To: someone@example.com <someone@example.com>

this is a violation of RFC 2821 (a display name can't be a mail address without
quoting), but the code will parse $h_To: as a list of two addresses. I would
prefer it if ${addresses explicitly used commas to separate the elements.

ideally, Exim should be able to see that $recipients is used in a list context
(to use Perl terminology) so that you don't need the extra call. or perhaps

${map {< $recipients} ...}

to tell ${map that the list is space separated, or do we need a ${split for
this? btw, ${join can be implemented trivially with ${reduce :-)

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #20 from bugzilla.exim.simon@arlott.org 2007-02-11 09:49 -------
expand.c: In function ‘expand_string_internal’:
expand.c:4680: error: ‘iterate_item’ undeclared (first use in this function)
expand.c:4680: error: (Each undeclared identifier is reported only once
expand.c:4680: error: for each function it appears in.)

It looks like you've renamed the_item to iterate_item without updating any
patches.

Also, you have some tabs indenting making it hard to read.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #21 from bugzilla.exim.simon@arlott.org 2007-02-11 17:32 -------
> ${reduce{1 2 3 4 5}{0}{${if >{$item}{$value}{$item}{$value}}}}
Segmentation fault

That shouldn't happen...

Your suggested code works though :)

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #22 from holmgren@lysator.liu.se 2007-02-11 18:55 -------
On Sunday 11 February 2007 04:46, kjetilho@ifi.uio.no wrote:
> ------- Comment #19 from kjetilho@ifi.uio.no 2007-02-11 03:46 -------
> I like map/filter/reduce very much!
>
> (In reply to comment #18)
>
> > {${map {${addresses:$recipients}}
>
> so ${addresses:} will accept space delimited addresses? looks like it from
> a quick glance at the patch.

No, that is not my intention, and I don't think it is the case. ${addresses:}
uses parse_find_address_end() and parse_extract_address(), which should parse
RFC 2822 address lists correctly. And $recipients is comma-delimited.

> ideally, Exim should be able to see that $recipients is used in a list
> context (to use Perl terminology) so that you don't need the extra call.

I hope that that's how it will work in Exim 5...

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #23 from holmgren@lysator.liu.se 2007-02-11 19:09 -------
On Sunday 11 February 2007 10:49, bugzilla.exim.simon@arlott.org wrote:
> expand.c: In function ‘expand_string_internal’:
> expand.c:4680: error: ‘iterate_item’ undeclared (first use in this
> function) expand.c:4680: error: (Each undeclared identifier is reported
> only once expand.c:4680: error: for each function it appears in.)
>
> It looks like you've renamed the_item to iterate_item without updating any
> patches.

Philip renamed the_item to iterate_item before committing the forany/forall
patch. The newer patches apply against the current CVS snapshot.

> Also, you have some tabs indenting making it hard to read.

That will be fixed before the check-in, I promise! :-)

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458


holmgren@lysator.liu.se changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #67 is|0 |1
obsolete| |
Attachment #69 is|0 |1
obsolete| |




------- Comment #24 from holmgren@lysator.liu.se 2007-02-12 00:00 -------
Created an attachment (id=70)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=70&action=view)
Updated map, filter, reduce, and addresses

I've corrected error handling a bit, which seems to have got rid of the
segfault. On second thought I don't think forced expansion failure should be
caught here, so I removed that. I also corrected the way lists are built.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

I really think we should get rid of the gratuitous braces. That could be done
without breaking compatibility, but requires huge modifications to expand.c.

Look how much more readable this is:

> ${reduce
> ${map ${addresses:$recipients}
> ${lookup {${domain:$item}}lsearch{/etc/exim/conf/domains}
> ${lookup ${local_part:$item} partial0-lsearch
> {/etc/exim/conf/${domain:$item}/acls}
> ${lookup $value lsearch* {/etc/exim/conf/acls/spam}
> ${extract {reject}{$value}{$value}{0}}
> 0}
> 0}
> 0}
> }
> 0
> ${if >{$item}{$value}{$item}{$value}}
> }

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458


ph10@hermes.cam.ac.uk changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED




------- Comment #25 from ph10@hermes.cam.ac.uk 2007-02-14 15:04 -------
(In reply to comment #24)
> Created an attachment (id=70)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=70&action=view) [details]
> Updated map, filter, reduce, and addresses

I have committed a patch which I have only changed in trivial ways: mainly some
formatting to suit my prejudices, and added some more comments. However, I also
made a change to remove the redundant separator at the ends of lists. Apart
from looking nicer, it means that ${filter{....}{a "true" condition}} will
generate the same output as its input. Oh, and I moved save_lookup so that it
always gets initialized and so stops gcc complaining.

One final point: I've left it so that a syntactically bad address is ignored by
${addresses - and documented that. I think it is probably the best thing, but
it could be an issue.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #26 from holmgren@lysator.liu.se 2007-02-14 15:31 -------
On Wednesday 14 February 2007 16:04, ph10@hermes.cam.ac.uk wrote:
> However, I also made a change to remove the redundant separator at the ends
> of lists. Apart from looking nicer, it means that ${filter{....}{a "true"
> condition}} will generate the same output as its input.

But string_nextinlist() trims leading and trailing whitespace, meaning that
the the output will be (exactly) the same as the input only in a special
case.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On Wed, 14 Feb 2007, holmgren@lysator.liu.se wrote:

> But string_nextinlist() trims leading and trailing whitespace, meaning that
> the the output will be (exactly) the same as the input only in a special
> case.

Oh, OK, but it still looks nicer! (And who is to say that the output is
in fact to be processed by string_nextinlist(), which ignores the
empty trailing item? It may be being used for something else.)

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=458





------- Comment #27 from ph10@hermes.cam.ac.uk 2007-02-14 15:50 -------
On Wed, 14 Feb 2007, holmgren@lysator.liu.se wrote:

> But string_nextinlist() trims leading and trailing whitespace, meaning that
> the the output will be (exactly) the same as the input only in a special
> case.

Oh, OK, but it still looks nicer! (And who is to say that the output is
in fact to be processed by string_nextinlist(), which ignores the
empty trailing item? It may be being used for something else.)

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##