[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Poco Forums • View topic - Turning off incoming virus scans

Turning off incoming virus scans

Help and advice on using PocoMail

Moderators: Eric, Tomas, robin

Turning off incoming virus scans

Postby frazmi » Thu Aug 12, 2004 3:37 pm

[EDIT] As you will see below, Sandy makes a good case that the theory presented in this post is not correct in at least one respect: The index files on disk (e.g., in.idx) do not seem to have pointers into the message file (e.g., in.mbx). So, before you go out and shoot your Anti-Virus program, please think and evaluate this entire thread.

I've been doing more testing, however, and I will be posting the results soon. As a preview, I've been able to force Poco to garble messages by simulating the action of an AntiVirus program "cleaning" a message while Poco is running.

So far, I have not been able to simulate a problem when Poco is not running, which suggests that a background anti-virus scan (when Poco's not running) is safe.
[/EDIT]

For those who don't want to read the entire post, here's my bottom line:
Do not turn off incoming message virus scans except for testing. Doing so may cause you to lose messages or to have some messages corrupted.

For those who want some details, please read on.

I've read in a number of threads the suggestion to turn off virus scanning of incoming email. As a temporary measure to help diagnose a problem, I think this is justified. (It feels a bit like running naked into the Colorado River in order to find out the water temperature -- but that's just my opinion. However, as a permanent solution to problems like "long message download time" and "messages without senders" I think it's very dangerous. Here's why.

If you don't check email on arrival, then you have to check it later using a system-scan of your AV product (unless you always swim in the Colorado without swimsuit). For almost all mailboxes, Poco stores messages in mailbox files (mbx extension). When an AV product scans an mbx file and finds a virus, what does it do? Well, depending on your AV program and settings, it might...

1) Delete the file. :shock: There go your messages!
2) Quarantine the file. :shock: Can't access your messages!
3) Repair the file. Well, here the situation gets trickier.

Poco manages an index file (idx file) to tell it where each message starts in the mbx file. Now, I am making some assumtions based on what the index file looks like, but it seems that there is a pointer in the idx file which is the message offset into the mbx file. (Offset = how many characters precede the particular message.) If the AV product changes the mbx file by "repairing" or "cleaning" it, all of the messages after the "cleaned" message will have incorrect pointers in the idx file.

Let's run a typical scenario:
1) Incoming AV checking is turned off.
2) Message with virus arrives.
3) Poco stores message in MBX file (e.g., foo.mbx)
4) User fails to recognize the virus, and does not delete message.
5) User closes Poco.
At this point, the index and message files might look like this:
ImageBigger image

6) Automatic virus scan runs, and finds the virus-infected file foo.mbx.
ImageBigger image

7) AV program "cleans" the virus infected file.
ImageBigger image

8) User restarts Poco, which [perhaps] does not realize that the mbx file has been changed. Thus, the idx file pointers don't point to the right place. Like this:
ImageBigger image

9) User moves or copies a "defective" message before Poco does an automatic mailbox compression. The result is a permanently disfigured message.

Now, if Poco does a check to make sure that all idx pointers actually point to the start of messages, then this scenario probably will not happen. However, I have an actual case study where this happened using Norton AntiVirus 2004. (In this particular case, the messages were actually longer after the "cleaning" but that's not important. The critical point is that the AV cleaning process moves the physical start of the message relactive to the beginning of the file, and unless Poco checks for this, message loss and message garbling will occur.
Last edited by frazmi on Fri Aug 13, 2004 7:29 pm, edited 1 time in total.
frazmi
Poco Enthusiast
 
Posts: 248
Joined: Tue Jul 27, 2004 1:27 am
Location: South Korea

Postby Pete » Thu Aug 12, 2004 4:11 pm

Well, I think that you've provided a lot of useful information, frazmi, for people who scan incoming email messages, but I have a different opinion about all of this. :)

I disabled my AV's automatic scan of incoming email messages more than two years ago and I have never re-enabled it. Since PocoMail never automatically runs things in messages, I really don't see a need to scan incoming messages, and it apparently causes a lot of unnecessary problems. Now if someone also uses other email clients besides PocoMail, then that is a different case.


frazmi wrote:If you don't check email on arrival, then you have to check it later using a system-scan of your AV product [...]

While this is true, I don't think that anyone has to manually run a scan of messages or attachments after they have been downloaded or saved to disk files. Norton Anti-Virus, for example, automatically scans an attachment while you're opening it. So when I double click on the attachment in the Attachment Pane, that is the only time when Norton checks it for viruses on my computer. Or, if I run the attachment from Windows Explorer, then Norton checks it at that time. In either case, the attachment is not run from an MBX file. It's run from either the Attach folder or the Cache folder (depending on your settings) so no MBX or IDX files should ever become corrupted using this method.

If your AV program doesn't let you do this the way that I do it, then maybe it's time to switch to a different AV program. :)

