Sophos apparently has trouble dealing with "deleted" messages

I just thought of something... some mailboxes tend to have an index file and a data file... when you delete a message, it deletes the index entry, but the data is still inside the data file.

(Someday I'll figure out how to quote and insert text on this System. Hand editing the poor HTML generated is a pain.)

In theory... that is what the "rebuild" option will do.

Select a mail box, click - mailbox-pulldown/rebuild.

Mail.app deletes all of the files in the associated directory: ~/LibraryMail/<mailbox>

the index files, data files and attachments.

This is easy enough to observe via the Terminal.

Since mailboxes of this sort contain more than one message, you often cannot "delete" the message without wiping out the entire data file.  If the file is still open for access from your mail app, it won't be deletable.

This is (can be)  true for Unix systems -- i.e. the IMAP server itself, but not for the Mail.app database -- which is the only thing Sophos looks at.

In the Mail.app "database" i.e. the ~/Library/Mail/<mailbox> - each message is a single ".emlx" file with the attachments stored separately.

Apple's Mail.app [Mail User Agent (MUA) ] retrieves each message from the from both POP and IMAP  servers (Mail Transport Agent (MTA)] as individual files and attachments. It maintains an index (.plist) of those retrieved. The only difference between POP and IMAP is that the IMAP server retains a copy of the mail message and any attachments, whereas the POP server does not. The mail client and server each operate independently. 

Ok, here's my current analysis...

What I believe I am seeing, now after the last couple of days of serious "debugging," is that the Quarantine Manager is DISPLAYING an additional "finding" for some reason. That additional finding is what is not being deleted from the Quarantine Manager.

Sophos first finds and lists  the individual files (but doesn't log them anyplace I have found except in the Quarantine Manager window), and then finds them again (logging them in a log file as well as the Quarantine Manager window this time) and builds the "collective" entry. As my last posting showed, that collective entry is apparently a duplicate of the files which are found individually. Then when the "Scan of local drives" deletes those individual messages and updates the Quarantine Manager, the "collective message" entry is not updated.

I don't know for certain, but here is a guess as to what is happening... Sophos is doing two different things, which generate two different situations, visible in the Quarantine Manager.

As the Mail.app retrieves each individual mail message it is scanned and an entry generated for the Quarantine Manager -- but this activity is not logged. (Or at least I haven't found evidence of it being logged.) This appears to be the action of the  "On-Access Scanner."

Then Sophos Scans the entire ~/Library/Mail structure and generates the "collective" entry, this time logging what it is doing. (I don't know the "period" here, but it appears to happen at least hourly.)

The "Scan Local Drives (custom scan)" logs to "~/LIbrary/Logs/Sophos Anti-Virus/Scans/<scan-name>/<time-stamp>

This log file contains the entries the scan actually deletes and they are deleted from the Quarantine Manager window as well.

The "collective scan" appears to be occurring when Sophos does its hourly check to update the virus database.

This log file (entries are tagged "com.sophos.intercheck " -  contains the entries which appear in the Quarantine Manager as that single collective entry. This "collective" entry is not updated by the "Scan Local Drives" (custom scan) action.

In short, there is a "communication" problem between "Scan Local Drives (Custom Scan)" and the Quarantine Manager display.

Guessing from the "Clear from list" button, this is "expected behavior" (i.e. a "known issue") with Sophos.

I suspect, but haven't tried, that the issue may be with the "Custom Scan" -- with a 320 gig drive, I have only ever done one full run of "Scan Local Drives" as it took something like 14 hours as I recall.

I just thought of something... some mailboxes tend to have an index file and a data file... when you delete a message, it deletes the index entry, but the data is still inside the data file.

(Someday I'll figure out how to quote and insert text on this System. Hand editing the poor HTML generated is a pain.)

In theory... that is what the "rebuild" option will do.

Select a mail box, click - mailbox-pulldown/rebuild.

Mail.app deletes all of the files in the associated directory: ~/LibraryMail/<mailbox>

the index files, data files and attachments.

This is easy enough to observe via the Terminal.

Since mailboxes of this sort contain more than one message, you often cannot "delete" the message without wiping out the entire data file.  If the file is still open for access from your mail app, it won't be deletable.

This is (can be)  true for Unix systems -- i.e. the IMAP server itself, but not for the Mail.app database -- which is the only thing Sophos looks at.

In the Mail.app "database" i.e. the ~/Library/Mail/<mailbox> - each message is a single ".emlx" file with the attachments stored separately.

Apple's Mail.app [Mail User Agent (MUA) ] retrieves each message from the from both POP and IMAP  servers (Mail Transport Agent (MTA)] as individual files and attachments. It maintains an index (.plist) of those retrieved. The only difference between POP and IMAP is that the IMAP server retains a copy of the mail message and any attachments, whereas the POP server does not. The mail client and server each operate independently. 

Ok, here's my current analysis...

What I believe I am seeing, now after the last couple of days of serious "debugging," is that the Quarantine Manager is DISPLAYING an additional "finding" for some reason. That additional finding is what is not being deleted from the Quarantine Manager.

Sophos first finds and lists  the individual files (but doesn't log them anyplace I have found except in the Quarantine Manager window), and then finds them again (logging them in a log file as well as the Quarantine Manager window this time) and builds the "collective" entry. As my last posting showed, that collective entry is apparently a duplicate of the files which are found individually. Then when the "Scan of local drives" deletes those individual messages and updates the Quarantine Manager, the "collective message" entry is not updated.

I don't know for certain, but here is a guess as to what is happening... Sophos is doing two different things, which generate two different situations, visible in the Quarantine Manager.

As the Mail.app retrieves each individual mail message it is scanned and an entry generated for the Quarantine Manager -- but this activity is not logged. (Or at least I haven't found evidence of it being logged.) This appears to be the action of the  "On-Access Scanner."

Then Sophos Scans the entire ~/Library/Mail structure and generates the "collective" entry, this time logging what it is doing. (I don't know the "period" here, but it appears to happen at least hourly.)

The "Scan Local Drives (custom scan)" logs to "~/LIbrary/Logs/Sophos Anti-Virus/Scans/<scan-name>/<time-stamp>

This log file contains the entries the scan actually deletes and they are deleted from the Quarantine Manager window as well.

The "collective scan" appears to be occurring when Sophos does its hourly check to update the virus database.

This log file (entries are tagged "com.sophos.intercheck " -  contains the entries which appear in the Quarantine Manager as that single collective entry. This "collective" entry is not updated by the "Scan Local Drives" (custom scan) action.

In short, there is a "communication" problem between "Scan Local Drives (Custom Scan)" and the Quarantine Manager display.

Guessing from the "Clear from list" button, this is "expected behavior" (i.e. a "known issue") with Sophos.

I suspect, but haven't tried, that the issue may be with the "Custom Scan" -- with a 320 gig drive, I have only ever done one full run of "Scan Local Drives" as it took something like 14 hours as I recall.