I ran fetchmail at 21:35 today and it reported that a single mail had been
fetched and flushed. Nothing strange about the output (I don't use verbose mode,
so I only saw that it was flushed).
Next thing I do, is run mutt to read the new mail, only to find that there
is no new email anywhere. So I check the .procmail.log file to see when the
last email was received (procmail always logs that). 19:30. I conclude that
procmail did not process this email. I use procmail 3.22.
Now I check the local MTA spool and logs. I use exim 3.36, with a standard
configuration (that uses a smarthost system for outgoing mails). There was no
trace of an email supposedly received at 21:35. The last email received was
at 19:30. The reject and panic logs are empty.
Ok, so I think that maybe it was a human mistake - made I had run fetchmail
earlier today and maybe the output that one message was flushed was from
then. However, the .procmail.log and exim logs contradicts this, since at
19:30 two emails were received, not merely one.
The case would be moot if I didn't own the POP3 server that the emails
were fetched from. This server also acts as an SMTP (configured as a
full internet site). Here are the POP3 logs:
Sep 11 21:35:24 alpha popa3d[28391]: Session from 192.168.1.2
Sep 11 21:35:24 alpha popa3d[28391]: Authentication passed for usel
Sep 11 21:35:24 alpha popa3d[28391]: 1 message (59960 bytes) loaded
Sep 11 21:35:27 alpha popa3d[28391]: 1 (59960) deleted, 0 (0) left
But maybe, most important, the SMTP logs of the message that was received:
2002-09-11 20:02:57 17pBnT-0007Jv-00 <= service(_at_)h8h(_dot_)com
H=171-117.kingnet.net.tw (h8h.com) [61.57.171.117] P=smtp S=59133
id=e2z(_at_)pchome(_dot_)com(_dot_)tw
2002-09-11 20:02:58 17pBnT-0007Jv-00 => usel
<oskar(_at_)osk(_dot_)mine(_dot_)nu> D=localuser T=local_delivery
The first and only email received after 19:30 (the time I previously ran
fetchmail)
was 20:02. So it must have been this email that got lost. This log entry
convinced me
that either fetchmail or exim have made a mistake.
Could this be the same problem as
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=50990
(reported by me some time ago :) ). Judging from the sender, I suspect
this is a spam email. It should be noted though that I use no spam
protection. My fetchmailrc is straight forward:
poll alpha, proto pop3, user usel, pass "<hidden>"
At least fetchmail should have reported that there was an error. Or maybe
the problem was that exim choked once fetchmail had sent it the email,
and died before it could log anything? (I run exim from inetd.) Still,
I wouldn't expect exim to return OK code to fetchmail if it soon after
would die.
By the way, I use fetchmail 5.9.11.
Oskar Liljeblad (oskar(_at_)osk(_dot_)mine(_dot_)nu)