Also, if you're concerned about sending viruses to other people, you can surely enable outgoing email scanning. This might not be as problematic as incoming email scanning seems to be, but that's just a guess.
Pete
 

Postby frazmi » Thu Aug 12, 2004 4:37 pm

Pete, some interesting perspectives there...

A couple of questions surface in my mind.
Do you leave attachments encoded in your message?
Do you run background AV checks (either automatic or manual)?

I used to have my settings almost as you describe, and was using NAV 2004 with the most current definitions. One day, for testing, I changed my attachment encoding settings to leave them encoded in the message. Imagine my surprise when a week later my routine weekly NAV full-system scan found many viruses that had not been detected during the incoming message scans.

After Norton "cleaned" the virus-laden files (which were not in the Attach folder, but were in fact the mbx files) I had truckloads of broken indices -- and corresponding lost or garbled messages. I've posted the details with sample messages already.

You said,
PocoMail never automatically runs things in messages,
How does Poco handle an embedded attachment?

Also, since NAV (based on your comments -- I've never really been 100% sure of when exactly NAV runs) runs a virus check whenever a file is opened, wouldn't it therefore run a virus check when Poco opens the mbx file? And thereby (potentially) triggering my scenario?

Regarding the outgoing email scan, that's the one that I've always turned off -- it takes way way way too long.
frazmi
Poco Enthusiast
 
Posts: 248
Joined: Tue Jul 27, 2004 1:27 am
Location: South Korea

Postby Sandy » Thu Aug 12, 2004 4:49 pm

I've got to go with Pete on this.

Frazmi, your theories are well thought out, and certainly well illustrated in this case :lol:, but you ought to check them out with testing before spending so much time building your case in the forum. You overstate how the IDX and MBX files work. I'm not sure I know exactly how they interrelate either, but I certainly would not take the logical leap of saying:

Now, I am making some assumtions based on what the index file looks like, but it seems that there is a pointer in the idx file which is the message offset into the mbx file.


You have no way of knowing that. And in fact it is wrong in spite of your nice graphics. It is easy to prove this. Set up a testing mailbox. Copy several messasges into it. Close Poco. Delete entire chunks of the MBX file, even headers so long as you don't delete the critical ones like the:

Code: Select all
From xyz@aol.com Thu, 12 Aug 2004 12:57:04 EDT


Open Poco. Look at the testing mailbox WITHOUT compressing it. You will see that Poco is still able to distinguish each message separately with only what you deleted missing (unless you happen to delete something critical I suppose). This would not be possible if your THEORY of how the IDX and MBX files work given your assumption above and as illustrated in your graphics.
Sandy
 

Postby frazmi » Thu Aug 12, 2004 5:43 pm

Sandy, you assume that I don't do testing. Bad assumption. I don't post just to see my name in pixels, and I spend a lot more time thinking about my posts than I do writing them.

I'm totally willing to stand corrected on my ideas about the index files. In fact, it looks like my theory is wrong, and I appreciate your taking time to point it out. However, I do have an actual (not hypothetical) AV scan event that was repeatable and that always screwed up the messages. I can see how various parts of one email message have been offset into the middle of other messages. (It's not repeatable anymore because I've removed Norton from my system.)

Why don't you try testing Norton AV 2004 on some mbx files with known viruses, and see if you can duplicate my results? IMO, that would be an effective way to use your skills and intelligence. Either way, your results would contribute to our understanding.

Back to the idx questions, your testing scenarios (and some further testing I've done since then) suggest that the content of the index file on disk is completely irrelevant. I've now deleted parts of the index file, and deliberately corrupted other parts, yet Poco seems to rebuild it every time Poco starts. What's the function of the idx file? Can it ever be subverted?

Finally, Sandy, cut me (and others) just a little more slack. You wrote
You have no way of knowing that
Of course I didn't know that. Why else would I say,
I am making some assumtions based on what the index file looks like
Those are the words of someone who is trying to figure out what's going on, who's not afraid to post something that might be wrong, and who is not claiming certainty.
frazmi
Poco Enthusiast
 
Posts: 248
Joined: Tue Jul 27, 2004 1:27 am
Location: South Korea

Postby Sandy » Thu Aug 12, 2004 6:26 pm

Sandy, you assume that I don't do testing.


Not true. However, it seems you took the route of assuming how AV software could munge an MBX/IDX file relationship in this case, and posting it, rather than doing simple tests on your own first. I can't think of when I've said you never test. You tell me.....do you ever test? I would think you do sometimes.

However, I do have an actual (not hypothetical) AV scan event that was repeatable and that always screwed up the messages.


What's that got to do with your assumptions about how IDX and MBX files work? Are you saying that you've narrowed your AV event down so that you have reason to think IDX/MBX interaction is involved?

Why don't you try testing Norton AV 2004 on some mbx files with known viruses, and see if you can duplicate my results?


I wouldn't even know where to get a virus to test with -- as if I'd knowingly put a virus onto my system in the first place. I must admit it is puzzling to me that you allow so many virus into your systems (50 per day I think you said). Personally, I have things set up so I rarely see a virus. Why would spent time I testing for such a rare event that I and most users are likely never to see?

IMO, that would be an effective way to use your skills and intelligence.


Gee, I'm really hurt that you don't think I normally use my skills and intelligence effectively. Is there any hope for me, do you think?

yet Poco seems to rebuild [the IDX file] every time Poco starts.


That would be my guess too. But I see no reason to make such guesses in this forum. Might be an interesting project to find out on my own however (if I were interested).

Finally, Sandy, cut me (and others) just a little more slack.


I can't see why I have any obligation to do that. Do you need the slack? Is there some reason to think I am not cutting you slack?

Of course I didn't know that. Why else would I say,
I am making some assumtions based on what the index file looks like


I must admit, that puzzled me too. Why would you make an assumption like that and take the time to post a long theory based on it when it is so easy to prove/disprove the assumption. Yes, I did wonder why else you would say that.

who's not afraid to post something that might be wrong


I have too often posted something wrong. For me it's not a matter of fear, but rather it results from me having made a mistake. My main objective is to post something useful (except of course in a "chat" like this).

who is not claiming certainty.


I too try not to do that.
Sandy
 

Postby robin » Thu Aug 12, 2004 8:08 pm

In my thread in another forum, Jim said
Jim wrote:One thing you may have missed is the fact that on start up, PocoMail compresses its mailboxes. This may explain your reaction to 3, above.
robin
 

Postby Hogyt » Thu Aug 12, 2004 11:00 pm

This is how i'd set it up:

If using NAV, disable incoming email scanning (more trouble than it's worth as experienced by several people, including me). Leave outgoing email scanning running unless you find the long time it takes to scan outgoing messages a pain.

Here is part of a reply i received from Symantec some time ago:
Also, please be aware that disabling email scanning does not leave you unprotected against viruses that are distributed as email attachments. Norton AntiVirus (NAV) Auto-Protect will scan any incoming files, including email, as they are saved to your hard drive. Email scanning is just another layer on top of this. To make sure that Auto-Protect is providing the maximum protection, keep Auto-Protect enabled and run LiveUpdate regularly to ensure that you have the most recent virus definitions.

If using another virus scanner leave email scanning turned on unless you have problems (it seems to be NAV that causes most problems, but maybe other mail scanners have problems too). Be aware that your virus scanner could be the cause of download problems.

Whatever virus scanner you use, configure it to ask you what to do when it finds a virus or to quarantine the file, NOT to automatically repair or delete the file.

In PocoMail, go to Tools->Options->General Options and enable automatic backups of mailboxes. How often you back them up is up to you.

In Tools->Options->Encoding Options, disable the attachment encoding checkboxes. This will save attachments separately to your email and hence if an attachment has a virus the mailbox will be left alone.

You could also completely disable scanning of C:\Program Files\PocoMail\Mail (or wherever your mail folder is) but personally i'd leave it to scan it. With the settings above you'll have a recent backup and your scanner will ask you before doing anything so leaving it to scan should not cause a problem.
Mat
Hogyt
Poco Enthusiast
 
Posts: 241
Joined: Thu Jul 29, 2004 11:22 am
Location: England

Postby Sandy » Fri Aug 13, 2004 2:22 am

In my thread in another forum, Jim said

Jim wrote:
One thing you may have missed is the fact that on start up, PocoMail compresses its mailboxes. This may explain your reaction to 3, above.


:? :? :?

How can this be?? A compress of all mailboxes on my system takes about 2 minutes, but startup takes about 10 seconds.
Sandy
 

Postby frazmi » Fri Aug 13, 2004 2:34 am

Oh, NO! How can it be? :? :shock: :wink:
Sandy and I agree two times in one week. I was going to ask the same question!
frazmi
Poco Enthusiast
 
Posts: 248
Joined: Tue Jul 27, 2004 1:27 am
Location: South Korea

Postby robin » Fri Aug 13, 2004 2:39 am

This is a fair question and one that I can't answer. I have my opinion but it'll stay this side of the pond for now.

Oh, and I'm glad to give you two something to agree about :D
robin
 

Postby Sandy » Fri Aug 13, 2004 2:55 am

Perhaps what Jim meant was -- and this is pure speculation -- that the IDX files are built anew each time Poco starts; leaving the MBX files untouched. I know for a fact that it does so if the IDX is missing.

P.S. Wiht Frazmi and I agreeing so much, maybe the stars are lined up and it's time to start investing in the stock market. Whaddya think? :lol:
Sandy
 

Postby robin » Fri Aug 13, 2004 2:59 am

Don't push your luck - today is after all Friday 13th......
robin
 

Postby Alpha » Fri Aug 13, 2004 3:05 am

Pete wrote:Well, I think that you've provided a lot of useful information, frazmi, for people who scan incoming email messages, but I have a different opinion about all of this. :)

I disabled my AV's automatic scan of incoming email messages more than two years ago and I have never re-enabled it. Since PocoMail never automatically runs things in messages, I really don't see a need to scan incoming messages, and it apparently causes a lot of unnecessary problems. Now if someone also uses other email clients besides PocoMail, then that is a different case.


frazmi wrote:If you don't check email on arrival, then you have to check it later using a system-scan of your AV product [...]

While this is true, I don't think that anyone has to manually run a scan of messages or attachments after they have been downloaded or saved to disk files. Norton Anti-Virus, for example, automatically scans an attachment while you're opening it. So when I double click on the attachment in the Attachment Pane, that is the only time when Norton checks it for viruses on my computer. Or, if I run the attachment from Windows Explorer, then Norton checks it at that time. In either case, the attachment is not run from an MBX file. It's run from either the Attach folder or the Cache folder (depending on your settings) so no MBX or IDX files should ever become corrupted using this method.

If your AV program doesn't let you do this the way that I do it, then maybe it's time to switch to a different AV program. :)

Also, if you're concerned about sending viruses to other people, you can surely enable outgoing email scanning. This might not be as problematic as incoming email scanning seems to be, but that's just a guess.


I feel the same way as Pete.
Alpha
 

Postby frazmi » Fri Aug 13, 2004 7:39 pm

Two points to make...

Regarding manual AV scans, all I can say is this: I had Norton AV 2004 set to scan incoming email, and also set to autoprotect. (I didn't have outgoing email scanning turned on.) Many times, when I did a full system scan, NAV reported viruses in attachments in the Poco Attach directory. Symantec was unable (or unwilling) to give me any answers to the question of how NAV missed the incoming virus. So I conclude: Manual AV scans (or periodic automatic scans if you wish) must be done to ensure that my PC (and perhaps yours as well) is free of viruses.

Point number 2: I believe that it's pretty certain that Poco does not do a true compress mailbox at startup, but rather a rebuild of the index files. As evidence, I point to the following:
1) Whatever happens at startup goes way to fast to be a true compression (per Sandy).
2) If you manually garble the index file before Poco starts, Poco just goes ahead and rebuilds it. In the extreme case, if one deletes the index file Poco doesn't even burp -- it just goes ahead and recreates it.
3) If you move a message from one mailbox to the other, then kill Poco (without a proper shutdown), when Poco starts again you will have 2 copies of the message -- one in the source mailbox and one in the target mailbox.
frazmi
Poco Enthusiast
 
Posts: 248
Joined: Tue Jul 27, 2004 1:27 am
Location: South Korea

Next

Return to PocoMail Help and How-To

Who is online

Users browsing this forum: No registered users and 2 guests

cron