bug#23040: Resolved

bug#23040: Resolved

[Lars Ingebrigtsen]

Nikolaus Rath <Nikolaus@rath.org> writes:

> The problem here is that recently some spam has started to come with
> extremely long "References" headers, and that the regular expression
> used in one of my scoring rules is sub-optimal when applied to such long
> strings.
>
> In particular, the leading dot in "<.+@[a-z0-9]+\\.rath\\.org>" first
> matches the entire reference header, and then emacs presumably has to
> backtrack character by character (or something like that).
>
> Fixing the rule by restricting the match to one message id fixes the
> problem: "<[^<>@]+@[a-z0-9]+\\.rath\\.org>"

Could you submit a patch for this problem? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23040: Resolved

[Nikolaus Rath]

On Jan 26 2017, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Nikolaus Rath <Nikolaus@rath.org> writes:
>
>> The problem here is that recently some spam has started to come with
>> extremely long "References" headers, and that the regular expression
>> used in one of my scoring rules is sub-optimal when applied to such long
>> strings.
>>
>> In particular, the leading dot in "<.+@[a-z0-9]+\\.rath\\.org>" first
>> matches the entire reference header, and then emacs presumably has to
>> backtrack character by character (or something like that).
>>
>> Fixing the rule by restricting the match to one message id fixes the
>> problem: "<[^<>@]+@[a-z0-9]+\\.rath\\.org>"
>
> Could you submit a patch for this problem? 

If I understand the issue correctly, then it is caused by a sub-optimal
regular expression in my local configuration that triggers problems in
Emacs' regular expression engine. I think the former can't be patched in
Gnus, and the latter is definitely beyond my area of expertise, sorry.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

bug#23040: Resolved

[Lars Ingebrigtsen]

Nikolaus Rath <Nikolaus@rath.org> writes:

> If I understand the issue correctly, then it is caused by a sub-optimal
> regular expression in my local configuration that triggers problems in
> Emacs' regular expression engine. I think the former can't be patched in
> Gnus, and the latter is definitely beyond my area of expertise, sorry.

OK; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no