WJCarpenter wrote:
>> Might you be looking at an artificial situation w/r what Exim takes
>> onboard? IE - entries in a table of recipients that are not themselves
>> in correct format?
>>
>
> Thanks for taking the trouble to poke at this.
No trouble - we have quoted "longname" that need attention as well.
I've set you an example off-list with Chinese characters in it (UTF8).
Our Exim setups handle that fine.
>
> The exact situation is that I sent a test message to a recipient with a
> quoted local part, where the quotes weren't needed. In other words, it
> was an envelope recipient. It showed up in the $recipients variable as
> "iamquoted"@example.com, and the quotes stuck with it even after I
> pulled out the local part via the ${local_part:} and ${address:}
> operators.
I haven't seen quotes persist in the 'wrong' place.
We DO have them preserved in archives in the 'right' place.
> I know that internally Exim must be discarding the quotes
> when it creats $local_part for routers because the message is delivered
> (and in my environment, the local part DB lookups would fail if the
> quotes were present).
>
We happen to bothway-archive with unseen routers, so I just took 'lynx'
into the archive dirtree.
> So, my tentative conclusion is that Exim's internal extraction of
> $local_part has some extra stuff not present in the ${local_part:}
> operator. That seems like a bug, but there could be some obscure reason
> for it.
Not-so-obscure. ISTR Exim has carefully crafted code in *several* places
to try and overcome bad input fomrats or dmamage en-route.
> Perhaps I'll file a bug report and let someone say it's as
> designed if that's the case.
>
More professional to have a look at the code first...
It's written in C, but so nicely done it could have been Forth....
;-)
Bill
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
