Re: [exim] canonical local_part from an address

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"@???, 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