From: Matthias A. <mat...@gm...> - 2020-10-22 17:56:39
|
Am 22.10.20 um 19:28 schrieb James Moe via Fetchmail-users: > fetchmail 6.4.11 > opensuse LEAP 15.2 > > Fetchmail had trouble with this one message. Both fetchmail and the local mail > server blamed each other for the failure. > The message is a trojan with a tainted XLS file; about 126KB. > The log has the mail server's log of the transaction; it is the first part of > the log file (see below). The server was waiting (for not many bytes!?) when it > logged the connection as closed by fetchmail. > Fetchmail sent the message header, then complained that the server broke the > connection. And proceeded to download the body anyway. And did not bother with > any of the other messages. > > My query: What happened? > > Log file: https://www.dropbox.com/s/5nj3wh8jlnfxv79/fetchmail.log?dl=0 > James, is there any middleware, malware filter, spam filter, firewall, whatever involved that might deliberately break the connection "from the outside" the moment when it detected the malware on the SMTP connection? I've checked the fetchmail 6.4.13-rc1 code path (unchanged from 6.4.11), and indeed when the output fails, fetchmail aborts the fetch, so "did not bother with any of the other messages." is what the code intends. All fetchmail releases I've made in fact behave this way, and Eric Raymond's 6.2.5 also did. I can only surmise the assumption was that if we fail shipping one message due to a hard error (lost connection), shipping more messages in the same run doesn't make sense. I see from the log that you are using an "MDA" to deliver mail, so can you show your configuration? See https://www.fetchmail.info/fetchmail-FAQ.html#G3, item #5, for instructions. Regards, Matthias |