[ILUG] fetchmail(1) discarding (probably bogus/spam?) e-mails

[Brian Foster]

 I'm not in a position to use Google™ ATM,
 so my apologies if this is well-known ....
 every now and then (it's rare — I can only
 recall seeing this c.4 times the last year),
 fetchmail(1) will delete an e-mail rather than
 downloading it.  as an example, from a recent
 (edited) `fetchmail -v' log:

     fetchmail: POP3< +OK [ user ]'s mailbox has 1 message(s) (1534 octets)
     fetchmail: POP3> STAT
     fetchmail: POP3< +OK 1 1534
     fetchmail: POP3> LAST
     fetchmail: POP3< +OK 0
     1 message for [ user ] at [ site ] (1534 octets).
     fetchmail: POP3> LIST 1
     fetchmail: POP3< +OK 1 1534
     fetchmail: POP3> TOP 1 99999999
     fetchmail: POP3< +OK
     reading message [ user at site ]:1 of 1 (1534 octets)
     fetchmail: incorrect header line found while scanning headers
     fetchmail: line: ----09-2[5]-3952-6[3]-047[3]
      flushed
     fetchmail: POP3> DELE 1
     fetchmail: POP3< +OK message 1 deleted

 this bothers me.  IMO, `fetchmail' should
 have the ability to download the message,
 but then place it into a “bogusity” directory,
 to be inspected later.  or something like
 that — I am quite happy with the e-mail not
 being delivered (bogus headers can cause some
 MUA to do weird things), but am unhappy with
 the e-mail simply being deleted.

 this behaviour does not appear to be documented
 in the fetchmail(1) manual page.  does anyone
 have any suggestions on how to (at the least)
 prevent `fetchmail' from deleting messages it
 does not like?

 ( “fetchmail release 6.2.5+POP2+RPA+NTLM+SDPS+SSL+OPIE+NLS” )
cheers!
	-blf-
-- 
Experienced (20+ yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com