gnus chokes on this junk mail

gnus chokes on this junk mail

[Stefan Waldherr]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

Hi,

I noticed that gnus chokes on the attached junk mail. Maybe a bug?  I
had to removed the mail from a huge spool file before gnus was able to
process the rest of the file. Junk mail gets really annyoing nowadays.

cu
Stefan.

[-- Attachment #2: fucker --]
[-- Type: application/octet-stream, Size: 21206 bytes --]

[-- Attachment #3: Type: text/plain, Size: 233 bytes --]


-- 
Stefan Waldherr                office +1 (412) 268-3837
                                  fax +1 (412) 268-5576
                               e-Mail swa@cs.cmu.edu
                                  www http://www.waldherr.org/

Re: gnus chokes on this junk mail

[Ken Raeburn]

Stefan Waldherr <swa@cs.cmu.edu> writes:

> I noticed that gnus chokes on the attached junk mail. Maybe a bug?  I
> had to removed the mail from a huge spool file before gnus was able to
> process the rest of the file. Junk mail gets really annyoing nowadays.

Does emacs crash or does gnus simply report some error?

That looks like a regexp bug I reported here and to RMS a while back.
It turns out that in some cases (hairy regexps of certain sorts?), the
regexp matching code requires an amount of temporary space based on
the size of the buffer-portion it's trying to match against -- such as
the entire "to:" field.  Try cutting down the "to:" field
significantly and see if gnus can handle it then.

Ken

Re: gnus chokes on this junk mail

[Stefan Waldherr]

>>>>> "Ken" == Ken Raeburn <raeburn@cygnus.com> writes:

  Ken> Does emacs crash or does gnus simply report some error?

Nope, gnus simply stops. 

  Ken> size of the buffer-portion it's trying to match against -- such as the
  Ken> entire "to:" field.  Try cutting down the "to:" field significantly and
  Ken> see if gnus can handle it then.

You were right. I removed a bunch of lines from the `To' field and gnus could
read the mail. Nevertheless I consider it a bug. In fact a nasty one.

S.
-- 
Stefan Waldherr                office +1 (412) 268-3837
                                  fax +1 (412) 268-5576
                               e-Mail swa@cs.cmu.edu
                                  www http://www.waldherr.org/

Re: gnus chokes on this junk mail

[Lars Magne Ingebrigtsen]

Stefan Waldherr <swa@cs.cmu.edu> writes:

>   Ken> size of the buffer-portion it's trying to match against -- such as the
>   Ken> entire "to:" field.  Try cutting down the "to:" field significantly and
>   Ken> see if gnus can handle it then.
> 
> You were right. I removed a bunch of lines from the `To' field and gnus could
> read the mail. Nevertheless I consider it a bug. In fact a nasty one.

Does it hang forever, or does it just take lots of time?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus chokes on this junk mail

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Waldherr <swa@cs.cmu.edu> writes:

>> You were right. I removed a bunch of lines from the `To' field and gnus
>> could read the mail. Nevertheless I consider it a bug. In fact a nasty
>> one.

> Does it hang forever, or does it just take lots of time?

It just takes a lot of time (upwards of five to ten minutes on my
machine).  An unavoidable side effect of slow regex matching, I think,
although one could argue that Gnus should simply bail on attempting to
match anything with a To header over a certain length.

I've considered just procmailing such messages away, as they're invariably
spam.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: gnus chokes on this junk mail

[Stefan Waldherr]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  >>  You were right. I removed a bunch of lines from the `To' field and gnus
  >> could read the mail. Nevertheless I consider it a bug. In fact a nasty
  >> one.

  Lars> Does it hang forever, or does it just take lots of time?

I don't quite remember but a fairly long time passed until I ^G'ed my XEmacs.

S.
-- 
Stefan Waldherr                office +1 (412) 268-3837
                                  fax +1 (412) 268-5576
                               e-Mail swa@cs.cmu.edu
                                  www http://www.waldherr.org/

Re: gnus chokes on this junk mail

[Hrvoje Niksic]

Stefan Waldherr <swa@cs.cmu.edu> writes:

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>   >>  You were right. I removed a bunch of lines from the `To' field and gnus
>   >> could read the mail. Nevertheless I consider it a bug. In fact a nasty
>   >> one.
> 
>   Lars> Does it hang forever, or does it just take lots of time?
> 
> I don't quite remember but a fairly long time passed until I ^G'ed
> my XEmacs.

You may wish to set `debug-on-quit' to t, and mail us the backtrace
that pops up after you press C-g.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Which is worse: ignorance or apathy?  Who knows?  Who cares?

Re: gnus chokes on this junk mail

[Ken Raeburn]

Russ Allbery <rra@stanford.edu> writes:

> It just takes a lot of time (upwards of five to ten minutes on my
> machine).  An unavoidable side effect of slow regex matching, I think,
> although one could argue that Gnus should simply bail on attempting to
> match anything with a To header over a certain length.

Or split the header into managable chunks for matching.

> I've considered just procmailing such messages away, as they're invariably
> spam.

Almost.  I've seen mail recently with a large "to" header because the
sender wanted to ask the maintainers of a large set of programs about
distributing those programs or some such.

Re: gnus chokes on this junk mail

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> It just takes a lot of time (upwards of five to ten minutes on my
> machine).  An unavoidable side effect of slow regex matching, I think,
> although one could argue that Gnus should simply bail on attempting to
> match anything with a To header over a certain length.

Hm... yes.  Perhaps the mail splitting code should go over the headers
and shorten all headers that are longer than N octects?  How big
should N be?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen