From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.8.1+) Gecko/20010425 $ fetchmail -a pop.mail.yahoo.com <snip> reading message 5 of 6 (3240 octets) ...fetchmail: message delimiter found while scanning headers Segmentation fault $ telnet pop.mail.yahoo.com 110 <snip> +OK maildrop ready, 6 messages (22942 octets) (488754 6291456) LIST +OK 6 messages (22942 octets) 1 3001 2 5599 3 3502 4 4441 5 3240 6 3159 . RETR 5 +OK 3240 octets X-Apparently-To: mschwendt via web6202.mail.yahoo.com Return-Path: < . I've been able to reproduce this several times. After I had downloaded, compiled, and installed fetchmail 5.8.0, I could not reproduce above segfault. However, if Yahoo's POP3 server was in a bad condition only temporarily, it could still be that 5.8.0 also causes a segfault the next time a bad message is found. Maybe you find a related bug in the code. Reproducible: Always Steps to Reproduce: Only while running version fetchmail 5.7.4 -- and as long as the damaged message was on the server -- I was able to reproduce the bug always. Yes, I know I should have kept the bad message on the server to be able to test this further. :-( Expected Results: Fetchmail should not cause a segmentation fault, but should skip the bad message and try downloading any subsequent messages.
This is a copy of the bug-report to Eric S. Raymond (fetchmail author). Meanwhile, fetchmail 5.8.0 has dealt with a similar situation properly. It said "message delimiter found while scanning headers" but didn't throw a segfault.
ESR's fetchmail 5.8.0-1 release throws a SegFault, too. It just needs an incomplete message which is cut somewhere in the headers. Seems to happen now and then with Yahoo Mail's POP3 server. ;-) ... reading message 3 of 4 (2829 octets) ..fetchmail: message delimiter found while scanning headers Segmentation fault
Happily running 5.8.14 for quite some time by now without similar symptoms. Have encountered a very few truncated/damaged mails only, though. I post this because it happens usually that the bug occurs shortly after. :) Seriously, this bug _could_ be related to the buffer overflow in the header parser of all versions prior to 5.8.6 (bugtraq id 2877). But I'm not uptodate on that one and what has been fixed.
Running without problems with 5.9.0 for some time (which is in Roswell 7.1.94 now, too).
As long as I don't get this failure again with the newer releases of fetchmail, I consider this resolved.