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 #2 from holmgren@lysator.liu.se 2007-01-31 17:57 -------
the_item needs to be saved to enable nesting, of course.

--
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


ph10@hermes.cam.ac.uk changed:

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




------- Comment #3 from ph10@hermes.cam.ac.uk 2007-02-06 10:02 -------
I have committed a patch.

--
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 #4 from holmgren@lysator.liu.se 2007-02-06 14:45 -------
Nice. Though in fact I didn't expect you to accept this without discussion. I
see that you have given an example using $recipients in NewStuff. I think
people should be made aware that it won't work if items contain commas. Not
that they usually do, but they *can* - and even if local users don't have
commas in their usernames, there's still local_part_prefix/_suffix. And if
one wants to apply forany/forall to $h_To:, the display-name can also contain
commas.

So I'm still trying to decide which is best: An expansion operator that
converts from an RFC 2822 address-list to a list compatible with
string_nextinlist(); separate conditions (foranyaddress/foralladdresses) that
work with such lists; or perhaps string_nextinlist can simply ignore
separators within quoted strings (treating \" as a literal quote).

--
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 Tue, 6 Feb 2007, holmgren@lysator.liu.se wrote:

> So I'm still trying to decide which is best: An expansion operator that
> converts from an RFC 2822 address-list to a list compatible with
> string_nextinlist(); separate conditions (foranyaddress/foralladdresses) that
> work with such lists; or perhaps string_nextinlist can simply ignore
> separators within quoted strings (treating \" as a literal quote).

The last of those is a bad idea because string_nextinlist is used all
over the place. I wouldn't want it to assume any kind of quoting other
than what it currently has.


--
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 #5 from ph10@hermes.cam.ac.uk 2007-02-06 16:51 -------
On Tue, 6 Feb 2007, holmgren@lysator.liu.se wrote:

> So I'm still trying to decide which is best: An expansion operator that
> converts from an RFC 2822 address-list to a list compatible with
> string_nextinlist(); separate conditions (foranyaddress/foralladdresses) that
> work with such lists; or perhaps string_nextinlist can simply ignore
> separators within quoted strings (treating \" as a literal quote).

The last of those is a bad idea because string_nextinlist is used all
over the place. I wouldn't want it to assume any kind of quoting other
than what it currently has.

--
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 #6 from holmgren@lysator.liu.se 2007-02-06 18:00 -------
Created an attachment (id=64)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=64&action=view)
Add foranyaddress/foralladresses

As another example, this patch adds foranyaddress/foralladdresses conditions.
Note that they unlike the foranyaddress filter condition, the addresses are
*not* automatically extracted - you have to use ${address:...} for that. This
may be confusing, but it allows inspection of the full item, including any
display-name.

Also note that like the foranyaddress filter condition, but unlike
forany/forall, empty items are skipped. This allows easy concatenation of
address fields.

There is one thing I don't like about this solution: I envision further
list-operating expansion items, such as map, reduce, filter, and foreach
(similar to forany, but an expansion item), and having two versions of every
one of them seems ugly.

--
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 #7 from holmgren@lysator.liu.se 2007-02-06 21:53 -------
Created an attachment (id=65)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=65&action=view)
Add conversion operator

And this implements an operator that converts an RFC2822 address-list into a
colon-separated (the separator can be changed in the same way as for the dnsdb
lookup) list, i.e. it changes commas between separate addresses into the
separator and doubles all (other) occurrences of the separator.

The name of the operator would be more apt if it extracted the actual addresses
(automatic ${address:...}), but again I wanted to make the list elements
available in their entirety.

The the separator changing mechanism (example: ${addresses:>,$h_To:}) makes
things a bit insecure unless the separator is always explicitly specified.

--
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 #8 from holmgren@lysator.liu.se 2007-02-07 11:02 -------
Hmmm, would it hurt too much if ${address: ...} always called
parse_extract_address()? Obviously it causes a little bit of overhead when it
wasn't needed.

--
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 #9 from ph10@hermes.cam.ac.uk 2007-02-07 15:31 -------
(In reply to comment #8)
> Hmmm, would it hurt too much if ${address: ...} always called
> parse_extract_address()? Obviously it causes a little bit of overhead when it
> wasn't needed.

As far as I can see, it *does* always call parse_extract_address().

I far prefer the solution of finding a way of converting RFC2822 address lists
rather than having foranyaddress, etc. However, I think the name "addresses" is
too ambiguous. I think something like ${address_list:xxxxx} would be clearer.
I'm thinking about putting that in.

--
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 #10 from holmgren@lysator.liu.se 2007-02-07 15:45 -------
On Wednesday 07 February 2007 16:31, ph10@hermes.cam.ac.uk wrote:
> As far as I can see, it *does* always call parse_extract_address().

It does? Where? When testing, I get:

> ${if match_address {"Magnus Holmgren" <holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}
16:38:12 30499 expanding: "Magnus Holmgren" <holmgren@lysator.liu.se>
16:38:12 30499 result: "Magnus Holmgren" <holmgren@lysator.liu.se>
16:38:12 30499 expanding: *@lysator.liu.se
16:38:12 30499 result: *@lysator.liu.se
16:38:12 30499 address match: subject="magnus holmgren"
<holmgren@lysator.liu.se> pattern=*@lysator.liu.se
16:38:12 30499 lysator.liu.se> in "lysator.liu.se"? no (end of list)
16:38:12 30499 "Magnus Holmgren" <holmgren@lysator.liu.se> in
"*@lysator.liu.se"? no (end of list)
16:38:12 30499 condition: match_address {"Magnus Holmgren"
<holmgren@lysator.liu.se>}{*@lysator.liu.se}
16:38:12 30499 result: false
16:38:12 30499 expanding: yes
16:38:12 30499 result: yes
16:38:12 30499 skipping: result is not used
16:38:12 30499 expanding: no
16:38:12 30499 result: no
16:38:12 30499 expanding: ${if match_address {"Magnus Holmgren"
<holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}
16:38:12 30499 result: no
no

It doesn't work better the other way around either.

> I far prefer the solution of finding a way of converting RFC2822 address
> lists rather than having foranyaddress, etc. However, I think the name
> "addresses" is too ambiguous. I think something like ${address_list:xxxxx}
> would be clearer. I'm thinking about putting that in.

I concur. address_list was that Kjetil T. Homme suggested. But isn't
"addresslist" better, considering the "historical mis-design"?

--
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, 7 Feb 2007, holmgren@lysator.liu.se wrote:

> ------- Comment #10 from holmgren@lysator.liu.se 2007-02-07 15:45 -------
> On Wednesday 07 February 2007 16:31, ph10@hermes.cam.ac.uk wrote:
> > As far as I can see, it *does* always call parse_extract_address().
>
> It does? Where? When testing, I get:
>
> > ${if match_address {"Magnus Holmgren" <holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}

Did I misunderstand? I though you were talking about ${address:
No, I didn't misunderstand. This is what you wrote:

Hmmm, would it hurt too much if ${address: ...} always called
parse_extract_address()? Obviously it causes a little bit of overhead
when it wasn't needed.

As far as match_address goes, I don't see why one would ever want to
supply a full RFC2822 address.

> I concur. address_list was that Kjetil T. Homme suggested. But isn't
> "addresslist" better, considering the "historical mis-design"?

I don't think I really mind, though "addresslist" is already an Exim
technical term, so might be misunderstood. I had considered something
like "regularize_address_list", but that's too long, and
"fix_address_list" is vague.

--
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 #11 from ph10@hermes.cam.ac.uk 2007-02-07 16:29 -------
On Wed, 7 Feb 2007, holmgren@lysator.liu.se wrote:

> ------- Comment #10 from holmgren@lysator.liu.se 2007-02-07 15:45 -------
> On Wednesday 07 February 2007 16:31, ph10@hermes.cam.ac.uk wrote:
> > As far as I can see, it *does* always call parse_extract_address().
>
> It does? Where? When testing, I get:
>
> > ${if match_address {"Magnus Holmgren" <holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}

Did I misunderstand? I though you were talking about ${address:
No, I didn't misunderstand. This is what you wrote:

Hmmm, would it hurt too much if ${address: ...} always called
parse_extract_address()? Obviously it causes a little bit of overhead
when it wasn't needed.

As far as match_address goes, I don't see why one would ever want to
supply a full RFC2822 address.

> I concur. address_list was that Kjetil T. Homme suggested. But isn't
> "addresslist" better, considering the "historical mis-design"?

I don't think I really mind, though "addresslist" is already an Exim
technical term, so might be misunderstood. I had considered something
like "regularize_address_list", but that's too long, and
"fix_address_list" is vague.

--
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 Wednesday 07 February 2007 17:29, Philip Hazel wrote:
> On Wed, 7 Feb 2007, holmgren@lysator.liu.se wrote:
> > ------- Comment #10 from holmgren@lysator.liu.se 2007-02-07 15:45
> > -------
> >
> > On Wednesday 07 February 2007 16:31, ph10@hermes.cam.ac.uk wrote:
> > > As far as I can see, it *does* always call parse_extract_address().
> >
> > It does? Where? When testing, I get:
> > > ${if match_address {"Magnus Holmgren"
> > > <holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}
>
> Did I misunderstand? I though you were talking about ${address:

You didn't RWIM. :-) Of course ${address:...} calls
parse_extract_address() - that's all it's there for.

> As far as match_address goes, I don't see why one would ever want to
> supply a full RFC2822 address.

${if match_address {$h_From:}{+something}} instead of ${if match_address
{${address:$h_From:}}{+something}}. Less typing :-) and a slight compensation
for having to apply ${address_list:} to $h_To: etc. when there is no
foranyaddress/foralladdresses. Unless address_list does extract the
effective addresses instead of merely converting the commas and doubling the
nonseparating colons. But in that case I find the name "addresses"
appropriate, for it does exactly the same thing as ${address:}, but in
plural.

--
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





------- Comment #12 from holmgren@lysator.liu.se 2007-02-07 21:31 -------
On Wednesday 07 February 2007 17:29, Philip Hazel wrote:
> On Wed, 7 Feb 2007, holmgren@lysator.liu.se wrote:
> > On Wednesday 07 February 2007 16:31, ph10@hermes.cam.ac.uk wrote:
> > > As far as I can see, it *does* always call parse_extract_address().
> >
> > It does? Where? When testing, I get:
> > > ${if match_address {"Magnus Holmgren"
> > > <holmgren@lysator.liu.se>}{*@lysator.liu.se}{yes}{no}}
>
> Did I misunderstand? I though you were talking about ${address:

You didn't RWIM. :-) Of course ${address:...} calls
parse_extract_address() - that's all it's there for.

> As far as match_address goes, I don't see why one would ever want to
> supply a full RFC2822 address.

${if match_address {$h_From:}{+something}} instead of ${if match_address
{${address:$h_From:}}{+something}}. Less typing :-) and a slight compensation
for having to apply ${address_list:} to $h_To: etc. when there is no
foranyaddress/foralladdresses. Unless address_list does extract the
effective addresses instead of merely converting the commas and doubling the
nonseparating colons. But in that case I find the name "addresses"
appropriate, for it does exactly the same thing as ${address:}, but in
plural.

--
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, 7 Feb 2007, Magnus Holmgren wrote:

> ${if match_address {$h_From:}{+something}} instead of ${if match_address
> {${address:$h_From:}}{+something}}. Less typing :-)

But strictly invalid, of course, since From: is allowed to contain more
than one address. :-)

> Unless address_list does extract the effective addresses instead of
> merely converting the commas and doubling the nonseparating colons.
> But in that case I find the name "addresses" appropriate, for it does
> exactly the same thing as ${address:}, but in plural.

Maybe that is the best way forward here. It is a nice clean spec. Your
example above then becomes

${if forany{${addresses:$h_from:}}{match_address{$item}{+something}}



--
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/ ##