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?
Frank
--
Frank Richter
URZ, Chemnitz University of Technology, Germany
