Szerző: Konstantin Boyandin Dátum: Címzett: Jeremy Harris, exim-users Tárgy: Re: [exim] Exim 4.86: errors when trying to process incoming email
with filter
Hello Jeremy,
On 01/23/2016 11:30 PM, Jeremy Harris wrote: > On 23/01/16 01:10, Konstantin Boyandin wrote:
>> Hello Evgeniy,
>>
>> On 01/22/2016 01:54 PM, Evgeniy Berdnikov wrote:
>>> On Fri, Jan 22, 2016 at 10:13:06AM +0600, Konstantin Boyandin wrote:
>>>> Two questions:
>>>>
>>>> 1. Is it required to enclose the $header* in quote marks before
>>>> passing to the script?
>>>
>>> Look at chapter 11 of documentation for description of ${run{...}},
>>> there is a complete answer.
>>>
>>>> Looks like Exim decodes KOI8-R encoded parts
>>>> of the headers and tries to pass them as they are.
>>>
>>> Yes, $header_<name> ($h_<name>) functions do some decoding.
>>> Look for $rh_<name> and $bh_<name> in the same chapter 11.
>>
>> Thanks for the directions. Using "raw" format looks optimal workaround,
>> since I don't need text parts anyway, only email addresses.
>>
>> However, I was wondering why Exim signalled "Too many arguments..."
>> error (location: src/transport.c, function transport_set_up_command)
>> when expanding arguments.
>
> As the docs say, the command and args for ${run } are split into
> arguments by spaces. So if one of your headers had things in
> it that looked like spaces, it would be chopped into multiple
> actual args. This could easily result in "too many args" -
> as well as not being what you wanted to be given to your
> script.
I see the problem is in "looked like spaces" issue.
> If you wrap the $h_<name> in doublequotes (") then spaces embedded
> in its expansion don't matter. Of course, now doublequotes do...
> If this an issue for your use-case, consider using the ${quote: }
> operator.
That's complicated. After checking combinations, I preferred to pass the
unexpanded data ($rheader_*) to the script; it's simpler to expand them
inside, than to juggle escaping combinations, to both satisfy the script
and prevent Exim from failing due to the mention error.
The original version of the filter worked for years, until one
particular email message caused the error, preventing it from being
delivered.
