INTRODUCTION
24-Nov-2004: Virus Snaggers(tm) 2.2 builds on the success of the 2.0/2.1 series with further refinement and some new tools. I hope you like it. As ever, the What's New section of this document highlights changes and provides news about interim updates, bug fixes, and new tools. I have now removed the full program history from this document in favor of listing only recent changes. The earlier program history can still be found at the website here. I will also continue to leave the final previous version of Virus Snaggers (1.6.1a) up at the site for the time being. Thank you for your continuing interest, suggestions, and trust.
I will discuss
six areas in this file: (a) The license; (b)
what Virus Snaggers is and is not; (c) the philosophy;
(d) what's new; (e) some FAQs
and how-to's for the new version and its variables files; and (f)
the new mailing
list. I am putting (a) first on purpose, even though most of you have probably
not thought much about that. I don't mind if you only skim this file quickly,
but I hope you will look at that part if nothing else. Finally,
please email me if you find any problems or errors, whether in the code
or in these pages.
Virus Snaggers(tm) ver. 2.x ("vsnag") is registered with the U.S. Copyright Office and is the intellectual property of the author. I also claim name trademark rights under common law. I have always agreed to grant a free, non-terminating license for use to individuals and system administrators. I CONTINUE TO DO SO.
That said, it was never my intention to allow work that is uniquely mine to be applied to other projects, programs, or compilations. Nuances of algorithm found here belong here, and not in other people's procmail projects. The free license is granted when the Virus Snaggers plug-ins are used for their stated purpose (finding or blocking classes of unwanted email message files); but not for other, unintended purposes or derivative works.
Take the files, learn from the files, and use them to take back control of your email. But do not lift my work from them for use in your own code. Vsnag does not fall within the GNU Public License, and it never has; and the reason is that I wish to retain rights to my code. I worked hard to get here. If you want to profit from my work, you should contact me with a proposal for collaboration or private licensing. Clarifying, at the risk of repeating myself: the use of the files is free. The code itself is not.
Finally, corporate sysadmins should think hard about whether they wish to support the use and development of this project with funding contributions or grants. Please email me with your questions or comments.
DISCLAIMER AND LEGAL MUMBO-JUMBO: By downloading and installing vsnag, you affirm your understanding that I wrote it without specific knowledge of your system or your particular implementation and that I therefore cannot guarantee any result or warrant against any damage.
You may copy the files for your or your organization's use for their stated purpose. You may not redistribute them commercially; nor may you use them or their code in derivative works. Those installing vsnag should acquire their own copies from the source at spamless.us or at other mirrored sources approved by the copyright holder.
You may edit, alter, or change the files or use parts of them only with two provisions: (i) keep a set of the original files on hand for reference; and (ii) do not obliterate or delete the copyright notice or the accompanying license agreement. It is further requested that you mark any changes as your own.
THE COPYRIGHT OWNER AND AUTHOR PROVIDES THIS SOFTWARE "AS IS," AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Vsnag is a free text-based plug-in to aid email management under procmail on Unix/linux platforms. Procmail is a *nix-based compiled "C" program that one controls using textfile "recipes" to direct, sort, filter, and deliver email as an MDA (mail delivery agent). Vsnag tries to find email messages containing computer viruses or worms and stop them from being delivered to the user's normal inbox. It is intended to be called as a subroutine from an existing procmail "rc" file. To find out more about procmail, visit http://www.procmail.org and view the various links there.
Virus Snaggers is not guaranteed to stop all viruses or worms. It is an
aid only. I designed it to be effective and robust, but I also wrote it with
simplicity
of algorithm in mind. Vsnag is a "classifier" or
sorter of messages, and nothing more. It does not know what a virus looks like
in
a programmatic sense. It is not an anti-virus program in the manner of the
compiled commercial programs available. It finds, for example,
classes
of emailed attachments that in general are considered both suspect
and dangerous; but it doesn't know if a certain "nasty"-looking
attachment is actually infected. It quarantines by appearance or class only.
And though something could get through, I think you will find
it highly useful and helpful in reducing email dangers to a manageable
level. False negatives are also possible, though I've striven
to avoid them.
My coding philosophy is that elegance and simplicity are the Holy Grail. In the pursuit of function, I try to approach coding problems and algorithms with a little bit of poetry, with the wide-open eyes of a child awed by the power of his tools. I want my code to be natural instead of forced, gentle instead of close-fisted, self-documenting in finespun ways. To the extent that anything here remotely does any of that, I am pleased. These statements may well disclose to you that I was a scholar of the humanities long before I took up a coder's credo. The crooked road is often the best.
To date, vsnag uses no shell forks or calls. It's all pure procmail, which makes it very fast and processor-efficient. (The procmail executable itself is only about 71k in size, and it is coded to be "light.") I have not had to rely on recursion as such. More, I have striven to do most of the sleuthwork within only the headers of the email. I shun the notion of stuffing the entirety of every message through "greppy" tests. I try to fight with acumen rather than muscle. Most of the time, the mail headers tip us off to everything we need to know. Traits of the worm writers are discernible, if one only looks. Imagine!
The advent in recent months of the ZIP-payload worms has engendered my big
changes in vsnag. At first, with versions 1.4 and above, I was forced by events
and time pressure to adopt a temporary measure of relying on viral
signatures to combat the ZIP-file carriers. I did not like that, because
I do not envision me spending my time searching for ever-changing
signatures and updating this program constantly with those. More, the signatures
are something much better suited to a compiled program than
a to my text-based approach. So I started watching the virus-laden
messages
and looking for traits. The viruses and worms that come
to you in email do not look like email from your Aunt Martha! So
let's recognize them based on some intelligent screening. That's how I fight
spam in general in my personal email. And that's how we got to
vsnag ver. 2.
[The full program history is no longer listed in this file. It is still available for viewing here.]
Place the four files you just downloaded somewhere reasonable. Make sure they are readable by anyone on your system who will run vsnag from procmail. Make sure, further, that directory permissions permit access to the vsnag files. Then run vsnag from your .procmailrc with a line like this:
INCLUDERC = "/somewhere/reasonable/vsnag.rc"
The above we shall call the standard or default implementation. It assumes you have not changed the names of the files, and that you have placed them all in one location. Virus Snaggers is flexible about where you place it and what you call the files. If you wish to rename the files, naturally you'd first want to change "vsnag.rc" above to your chosen filename. You'd also then need to tell vsnag what name you've given the myvars file. Here is an example of what could go in your .procmailrc in the case of a non-default installation:
VS_MYVARS = "rc.vsnag.myvars.marion"
INCLUDERC = "/somewhere/reasonable/rc.vsnag.main"
That works, presuming that Marion's "myvars" file is in the same directory along with the other vsnag files. If it's not, then give the path. For example:
VS_MYVARS = "$HOME/procmail/rc.vsnag.myvars.marion"
INCLUDERC = "/somewhere/reasonable/rc.vsnag.main"
Relative paths can also work, but be very careful and test the implementation thoroughly.
If you've changed filenames or placed the files in segregated locations, there's one more important step: you'll want to edit the vsnag.myvars.rc file (or whatever you've named it to) and set the $VS_GENVARS variable therein to that file's custom filename, or path and filename.
You are encouraged to open the myvars file and change some of the values to customize vsnag and help it work more efficiently on your system. There is some documentation within that file. I will elucidate further about options in the FAQ just below.
You should not need to change the other files in the package. The genvars file is separate because the variables set within it can be helpful to procmailers generally, even if they're not actively using Virus Snaggers to block viruses or worms. You may well find the vars useful further down in your own .procmailrc in recipes (the name for most procmail code) you create.
Check back at http://vsnag.spamless.us periodically to see if a newer version has been released.
IT IS EXPECTED THAT YOU WILL thoroughly test any proposed
changes to a "live" mail
system before you implement them. For help in testing procmail code, familiarize
yourself with the use of a diagnostic "harness" or
"sandbox." The searchable procmail list archives
linked from http://www.procmail.org can
help with this, as can volunteers on the procmail mailing list. See also Nancy
McGough's QuickStart pages at
http://www.ii.com/internet/robots/procmail/qs/ .
0.0.0:
|
What is Virus Snaggers? |
1.0.0: |
Where can I go for help? |
2.0.0: |
I've installed Virus Snaggers, but nothing seems to be happening. |
2.0.1: |
I see nothing happening. Am I losing mail? |
2.1.0: |
I'm getting false positives (snagged mail that shouldn't be blocked). What should I do? |
3.0.0: |
What is the vsnag.myvars.rc ("myvars") file? |
3.0.1: |
Do I need to bother editing the myvars file? |
3.0.2: |
Tell me more about the "myvars" file and how to set it. What if I leave it as-is, but the settings are not optimal for my system? Will vsnag not work right? |
3.1.0: |
What is $VS_GENVARS? |
3.1.1: |
How do I set $VS_GENVARS? |
3.1.2: |
How do I know if I've set $VS_GENVARS correctly? |
3.2.0: |
What's the $MYVIRUS setting? |
3.3.0: |
Please discuss $VS_HOOK. |
3.4.0: |
What's $MYDOMAINSTUB? |
3.4.1: |
When would I want to set the $MYDOMAINSTUB var in myvars? |
3.4.2: |
What if my situation implies I'd want to set the $MYDOMAINSTUB var, but I don't do so? Will something bad happen? |
3.4.3: |
Okay, how do I set $MYDOMAINSTUB? |
3.5.0: |
What about $MYDOMAIN_IP? |
3.5.1: |
Give me an example of how to set $MYDOMAIN_IP if I have multiple hosts converging here. |
3.6.0: |
What's $VS_SPAMMY, and should I set it? |
3.7.0: |
What's the $h var? |
3.8.0: |
Why might I want to set the $NONDELIVER variable? |
3.9.0: |
How can I use $VBELL? |
3.10.0: |
Just what happens when I set $AGGRESSIVE to on? |
3.10.1: |
Do I need $AGGRESSIVE on to check ZIPs at all? |
3.10.2: |
Can I run $AGGRESSIVE but keep the default ZIP handling? |
3.10.3: |
Can I stop all ZIPs instead of just a certain range? |
3.11.0: |
What's $VS_NASTYEXT for? |
3.11.1: |
Can I block all ZIP files here? |
3.12.0: |
What are $VS_ZIPMIN and $VS_ZIPMAX? |
3.12.1: |
How can I customize my installation to use only the standard ZIP tests but use the tougher scouring heuristics offered with the $AGGRESSIVE switch? |
3.12.2: |
What if I want to block all ZIP attachments? (I'm paranoid.) |
3.12.3: |
Why are some ZIPs being blocked that are outside the range of $VS_ZIPMIN/MAX? |
3.13.0: |
What's $VS_MINBUF, and do I need to change it? |
3.14.0: |
What is the $RCVD_THRESHOLD for? |
3.14.1: |
Should I worry about changing $RCVD_THRESHOLD? |
3.14.2: |
I want to tweak $RCVD_THRESHOLD. How do I find the right value? |
3.14.3: |
Hmm, I forward mail to this server from various others, and thus all messages do not have the same minimum number of Receiveds. |
4.0.0: |
It's annoying to edit your myvars file with the cutesy justified formatting. |
4.0.1: |
Okay, that's rather brilliant; but I don't feel like editing myvars anew each time a vsnag update comes out, either! |
4.1.0: |
Can I have special logging during the vsnag run? |
4.2.0: |
What values work to turn on, or off, vsnag's boolean variables? |
4.3.0: |
Can Virus Snaggers block all ZIP extensions for me? |
4.4.0: |
Can I block individual recipe actions in vsnag without hacking away at the main vsnag.rc file? |
4.5.0: |
Does Virus Snaggers work for system administrators? |
4.6.0: |
How can I help? |
5.0.0: |
A final caveat. |
Please scroll up in this document to Section B.
Resources or links listed herein other than those under spamless.us are independent of Virus Snaggers and are mentioned for informational purposes only. Please do not use the procmail mailing list for questions about Virus Snaggers that are not particularly also about procmail. I am a frequent contributor to the procmail mailing list, but I do not wish to derail that forum or co-opt it for my own projects. Nor will the other fine people on that list wish to be pestered. :-) On the other hand, the vsnag mailing list, about which see (f) below, is a place to ask vsnag-specific questions.
Finally, for further discussion about virus management in
procmail, see
http://www.ii.com/internet/robots/procmail/qs/#viruses .
First, check your procmail logfile. (Check the procmail manpages if you have not set a logfile.) It may be that you've renamed or moved the vsnag.myvars.rc or the vsnag.genvars.rc file, or failed to set file permissions making them readable. If that is the case, you will see a message about it in your log. I've described above, in the basic instruction area, how to point properly to the myvars file. Further below I will discuss genvars.
If there is an error condition interrupting vsnag's operation, your logfile will probably show you an error message about it. The email passing through your .procmailrc should not be lost. Procmail will proceed as if vsnag were not installed, but for the error message mentioned. To further diagnose what you think to be a problem, turn on verbose logging. You can do so by setting $VS_DEBUG to on in your .procmailrc before your call to vsnag:
VS_DEBUG = on
INCLUDERC = "/somewhere/reasonable/vsnag.rc"
The most likely cause of false positives (FPs) would result if vsnag is unable to divine your IP address properly. Vsnag declines to run shell or external processes in general, so has no bulletproof way to determine your server's IP address. If you haven't set the address explicitly (in the “mvars” file, which you should read about in this FAQ), vsnag guesses. The method for guessing is to look in the top Received header in the incoming message. Most – but by no means all – mail servers identify themselves with an IP address in the topmost Received header. If yours does not, or if vsnag is otherwise misidentifying your machine's IP address, you should set it inside the myvars file. Specifically, you will want to look to the $MYDOMAIN_IP var within that file. You should read about that var in this FAQ. It might also be the case that you wish to use a regex for the value you assign to $MYDOMAIN_IP. The FAQ entry describes how to do that and why you might want to.
If you've set the $MYDOMAIN_IP var and you're still having trouble, you are urged to join the vsnag mailing list and discuss the issue with other users and the vsnag code author. See, also, the diagnostics toolkit that has been included with the Virus Snaggers package. Unpack the kit and look at, and run, the point-n-shoot shell script to help you resolve this and other issues.
Vsnag comprises four files, three of which get run from the .procmailrc (The fourth file is the one you're reading. It belongs with the others because it contains documentation and the license.) The three procmail-coded files are vsnag.rc, vsnag.myvars.rc, and vsnag.genvars.rc. To run, vsnag employs a number of variable assignments. The variables are all listed in the myvars file. Ones that you might want to customize are marked with a plus sign (+).
In most cases, no, unless you want to tweak. The one strong exception is if you've renamed vsnag.genvars.rc or placed it somewhere nonstandard (not with the other vsnag files). If you have done that, then you must properly set $VS_GENVARS (which see) in the myvars file. If you forward mail from other accounts to the server where you've installed vsnag, or if there are some other unusual circumstances about your setup, you may want to get deeper into the myvars settings.
Moreover, if you want to block ZIPs completely, look at the section below discussing $VS_NASTYEXT. ZIP fine-tuning in general can also managed in myvars.
Except as described immediately above, myvars is for tweakers or those with unusual setups or a wish to operate vsnag with an optional configuration. Look inside the file; it has quite a bit of documentation in it. Even though some of the settings may not optimally or precisely match your system, things should generally work reasonably well all the same. By adjusting some of the vars to more closely match your system, though, you can improve vsnag's performance. By "improve," I mean obviate or reduce incidences of false negatives (uncaught viruses or worms) or false positives (stopped mail that is not actually infected). Others will want to change some of the configuration options simply to allow vsnag to operate more to their liking.
$VS_GENVARS is a variable, set within the myvars file, which points vsnag to the vsnag.genvars.rc file making up part of the Virus Snaggers package. If you've renamed or moved genvars, you'll want to set the $VS_GENVARS value within the myvars file.
The naming and path information you set the variable to work as described in the main instruction area above with regard to the $VS_MYVARS variable setting. You don't need a path unless you've placed genvars somewhere different from where the other files are located.
If you didn't, vsnag won't run to completion and your logfile will show you an error message about it. Your email passing through your .procmailrc shouldn't be lost. It will be as if vsnag were not installed, but for the error message mentioned.
The $MYVIRUS variable is set to a name to which blocked messages will be saved. The default configuration quarantines stopped messages by placing them in an mbox-style folder called "VIRUS" in the directory that is current at the place in the .procmailrc where you've invoked Virus Snaggers. If you want the folder to be called something else, change "VIRUS" to that something else. You may also set path information, if desired. Example:
MYVIRUS = "/var/tmp/vsnagged"
If you wish to use maildir-style mail folders, place a slash at the end of the pathname. Example:
MYVIRUS = "VIRUS/"
If you're comfortable with the idea of losing any possible false positives (messages vsnag might misidentify as unwanted), you could set $MYVIRUS to /dev/null. But before you settle on such a drastic measure, consider that it might be better to use vsnag's $h var (explained below) to save only headers for those messages deemed infected. See also the $VS_HOOK section below for another approach.
Right before vsnag runs the final, "Delivery" part of its code, it calls an optional INCLUDERC of your creation if such exists. If you wish to implement the option, set the $VS_HOOK var in myvars to point to the path and filename for your INCLUDERC. Paths are relative to the current working dir for your .procmailrc (or use a full path).
There are various uses for such a "hook." At this point in its run, vsnag has set all variables, so you can use whatever of them you like in your own recipes. You can post-process here with custom log entries, delivery of clones of putative viral messages to a second archive, etc. Here's an example recipe you might put in a file to be accessed by the call to $VS_HOOK:
:0 # log snagged files; all vars below but $LOG were defined in vsnag
* $ VS_OUT ?? $TRUE
{ LOG = "$NL ======> Vsnag detected: $VS_OUT <====== $NL" }
You could also use the "hook" rc to post-process and gzip-compress found viruses. For example,
:0:
* $ VS_OUT ?? $TRUE
| gzip -fc9 >> $MYVIRUS
The whole world of procmail customization within vsnag is opened up with $VS_HOOK.
Normally, if your local host is, e.g., mail.foo.co.uk, or smtp.foo.net, or just foo.com, then the "stub" (as I call it) is "foo". Vsnag would find foo properly on its own in each of those examples. Here's the point of it:
Many of the newer worms contain their own virtual SMTP server code right in the binary. A good percentage of messages sent from a computer so infected have over simple markers, such as faked Received headers at the bottom of the chain, among other easily discerned clues. The worm on the infected machine puts the domain "stub" in the forged bottom Received header, because unsophisticated receiving filters might see the name and allow the mail in as "local" without rigorous testing. So vsnag looks for such charlatans.
Similarly, a high percentage of worm code doesn't bother to inject a decent bogus Message-ID header. Since the SMTP bots on infected machines are "mainlining" their messages directly to your incoming SMTP server, your server (or your next upstream, if you use a forwarding service or otherwise chain your host machines and services) will put its own Message-ID header in these messages. The "stub" string is used to find those, as well. But not all locally-generated Message-IDs are bad. So vsnag combines this test with some other likely viral markers to lower the likelihood of misidentifying good mail as a virus or worm. In fact, much of the testing vsnag does in this area only applies to ZIP files (to further reduce general false-positives), since finding dangerous (non-ZIP) file extensions lops out the major source of viruses easily. (Vsnag has always been able to find file attachments with dangerous extensions.)
Virus Snaggers finds it properly on its own unless (a) you forward mail from other domains to the host where vsnag is installed; or (b) the " stub" appearing in locally generated Message-ID headers is not the same as the "stub" of your local host (perhaps because you use an upstream SMTP service or chain differently named hosts together on your system).
Not really. There will be a somewhat increased chance of ZIP attachments slipping through that would otherwise have been blocked. False positives (blocked good mail) won't come into play here.
Note that those who choose to block ZIP attachments overbroadly - either by using the $AGGRESSIVE switch (about which see) or otherwise (e.g., blocking ZIPs via post-processing, for which filtering on the $VS_EXT var within $VS_HOOK would be one suggested method) - have very little need to bother thinking about "stub" at all. That's because its main use is to help find ZIP files that are likely to be nasty.
Suppose your local domain also hosts your mail gateway and is called baz.com. Suppose, further, that you forward mail from foo.com and bar.com to yourself at baz.com. Depending on what locally generated Message-ID headers can look like, you'll want the stub from each of these three names in your variable. Now, complicate the matter by presuming that bar.com's incoming mail all gets handled at qux.net, whose "stub" appears in messages routed to bar.com through that upstream server. Presume further that a different server from yet another domain), quux.com, is a CNAME record for baz.com. Wow, but we'll want all those. In the myvars file, set:
MYDOMAINSTUB = "(foo|bar|baz|qux|quux)"
This var works similarly to $MYDOMAINSTUB insofar as goes why it exists and why you might need to set it manually; and what will happen if you don't (i.e., not much that would be harmful). Virus Snaggers uses the IP address of the current host (or what it thinks is that, see further discussion) in order to guard against falsely snagged local mail, such as could occur if you send yourself or someone on your local system sends you a ZIP file. Vsnag normally looks in the topmost Received header for a good IP address for your host. If one isn't there, or if locally generated mail will actually have a different number (visible in the bottommost Received header), or if, again, you typically collect forwarded mail from other hosts at the local host, you'll want to set a regex pattern for this var.
Something else about $MYDOMAIN_IP in the default operation (when you don't explicitly set it) is that vsnag strips off the last octet of the dotted-quad it found. It does this because some systems use networked hosts with ranged IP addresses whose last octet would differ. Basically, we don't want any mismatches due to this common configuration. So we just ignore the final octet. If you set this var manually, you don't need to worry about this; though it would also be valid to use a numerical regex ("[0-9]*") or nothing at all for the final octet you set.
Okay. Remember that you will want to quote dots! You can do so a couple of ways; the square brackets you see below are the way I chose to show. Suppose you want to include two IP addresses, 123.12.21.1 and 234.23.32.4. Here's how it would look:
MYDOMAIN_IP = "(123[.]12[.]21[.]1|234[.]23[.]32[.]4)"
If that seems too hairy, just forget the whole thing. As mentioned up-top, this is a fine tweak, but nothing horrible will happen if you don't set it.
This new var became available with ver. 2.10 of Virus Snaggers. Some spam messages mimic the suspicious look of virus messages, and vsnag identifies these messages, too. But lumping spam in with more dangerous-seeming messages may not be optimal for you. With the $VS_SPAMMY variable, you can choose to save this special type of snagged message to its own “spammy” folder. As with the $MYVIRUS variable described above, use any file- or dirname you wish, with or without a path. If you don't set this var, then vsnag will continue to snag this type of email and stuff it in with the malicious files in $MYVIRUS.
Set that to on if you prefer to save only message headers for mail that vsnag believes is malicious.
This is the new name for what previously was $NONDEL. Some people told me the name was not self-evident; so now I hope it is. Vsnag is coded to be flexible for users who want to customize their configurations. Supposing you don't wish for Virus Snaggers to block messages at all; but you only wish to add a custom X-header to them. Okay, we can do that! Set $NONDELIVER to yes in myvars, and concoct a filtering procmail recipe that you could place in the $VS_HOOK (which see) INCLUDERC of your own design. The recipe might look like this:
:0 fwh
* $ VS_OUT ?? $TRUE
| formail -i "X-Vsnag: $VS_OUT"
See "man formail" and "man procmailrc" to understand how this works.
For system diagnostics, I use a test harness that sends my procmail log output to my tty as stderr. I leave $VBELL set to on. When I'm not testing, this will make essentially no difference. When I am running my test harness, though, I hear an audible bell when a vsnag detects a snaggable message.
Some tests are expanded to include more messages in the "first cut"; and ZIP attachments are stopped if they are between $VS_ZIPMIN and $VS_ZIPMAX (which see) in size. An example of expanded checking with $AGGRESSIVE is that all files - even those without either traditional attachments or HTML encoding - will be run through a test to see if we can block the Bagle worm variants that merely supply a malevolent web link, but no traditional viral payload.
No. Messages containing ZIP attachments are always checked for typical worm markers. The $AGGRESSIVE switch simply offers a way to ratchet up the protection and block ZIPs based on size alone, even if they seem benign to the vsnag heuristic. (Vsnag might have failed to identify an actual virus or worm.)
Yes, by adjusting $VS_ZIPMIN/MAX, which see.
Yes, by adding ZIP to $VS_NASTYEXT, which see. Alternatively, you could adjust $VS_ZIPMIN/MAX to do this; see that section for more. (The MIN/MAX method would be controlled by the state setting of $AGGRESSIVE.)
Vsnag will block messages containing attachments whose extensions are listed in this var. If you find you are being pestered with virus or worm messages with dangerous attachment types not predefined here, you may add the extensions in yourself. Please edit this variable carefully and consistent with the format given. Comments may not go inside the $VS_NASTYEXT multiline var!
Yes, this is the best (least complicated) way to cause vsnag to block all messages containing ZIP attachments: by adding ZIP to the $VS_NASTYEXT extension set.
If you don't run the $AGGRESSIVE switch, they are of no consequence. If you do use $AGGRESSIVE, then ZIP files between the two values will be snagged, regardless of what vsnag "thinks" of them otherwise.
Set $VS_ZIPMIN to a very high number, such as the largest byte count your system will accept through the mail server. Then set $VS_ZIPMAX to zero.
:-) You can do this with the $VS_ZIPMIN/MAX settings by setting $VS_ZIPMAX to a very high number, such as the largest byte count your system will accept through the mail server; then setting $VS_ZIPMIN to zero. But you may find it easier to block ZIPs by adding that extension to $VS_NASTYEXT, for which see above.
$VS_ZIPMIN/MAX is a range with which all ZIPs
will be blocked if you have turned on the $AGGRESSIVE switch. They do not control
how vsnag interacts with
ZIPs generally, in that messages of any size with ZIP extensions will
be scoured by some of vsnag's recipe algorithms. If you are getting false
positives (blocked clean mail), please report them to the vsnag
author, preferably via the Vsnag Mailing List (about which see the bottom
section of this file). You might also look at the section of this FAQ
below that describes how to turn off various vsnag tests discretely.
With ver. 2.2x of vsnag, this var is no longer customizable from the myvars file. The comfortable minimum vsnag needs to run is 24K of RAM, and the var is set to that in the main vsnag.rc file. In any case, you almost certainly would not wish to change this value. By way of explanation, the var raises the default minimum environment space in your .procmailrc. It offers a roomy, but not piggish, amount of space for vsnag's operation and that of the rest of your rc. But it is only a minimum value. If you are already running with your $LINEBUF (see "man procmail" and "man procmailrc") set higher, nothing at all will happen. In any case, if you wish for the value to be higher, it is suggested that you set $LINEBUF in your own rc-file prior to calling vsnag. (See the procmail man pages for what happens if we run out of env space.) Keep in mind that the default $LINEBUF value in procmail was coded in about a decade ago, and hardware is vastly different nowadays.
It helps vsnag tell if messages were "mainlined" direct to your server, e.g., via the virtual SMTP client that worms often employ. The default has been set to 2. Vsnag counts Received headers; and if there are no more of them than this threshold is set to, the program considers that the mail might have been sent directly from the infected machine to yours, without the intermediary mail servers that non-bulk senders usually use (and which raise the count of Receiveds). If the threshold is too low, vsnag may miss some ZIP attachments with malevolent payloads. Too high, though, can increase false positives (blocked good messages).
If you're running with $AGGRESSIVE on, it's not very important, though it still could help a tiny bit. If you're blocking all ZIPs anyway, this makes no difference at all. Vsnag only uses this test for ZIP files.
Send yourself a message from your local machine. Use your pager or similar means to view the full headers to the message, and count Received headers - but only when they start out like this:
Received: from
Whatever the count is, add one, and set this var to that number.
Better to set this var too high than too low. Move it up to 4 or even 5. You can experiment a bit. If some ZIP files get through vsnag that you think should not have, see if upping this value helps.
Sorry about that; but here's a tip: you don't really need to perform your edits on the particular line you find in the myvars file, along with its comment (the one you're complaining is in your way). You can simply comment out the line you intend to change, and add a new line below it.
Ah. You can do it the way I do, then: I set $VS_MYVARS to a private file (I use "vsnag.myvars.rc.private"). In that file, I make another INCLUDERC call to the default myvars file. Thereafter, I reassign any values I wish to configure differently from the default.
One other thing: the vars in the myvars file could change whenever a new version of Virus Snaggers is released. You'll want to check the file, or at least read the "What's New" section in the readme, before you go on with the status quo of your previous private myvars file.
Yes, you can preset a variable called $VS_DEBUG to change the logging level during your vsnag run only. Thus, if you normally do not turn verbose logging on but want the vsnag subroutine to log its actions verbosely, you can set $VS_DEBUG to on before your call to vsnag. Alternatively, suppose you use verbose logs generally but wish to turn off verbose logging during the vsnag run. Preset $VSNAG to off in that case.
These work in vsnag as detailed in "man procmailrc" (search term: "boolean"). $VS_DEBUG also uses the same syntax.
Yes, easily. See the section above on customizing $VS_NASTYEXT.
If by "block individual recipe actions," you mean you wish to turn off some of the message blocking vsnag does, then the answer is yes! Enable the $VS_HOOK option and create or edit that rc-file. Any message that Virus Snaggers intends to block will have been identified via an assignment to the $VS_OUT variable. Look at your logs to see what value the recipe is assigning, and undo the assignment in your hook rc. Here's an example.
:0
* VS_OUT ?? boundary=suspect
{ VS_OUT }
Now that "boundary=suspect" test in vsnag will be disabled!
Certainly. If you're calling vsnag from a systemwide /etc/procmailrc, we recommend that you use a DROPPRIVS statement prior to the call to vsnag. Alternatively, put DROPPRIVS, along with whatever logging or other options you wish, in the separate hook file that vsnag can now run. See discussion above for $VS_HOOK.
Stay tuned. Meanwhile, report bugs or problems, including typographical errors or confusing language in these docs! And if you come up with any neat $VS_HOOK recipes you think are worth sharing, send them in! I plan to make a contribution area available on the site.
In general Virus Snaggers is targeted at finding attachments designed to trick the mail-reader program into auto-executing them, or at those employing deliberate filename obfuscation. Virus Snaggers doesn't do much to protect people from clicking on something they should not.
The Virus Snaggers mailing list is a small, low-volume list for discussing all aspects of vsnag's application, for disseminating tips, for troubleshooting or general interactive feedback, and for other special customizing issues.To get on or off the vsnag list, send an email to vsnag-list-admin@vsnag.spamless.us. Begin the Subject line of your email with the appropriate of the following commands:
subscribe you@your_address
unsubscribe you@your_address
(You don't need to list your address if you want to subscribe or unsubscribe the address you're writing from.) No human will read your mail. Any body text will be ignored. When you send the list-admin address a command, you will receive a one-time confirmation message at the address specified (or, if none, your sending address).
The vsnag-list is a reflector. Only subscribed members can send to the list. The list administrator reserves the right to unsubscribe without recourse members who the administrator deems are posting inappropriately. The list administrator also reserves the right to moderate list postings. The list is a free service provided by the vsnag author, and there are no durable rights inhered by list members. List members should not republish list postings or material in other forums without asking the list administrator and the original contributor for permission. Copyright remains with individual list contributors. There will be made available on the vsnag website searchable archives of list postings; but these archives will be accessible only to list members and not to general online search engines.
The list is intended to accept text-based, English-language mail only. Please, no PGP sigs, HTML or MIME encoding, attachments, and so on. Top-posting is strongly discouraged.
You can submit bug reports to the code author via the vsnag mailing list. It is suggested that you use the diagnostics plug-in and script now packaged with the program to help you debug.
Happy Virus Snagging,
Dallman Ross <vsnag@spamless.us>
[Top]