How can I stop WLM from scanning outbound email?

Discussion in 'Windows Live Mail' started by M.L., Aug 2, 2012.

  1. M.L.

    M.L. Guest

    I'm not being allowed to send a zip file attachment containing an
    executable that WLM is flagging as a virus even tho it is a false
    positive. How can I prevent WLM from scanning that message so I can
    send it out? Thanks.
     
    M.L., Aug 2, 2012
    #1
    1. Advertisements

  2. M.L.

    ...winston Guest

    WLM doesn't scan email.



    --
    ....winston
    msft mvp mail


    "M.L." wrote in message

    I'm not being allowed to send a zip file attachment containing an
    executable that WLM is flagging as a virus even tho it is a false
    positive. How can I prevent WLM from scanning that message so I can
    send it out? Thanks.
     
    ...winston, Aug 2, 2012
    #2
    1. Advertisements

  3. M.L.

    VanguardLH Guest

    WLM is not an anti-virus product. If your anti-virus program is
    flagging an outbound e-mail as containing a virus, it's up to you to
    scan your host (after updating your AV software) to determine if you do
    indeed have an infected file that you are attempting to pass onto others
    or if it is a false positive (that you should report to your AV vendor).
    If you believe your AV is issuing a false positive, temporarily disable
    your AV scanner to send the e-mail.

    How you manage false positives from your AV product depends on which AV
    product you have but never mentioned here (AV discussions are best
    submitted to an AV newsgroup, like alt.comp.[anti-]virus). WLM isn't
    involved in the virus alert.

    How do you know a file contained within the .zip file is not infected?
    Who created the file inside that .zip archive file? Oops, this probably
    should be discussed in an AV newsgroup.
     
    VanguardLH, Aug 2, 2012
    #3
  4. M.L.

    Magnus Guest

    Let's see. You want to send malware "disguised" in a zip file container,
    but your present system balks. So you want help finding a workaround so
    your destructive payload may be delivered more effectively? No thank you.
     
    Magnus, Aug 4, 2012
    #4
  5. M.L.

    VanguardLH Guest

    You are pretending that you are unaware of what is a "false positive".
    I've had several AV products false alert on the .vhd file (for the
    virtualized disk) for VirtualPC 2007 which contains only a fresh install
    of Windows and all Windows updates. The use of signatures is not a
    perfect method of detecting malware. Goodware can also generate the
    same hash to produce the same signature, especially for large files
    since hashes only encompass a portion of large files.

    http://dictionary.reference.com/browse/false-positive
    http://en.wikipedia.org/wiki/Type_I_and_type_II_errors#False_positive_error
    http://service1.symantec.com/sarc/sarc.nsf/info/html/what.false.positive.html
     
    VanguardLH, Aug 4, 2012
    #5
  6. M.L.

    Magnus Guest

    My POV is that you should have your AV unconnected to your email app.
    More often than not it will adversely affect email performance. That
    said, I would never recommend AV scanning /outgoing/ mail. It simply
    isn't justified. If your AV system is working properly, it would have
    found that "false positive" before you attempted to send it out via email.
     
    Magnus, Aug 5, 2012
    #6
  7. M.L.

    VanguardLH Guest

    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've 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 don't go checking quiescent files - those
    that aren't 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're quiescent then they
    aren't active. Something would have to open those files and if it were
    the parent malware then that's 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've 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 won't be scanning. With scheduled on-demand scans,
    those occur at preset intervals so you won't catch the quiescent file
    until that on-demand scan is scheduled.

    There's also the possibility that the pest is so new that your AV
    program doesn't yet have a signature for it (since we're 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 doesn't 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've 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's 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'd 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 wasn't present before in the non-compressed
    state. Also, the OP didn't 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 won't 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's 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's 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'll
    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's a reason why no decent AV program relies solely on signatures:
    they're 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.
     
    VanguardLH, Aug 5, 2012
    #7
  8. M.L.

    Ildhund Guest

    VanguardLH wrote...
    Thanks for the detailed explanation.
    I sometimes get the impression that the only function of the interception of outgoing mail by security software (AV or anti-spam, for example) is to insert some comforting words into the outgoing message ("Scanned and certified clean by Super Acme Anti-Everything"). There have been several cases in recent months where this insertion - whether as X- headers or as a footer to the message body - has fouled up the text stream to such an extent that the recipient can't read the message. Known culprits I can remember are SPAMfighter and System Mechanic.
    Perhaps you could as a service to the general public edit the text of your post to generalize it, and possible exclude technical terms like MIME that tend to put off the general reader. I often need an explanation like this and usually refer to the Thundercloud text at http://thundercloud.net/infoave/tutorials/email-scanning/index.htm . This article is just as useful as it always has been, but it's so dated that readers may be tempted not to take it seriously.
    I'd happily give such an article space on a page at my WLMail stuff site http://wlmail.wordpress.com .
     
    Ildhund, Aug 5, 2012
    #8
  9. M.L.

    Magnus Guest

    Alternately, the OP could upload the zip and/or exe file to
    www.virustotal.com

    Either way, it's possible that the local AV software could prevent zip
    extraction/manipulation.

    Nice explanation, BTW !
     
    Magnus, Aug 5, 2012
    #9
  10. M.L.

    VanguardLH Guest

    My guess is that adding the files to the .zip archive file in a
    different order would be sufficient to alter the bit pattern on which
    the AV is falsely alerting. If not, just .zip each file and separately
    to add them to the e-mail. Adding a password to encrypt the contents
    would also change the bit pattern in the .zip file. Just remember to
    tell the recipient what is the password. Probably the simplest way is
    to just disable the AV program momentarily while composing and sending
    the e-mail with the attached .zip file.

    Sometimes folks are zipping up an .exe file because a security feature
    in their e-mail client bars them from sending executable files via
    e-mail. Okay, but why not just change the extension of the attached
    file so it isn't an executable filetype. If you want to send an .exe to
    someone, rename the file to .exx, attach it to your e-mail, and tell the
    recipient they have to rename the file when they extract it from the
    e-mail from .exx back to .exe.

    Wonder what M.L. decided to do. I bet he hasn't been waiting these 3
    days to figure out how to get his e-mail sent.
     
    VanguardLH, Aug 6, 2012
    #10
  11. M.L.

    BeeJ Guest

    M.L. laid this down on his screen :
    1) encrypt the data as it goes into the zip file. 7Zip and WinZip do
    this. (or encrypt after adding using 7Zip or WinZip encrypt)
    2) change the name of the .zip to .z
     
    BeeJ, Aug 7, 2012
    #11
  12. M.L.

    M.L. Guest

    I want to thank all who replied for their recommendations. Sorry for
    the delayed response but I decided to upload the file to Adrive and
    have the recipient download it from there.

    My AV is MSSE and I see no way to disable email scanning with that
    app. Temporarily disabling MSSE while sending flagged files sounds
    like the perfect solution since I rarely send email executables
    anyway. In fact, after the false flagging I'll probably stop sending
    zip-enclosed executables by email.
     
    M.L., Aug 19, 2012
    #12
  13. M.L.

    Bruce Hagen Guest




    Open MSE | Settings | Excluded File Types and add .eml. See if that
    helps.
     
    Bruce Hagen, Aug 19, 2012
    #13
  14. M.L.

    StephenB Guest

    StephenB, Aug 19, 2012
    #14
  15. M.L.

    StephenB Guest

    I'll add that the issue is likely to be that MSE is seeing the .zip file as
    infected -- not that it is preventing the sending of the attachments.
    -steve
     
    StephenB, Aug 19, 2012
    #15
  16. M.L.

    Ildhund Guest

    Bruce Hagen wrote...
    I don't know anything much about AV, but I would have thought that excluding the one file type most likely to carry infection is a highly dubious suggestion. WLMail converts the incoming mail text stream to a file which is then written to disk. Since the stream itself is not being scanned, the only opportunity MSE has to detect anything nasty is before the .eml file is written. Or is there something I've misunderstood?
     
    Ildhund, Aug 19, 2012
    #16
  17. M.L.

    Good Guy Guest

    Generally this is an anti-virus setting but some don't scan by default
    like Microsoft's Security Essentials. With others like AVG you need to
    configure it but I don't use it anymore so can't help you here.

    What is your anti-virus? Perhaps google for it and the solution will be
    there out there.

    Good luck.

    --
    Good Guy
    Website: http://mytaxsite.co.uk
    Website: http://html-css.co.uk
    Forums: http://mytaxsite.boardhost.com
    Email: http://mytaxsite.co.uk/contact-us
     
    Good Guy, Aug 19, 2012
    #17
  18. M.L.

    M.L. Guest

    But the zip remained in my outbox.
     
    M.L., Aug 19, 2012
    #18
  19. M.L.

    ...winston Guest

    The process was interrupted before it could be sent.
    Temporarily exclude the zip file from MSE
    or better yet ....rename the file with a different extension, exclude that extension in MSE

    Note: Delete the original message from the Outbox, recreate the message and attach the file then send the message.

    Do not exclude *.eml from MSE.


    --
    ....winston
    msft mvp mail


    "M.L." wrote in message
    But the zip remained in my outbox.
     
    ...winston, Aug 19, 2012
    #19
  20. M.L.

    ...winston Guest

    Answered 8 hrs earlier in this thread
    "My AV is MSSE"
    which probably means M icro S oft S ecurity E ssentials



    --
    ....winston
    msft mvp mail


    "Good Guy" wrote in message
    Generally this is an anti-virus setting but some don't scan by default
    like Microsoft's Security Essentials. With others like AVG you need to
    configure it but I don't use it anymore so can't help you here.

    What is your anti-virus? Perhaps google for it and the solution will be
    there out there.

    Good luck.

    --
    Good Guy
    Website: http://mytaxsite.co.uk
    Website: http://html-css.co.uk
    Forums: http://mytaxsite.boardhost.com
    Email: http://mytaxsite.co.uk/contact-us
     
    ...winston, Aug 19, 2012
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.