Hi,
I noticed that my fetchmail was segfaulting at the very start of a particular
mail message, with this trace:
#0 0xb7e67423 in strlen () from /lib/tls/libc.so.6
#1 0x0805cded in readheaders (sock=6, fetchlen=0, reallen=0, ctl=0x808d2d8,
num=2, suppress_readbody=0xbff7c835 "")
at transact.c:920
#2 0x080597df in fetch_messages (mailserver_socket=6, ctl=0x808d2d8,
count=272, msgsizes=0xbff7c7f0, maxfetch=0,
fetches=0xbff7e8c0, dispatches=0xbff7e8bc, deletions=0xbff7e8cc) at
driver.c:614
#3 0x0805ae82 in do_session (ctl=0x808d2d8, proto=0x8071da0, maxfetch=0) at
driver.c:1449
#4 0x0805b39d in do_protocol (ctl=0x808d2d8, proto=0x8071da0) at driver.c:1622
#5 0x0804f81a in doPOP3 (ctl=0x808d2d8) at pop3.c:1215
#6 0x08054c11 in query_host (ctl=0x808d2d8) at fetchmail.c:1373
#7 0x08052c26 in main (argc=4, argv=0xbff80bd4) at fetchmail.c:646
It is downloading mail from POP3.
Investigated further, turns out that the server had several mails on with
these contents: \r\n.\r\n
Or more literally:
=========
.
=========
No headers, no body, nothing.
This caused the process_headers label to be called with msgblk.headers as
NULL, and the duplicate-message killing code tried to do strlen(NULL) on line 920.
The attached patch solves the problem. Applies against both 6.2.5 and 6.3.0. I
know that it's a nonsense situation (did my ISP SMTP really accept such a
minimal email?) but I'd appreciate if if this could be considered anyway :)
Thanks,
Daniel
--- fetchmail-6.2.5/transact.c.orig 2005-12-05 15:25:54.000000000 +0000
+++ fetchmail-6.2.5/transact.c 2005-12-05 16:16:45.000000000 +0000
@@ -511,7 +511,7 @@ int readheaders(int sock,
}
/* check for end of headers */
- if (end_of_header(line))
+ if (msgblk.headers && end_of_header(line))
{
if (linelen != strlen (line))
has_nuls = TRUE;