I figure any e-mail scanning, inbound or outbound, is superfluous. The
same engine and signatures used for the on-access (realtime) scanner is
the same employed to interrogate e-mail traffic. That means if your
inbound e-mail has malware that it get detected by the on-access scanner
if and when you extract the text-only encoded string in the MIME part in
the e-mail to create a file to store that extracted content. Your AV
should already detect if you have infected files on your host before you
even attempt to encode it into the MIME text string in an outbound
e-mail. You gain no further detection coverage by scanning your e-mail.
You only change when the detection takes place: during e-mail transfer
(which it is unimportant since the malware exists merely as a text
string within a MIME part) or later when you attempt to decode the text
string to create a new file to store that content.
E-mail scanning always affects performance since it is interrogating
your e-mail traffic. That delay can cause timeouts between the client
and server. For some AV products, it can hide the true status of an
e-mail transaction. Some work by pretending they are the server to the
client and pretending they are the client to the server. The client
connects to what it thinks is the server but instead connects to the AV
interrogation proxy. Since the AV proxy returns a good status the
e-mail client is told the e-mail transaction completed okay but there
has yet been no real e-mail transfer. After interrogating the e-mail
message, the AV proxy then pretends it is the client and connects to the
real SMTP server to actually transfer and send the message. If there is
a failure in that e-mail session, the AV proxy knows about it but not
the real e-mail client. So the user thinks their e-mail got sent okay
but, in fact, the e-mail session failed between AV proxy and server.
The only way the user knows for sure whether or not their e-mail
actually got sent is to look in the logs of their AV program, if that
feature is available.
Some AV proxies interrogate on-the-fly: they inspect the e-mail traffic
during the e-mail session between real e-mail client and real e-mail
server but this still generates a delay and sometimes enough to generate
timeouts with the user seeing errors issued by their e-mail client which
is not its fault. Also, I have seen where these transparent AV proxies go
brain dead. They simply stop functioning so the user cannot send or
receive any e-mail. Disabling and reenabling the AV program does not
kick their proxy to start working again. Typically the user has to
reboot Windows to get the AV driver reloaded and its service(s) running
correctly again. I remember figuring out how to stop and restart
processes for Norton AV so I could kill and restart its proxy and
support processes in the correct order rather than have to reboot
Windows.
Understand that the on-access scanner is only useful for detecting pests
when files are written (which includes when they are created since they
are also being written). They do not go checking quiescent files - those
that are not being opened. That's why you scheduled periodic on-demand
scans to include inspection of quiescent files to see if you have
malware lurking on your host. Of course, if they are quiescent then they
are not active. Something would have to open those files and if it were
the parent malware then that is what would get detected and if the
quiescent file were executable then it gets inspected. It is possible,
for example, for malware to get onto your host when you disable your AV
program. When you install some programs, the AV program can interfere
with its installation. So the user disables the AV program to get the
known software installed and then reenables the AV program. Having to
disable, install, and reenable the AV program is not a rare event.
However, sometimes users forget to reenable the AV program. I have done
that several times when I had to get the AV program out of the way but
got busy and forgot to reenable it so I was unprotected. During this
window of vulnerability is when you might create a file on your host.
Reenabling your AV program does not have it scan every new file that
appeared between when the AV program got disabled to when it got
reenabled. So now you have a quiescent infected file that your
on-access scanner will not be scanning. With scheduled on-demand scans,
those occur at preset intervals so you will not catch the quiescent file
until that on-demand scan is scheduled.
There is also the possibility that the pest is so new that your AV
program does not yet have a signature for it (since we are talking about
including an infected file in a .zip file and not catching it using
heuristics when running the file). You create the .zip file when you AV
program does not yet know about the pest. Sometime later you go to
attach the .zip file which is writing to a file and the on-access
scanner catches the pest because you have gotten updated signatures
sometime after you created the .zip file. So what the OP thought was
clean when they created a .zip file was alerted upon sometime later
because their AV signatures got updated.
Then there is the question of just how an AV program delves into a .zip
file to inspect the files within. Does it actually spend the time to
expand the .zip file into the separate files? That would take a long
time, especially when considering the purpose of a .zip archive is to
compress really big files into something much smaller. So you would think
they would read into the .zip file instead of expanding it. Since
compression generates wholly new bit patterns for the compressed content
stored within, I can see that that where the source files were tested
clean could result in a bit pattern in the compressed state that matches
on a signature pattern that was not present before in the non-compressed
state. Also, the OP did not say the alert was on a file within the .zip
archive but on the .zip archive itself. Again, the bit patterns of the
files stored within a .zip file will obviously not be the same as the
bit patterns for the non-compressed source files. This is why I get
false positives on the .vhd file: although the AV program will not find any
of its source files (in the virtual machine) to be infected, the bit
patterns for their compressed storage in the .vhd file might match on a
signature pattern. When testing on the compressed archive, you are not
testing against the source files but a change bit pattern when they got
compressed to get stored. Then there is the password encryption involved
with compressed archives which further alters the bit pattern of the
files contained therein.
The OP probably should extract the files to a temp folder, update his AV
program, run a scan on the extracted files to make sure they test clean
by the AV program, and then zip them up again. it is unknown who is the
source of the .zip file or when it got created relative to when it then
got attached to an e-mail. If the .zip attachment still generates an
alert (because the OP has decided they still want to incorporate the
superfluous e-mail scanning feature of their AV program) then they will
need to disable their AV program while composing and sending that
particular e-mail. Submitting the .zip file would probably be of little
value in trying to get the signature database updated to eliminate the
false positive because any change in compiling the .zip file, like file
order, size, or password would alter the bit pattern that happened to
match on a signature.
There is a reason why no decent AV program relies solely on signatures:
they are not a wholly reliable mechanism to detect malware with no
negative side effects and no deficiency in detection coverage. They're
like hanging fly catchers in your windows when screens would work so
much better but you do have to use the doors so the fly catchers still
have some value. The fly catchers work okay but sometimes you find them
stuck to your dog, and your dog is not a fly. Signatures do NOT always
identify solely malware.