kaspersky (?) causes repeated download of folders on imap
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
People
(Reporter: buecher, Unassigned)
References
Details
(Whiteboard: [needs protocol log])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
On Kaspersky KTS 19 (since yesterday), not on 18:
On automatic download of mails in a subfolder of inbox, Kaspersky reports 'email attachment with virus', next windows defender reports threat (not further specified).
TB decides to redownload whole folder. Kaspersky/Defender report messages. This goes into a loop, folder is redownloaded continously.
Kaspersky is (was always) set to scan port 143. Virus support is not activated in TB .
settings.
It seems, after Kaspersky does soMething to the messages, TB sees a discrepancy between local sync and server and redownloads.
What to do? Switch off scanning of 143 in Kaspersky? Then, what happens if an attachment with virus is opened? Is that given at time of opening to Kaspersky for scanning? Meaning, can I leave the virus attachments leave sitting in my mailbox because they are/might be scanned at opening?
This does not happen in KTS 18 on another PC.
Actual results:
tried to get info in support forum but no success.
a few minutes ago, TB on the other PC has started to redownload arbitrary folders(PC with the old Kaspersky). The folders are really old, having mails from 2014 only or similiar, so no change in the folders expected. At the moment, the redownload is not going into a loop.
I have imap server logs switched on (but not TB imap logs). Not sure whether they might help.
If you open an attachment with a virus then Kaspersky should first detect the signature in memory when the mime attachment is decoded and turned into something other than text. It gets another chance when the attachment is written to the temp folder and yet a third chance when the file is opened by the application that actually uses that type of file. (These later two are the same chances that are relied upon in their entirely when you plug in a USB drive. Scan the file on disk and when opened.) Mail scanning is really mostly hype and marketing. Offering little real protection in an environment that does not run scripts in the message body. It does offer real protection in mail clients that do run scripts in the message body and that used to be almost all "corporate" mail programs. I don't really know the sate of play these days.
thanks for the good explanation.
TB is now redownloading everything (40 GB...).
I have now set an exclusion for Kaspersky on the imapmail subfolder. Probably will have to wait for the full redownload to finish to see whether that helps. In a next step, I could also block scanning of port 143. Want to do it step by step to understand what is the origin.
For my understanding: if port scanning of 143 would strip an attachment from an email, the email on server is different from its copy in TB. Would TB know? Or would the server tell to TB at TB's next request for that imap-folder?
(In reply to klaus from comment #3)
thanks for the good explanation.
TB is now redownloading everything (40 GB...).
I have now set an exclusion for Kaspersky on the imapmail subfolder. Probably will have to wait for the full redownload to finish to see whether that helps. In a next step, I could also block scanning of port 143. Want to do it step by step to understand what is the origin.For my understanding: if port scanning of 143 would strip an attachment from an email, the email on server is different from its copy in TB. Would TB know? Or would the server tell to TB at TB's next request for that imap-folder?
You have mentioned scanning on port 143. this is in itself perhaps an issue as the imap mail is unlikely to be on an encrypted connection on that port. Generally encrypted email travels on port 993 for IMAP. Is the connection encrypted and on a non default port for encryption? That might be enough to trip up the unwary, or the anti virus.
the server is not encrypted and in my local network. 143 has always worked (10 years). No changes to server, no error message in server
|
||
Comment 6•5 years ago
|
||
(In reply to klaus from comment #3)
thanks for the good explanation.
...
I have now set an exclusion for Kaspersky on the imapmail subfolder. Probably will have to wait for the full redownload to finish to see whether that helps. In a next step, I could also block scanning of port 143. Want to do it step by step to understand what is the origin.
Klaus, your results?
it is not Kaspersky. Every so often, TB starts to redownload full folders without apparent reason. Sometimes, these folder have not been touched for years.
I can have a look at the imap logs but don't know what to look for. How does TB trigger the redownload? Or what message of the mail server would make TB think that something has changed and needs redownload?
|
|
||
Comment 8•5 years ago
|
||
If you get the log, gene can assist
IMAP:5,timestamp
|
||
Comment 9•5 years ago
|
||
Hi klaus. You might check this: Bug 1584983. Your re-downloads might be due to the server producing a new value for UIDVALIDITY. If you have updated to tb 68 you can add IMAP_CS to your log to verify this, see Bug 1584983 Comment 11. This will log when tb detects a change in folder's UIDVALIDITY number which triggers a re-init/re-download of the folder to ensure accurate synchronization.
Wayne, I'm thinking Bug 1584983 could be closed as invalid since the reporter did observer the UIDVALIDITY change in the log.
|
|
||
Comment 10•4 years ago
|
||
Klaus, can you get a protocol log?
|
Reporter | |
Comment 11•4 years ago
|
||
Thanks, Wayne, it seems I missed Gene's proposal from 4 months ago.
At the moment, my major problem is that imap is crawling (download of three text messages takes 3 min), although I didn't change anything at the server side (it is my local imap server). That is much worse than the download issue, and now, I am offline all the time, otherwise TB is unusable (we had thte same around 59??). Each download attempt makes TB irresponsive for several minutes (or writing to drafts, or ...).
My feeling was to wait for 78 and see whether the step in generation might solve anything.
Otherwise, it is my server installation, so I can easily get logs.
Klaus
|
|
||
Updated•4 years ago
|
|
||
Comment 12•4 years ago
|
||
Resolved per whiteboard.
Feel free to reopen when you'll have the logs
Description
•