------- 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 <[email protected]> 2012-11-01 16:18:01 --- An address that exim will accept can consist of either of these: "user name" <[email protected]> (quoted) user name <[email protected]> (bare user name) [email protected] (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. [email protected] <[email protected]> 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: [email protected] <[email protected]> to todd.ivenue.com <[email protected]> It also leaves alone: "[email protected]" <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
