You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/03/08 20:02:31 UTC
Re: mass-check failed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Theo Van Dinter writes:
> On Mon, Mar 08, 2004 at 10:48:50AM -0600, Michael Parker wrote:
> > Deep recursion on subroutine
> > "Mail::SpamAssassin::Message::Node::content_summary" at
> > /home/parker/SA/spamassassin-corpora/masses/../lib/Mail/SpamAssassin/Message/Node.pm
> > line 423.
> > Out of memory!
>
> Hrm. The only rule which uses that is the MPART_ALT_DIFF code. I guess
> it depends what is meant by "deep recursion" -- ie: how many times
> it that? ;)
Let's add a depth restriction, anyway, since there's no way we should
parse a MIME message 100 levels deep (for example) -- it'll just
result in resource exhaustion and I doubt many MUAs support it.
> > some ideas. Also, given that I know the msgid of the last message
> > written to the logs, how do I find which message would be next up for
> > processing?
>
> Heh. It's unfortunately not that easy. You'd need the list of messages,
> which doesn't get output in any useful way... You can edit the code in
> ArchiveIterator to not unlink the temp file. Then that would tell you
> the messages in order.
Probably something we should add to mass-check as a switch, because I
can see that being useful info quite frequently.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFATMNHQTcbUG5Y7woRAtVsAKDLUvF8YhUm9ArRnlqT6bEciynuqgCeJwGK
KXxRN8Tl1q2tJps0dMa4P4M=
=X/uj
-----END PGP SIGNATURE-----
Re: mass-check failed
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 11:02:31AM -0800, Justin Mason wrote:
> Let's add a depth restriction, anyway, since there's no way we should
> parse a MIME message 100 levels deep (for example) -- it'll just
> result in resource exhaustion and I doubt many MUAs support it.
Arguably though, if content_summary gets stuck, find_parts or the parser
itself should get stuck.
> Probably something we should add to mass-check as a switch, because I
> can see that being useful info quite frequently.
Yeah. This would be part of the resume capability as well... :)
--
Randomly Generated Tagline:
ep.