Heiko Schlittermann via Exim-users wrote on 23.02.2025 14:10:
> Viktor Ustiuhov via Exim-users <[email protected]> (So 23 Feb 2025
> 11:49:10 CET):
>> Heiko Schlittermann via Exim-users wrote on 23.02.2025 11:13:
>>>
>>> X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.2.5\r\n
>>> |<---- $h_x-bogosity: --------------------------------->|
>>> |<----- $rh_x-bogosity: ------------------------------------>|
>>>
>>>
>>> No need to check for the space before spam,
>>
>> I prefer to explicitly specify the pattern for whitespace characters in
>> case in the future for some reason I replace $h_X-Bogosity: with
>> $rh_X-Bogosity: and forget to add \s or a space to the regex.
>
> Hm, debatable, as you then have to check for possible encoding too.
Such a header should not be encoded.
>>> but better check for the
>>> comma terminating that word. I suggest
>>>
>>> match{$h_x-bogosity:}{(?i)^spam,}
>>
>> In such cases, I prefer to use \b in case the syntax changes in the
>> header value.
>
> Good point.
>
>>> We have ${address:<string>}, so e.g. ${address:$h_from:}, which extracts
>>> the address.
>>
>> Try to check ${address:$h_From:} for
>>
>> From: [email protected] <[email protected]>
>
> That is in invalid from header value.
I know.
> If I'm not mistaken, then, per
> RFC5322, an unquoted display name must not contain "@".
But users of the mail systems I support from time to time receive emails
with such From headers.
And MUAs display such headers quite correctly.
So I am forced to take such situations into account.
>>> Parsing the header with the expression above is likely
>>> going to fail in allowed but not probably covered edge cases. (Though I
>>> wasn't able to construct one yet.)
>>
>> Please, show me such cases.
>
> exim -be '${sg{${sg{"[email protected]" <hans @
> example.com>}{:}{\\\\:}}}{\N^\s*\S+@\S+\s*(<\S+@\S+>)\N}{\$1}}'
> "[email protected]" <hans @ example.com>
I such address is correct?
I've never seen addresses like that in From headers.
> So it doesn't extract the address, but it returns something
> ${domain:<string>} can extract a domain from.
> If that is your intention, then I fail proving it being wrong :)
ok.
I'll take this into account in the regular expression.
>> Try to check ${addresses:[email protected] <[email protected]>}
>
> Same as above - the input to ${addresses:<
>} is invalid per RFC5321.
Same as above - users of the mail systems I support from time to time
receive emails with such From headers.
--
Best wishes Viktor Ustiuhov
mailto:[email protected]
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
