------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1150
--- Comment #5 from Todd Lyons <tlyons@???> 2012-11-01 16:18:01 ---
An address that exim will accept can consist of either of these:
"user name" <user@???> (quoted)
user name <user@???> (bare user name)
user@??? (bare email)
During the parsing of the bare user name, if an @ sign is found, the parser
assumes that the bare part is a bare email address. So the following form will
always fail to be extracted properly because it sees it as two email addresses
incorrectly separated by a space instead of a comma.
user@??? <user@???>
Let me qualify this. I don't like the particular solution I propose below.
"sg" is an inadequate substitution for a properly tuned parser. Having said
that...
A simple, though not really straightforward, fix is to use sg to alter the
string so that it doesn't match the parsing for the @ sign any more.
I changed:
${domain:${extract{1}{:}{${addresses:%s}}}}
to
${domain:${extract{1}{:}{${addresses:${sg{%s}{([^\"]\\S+)@(\\S+[^\"])
(<\\S+@\\S+>)}{\$1.\$2 \$3}}}}}}
It converts:
todd@??? <todd@???>
to
todd.ivenue.com <todd@???>
It also leaves alone:
"todd@???" <todd@???>
In both cases it properly extracts the email from within the <> anchors. It
also works for multiple username/emails and multiply formatted username/emails.
I really would like a suggestion of a better way to do this though. Again,
"sg" is not a substitution for a proper parser.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
