Am 01.02.21 um 12:10 schrieb Frank Richter via Exim-users:
> Am 16.12.20 um 17:49 schrieb Frank Richter via Exim-users:
>>
>>>
>>> On 12/12/2020 15:30, Jeremy Harris via Exim-users wrote:
>>>> On 12/12/2020 14:46, Frank Richter via Exim-users wrote:
>>>>> It comes from an e-mail with an overlong From: header:
>>>>> From: "…"
>>>>> <PPPPPPPPPPPPPPKKKKKKKKKKKKKKKKKTTTTTTTTTTTTTTTTTTTTTTTTRRRRRRRRRRRRRRRRRRRRRRRRSSSSSSSSSSSSSSSSSSSSSSSSSSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDDDDDDDDDDDDDDDDFFFFFFFFFFFFFFFFFFFFFCCCCCCCCCCCCCCCBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB@…>
>>>>>
>>>>> I'd like to reject such "address monsters". How's the best way to
>>>>> achieve this?
>>>>
>>>> Try a rewrite rule:
>>>>
>>>> ^.{40,}@tuced.eu deny_me@???
>>>>
>>>> before your existing rule. Then a simple match-and-deny in your data ACL:
>>>>
>>>> deny condition = ${if eq {deny_me@???} {${address:$h_from:}}}
>>
>> Thanks.
>>
>> This works for local parts from 40 up to 254 characters. For longer local
>> parts we get the same paniclog:
>> no @ found in the subject of an address list match …
>>
>> So this isn't the proper solution yet.
>
> Has anybody ideas to deny overlong header addresses before rewriting?
> It seems that addresses are truncated to 255 chars. If local part is
> longer than or equal to 255, no @ is found and rewriting panics …
>
> Maybe an option: strict_address_length which denies addresses longer than
> 254 chars, and even local parts longer than 64 chars?
Oh, I see
https://bugs.exim.org/show_bug.cgi?id=2677
https://git.exim.org/exim.git/commitdiff/183389fae10672e8d5ffb1f14f23a179798f483a
Yes, this fixes the problem.
Thanks!
Frank
--
Frank Richter
URZ, Chemnitz University of Technology, Germany
