@@ -0,0 +1,962 @@ | |||
LATEST VERSION | |||
You always find news about what's going on as well as the latest versions | |||
from the curl web pages, located at: | |||
http://curl.haxx.se | |||
SIMPLE USAGE | |||
Get the main page from Netscape's web-server: | |||
curl http://www.netscape.com/ | |||
Get the README file the user's home directory at funet's ftp-server: | |||
curl ftp://ftp.funet.fi/README | |||
Get a web page from a server using port 8000: | |||
curl http://www.weirdserver.com:8000/ | |||
Get a list of a directory of an FTP site: | |||
curl ftp://cool.haxx.se/ | |||
Get the definition of curl from a dictionary: | |||
curl dict://dict.org/m:curl | |||
Fetch two documents at once: | |||
curl ftp://cool.haxx.se/ http://www.weirdserver.com:8000/ | |||
Get a file off an FTPS server: | |||
curl ftps://files.are.secure.com/secrets.txt | |||
or use the more appropriate FTPS way to get the same file: | |||
curl --ftp-ssl ftp://files.are.secure.com/secrets.txt | |||
Get a file from an SSH server using SFTP: | |||
curl -u username sftp://shell.example.com/etc/issue | |||
Get a file from an SSH server using SCP using a private key to authenticate: | |||
curl -u username: --key ~/.ssh/id_dsa --pubkey ~/.ssh/id_dsa.pub \ | |||
scp://shell.example.com/~/personal.txt | |||
Get the main page from an IPv6 web server: | |||
curl -g "http://[2001:1890:1112:1::20]/" | |||
DOWNLOAD TO A FILE | |||
Get a web page and store in a local file: | |||
curl -o thatpage.html http://www.netscape.com/ | |||
Get a web page and store in a local file, make the local file get the name | |||
of the remote document (if no file name part is specified in the URL, this | |||
will fail): | |||
curl -O http://www.netscape.com/index.html | |||
Fetch two files and store them with their remote names: | |||
curl -O www.haxx.se/index.html -O curl.haxx.se/download.html | |||
USING PASSWORDS | |||
FTP | |||
To ftp files using name+passwd, include them in the URL like: | |||
curl ftp://name:passwd@machine.domain:port/full/path/to/file | |||
or specify them with the -u flag like | |||
curl -u name:passwd ftp://machine.domain:port/full/path/to/file | |||
FTPS | |||
It is just like for FTP, but you may also want to specify and use | |||
SSL-specific options for certificates etc. | |||
Note that using FTPS:// as prefix is the "implicit" way as described in the | |||
standards while the recommended "explicit" way is done by using FTP:// and | |||
the --ftp-ssl option. | |||
SFTP / SCP | |||
This is similar to FTP, but you can specify a private key to use instead of | |||
a password. Note that the private key may itself be protected by a password | |||
that is unrelated to the login password of the remote system. If you | |||
provide a private key file you must also provide a public key file. | |||
HTTP | |||
Curl also supports user and password in HTTP URLs, thus you can pick a file | |||
like: | |||
curl http://name:passwd@machine.domain/full/path/to/file | |||
or specify user and password separately like in | |||
curl -u name:passwd http://machine.domain/full/path/to/file | |||
HTTP offers many different methods of authentication and curl supports | |||
several: Basic, Digest, NTLM and Negotiate. Without telling which method to | |||
use, curl defaults to Basic. You can also ask curl to pick the most secure | |||
ones out of the ones that the server accepts for the given URL, by using | |||
--anyauth. | |||
NOTE! Since HTTP URLs don't support user and password, you can't use that | |||
style when using Curl via a proxy. You _must_ use the -u style fetch | |||
during such circumstances. | |||
HTTPS | |||
Probably most commonly used with private certificates, as explained below. | |||
PROXY | |||
Get an ftp file using a proxy named my-proxy that uses port 888: | |||
curl -x my-proxy:888 ftp://ftp.leachsite.com/README | |||
Get a file from a HTTP server that requires user and password, using the | |||
same proxy as above: | |||
curl -u user:passwd -x my-proxy:888 http://www.get.this/ | |||
Some proxies require special authentication. Specify by using -U as above: | |||
curl -U user:passwd -x my-proxy:888 http://www.get.this/ | |||
curl also supports SOCKS4 and SOCKS5 proxies with --socks4 and --socks5. | |||
See also the environment variables Curl support that offer further proxy | |||
control. | |||
RANGES | |||
With HTTP 1.1 byte-ranges were introduced. Using this, a client can request | |||
to get only one or more subparts of a specified document. Curl supports | |||
this with the -r flag. | |||
Get the first 100 bytes of a document: | |||
curl -r 0-99 http://www.get.this/ | |||
Get the last 500 bytes of a document: | |||
curl -r -500 http://www.get.this/ | |||
Curl also supports simple ranges for FTP files as well. Then you can only | |||
specify start and stop position. | |||
Get the first 100 bytes of a document using FTP: | |||
curl -r 0-99 ftp://www.get.this/README | |||
UPLOADING | |||
FTP / FTPS / SFTP / SCP | |||
Upload all data on stdin to a specified server: | |||
curl -T - ftp://ftp.upload.com/myfile | |||
Upload data from a specified file, login with user and password: | |||
curl -T uploadfile -u user:passwd ftp://ftp.upload.com/myfile | |||
Upload a local file to the remote site, and use the local file name remote | |||
too: | |||
curl -T uploadfile -u user:passwd ftp://ftp.upload.com/ | |||
Upload a local file to get appended to the remote file: | |||
curl -T localfile -a ftp://ftp.upload.com/remotefile | |||
Curl also supports ftp upload through a proxy, but only if the proxy is | |||
configured to allow that kind of tunneling. If it does, you can run curl in | |||
a fashion similar to: | |||
curl --proxytunnel -x proxy:port -T localfile ftp.upload.com | |||
HTTP | |||
Upload all data on stdin to a specified http site: | |||
curl -T - http://www.upload.com/myfile | |||
Note that the http server must have been configured to accept PUT before | |||
this can be done successfully. | |||
For other ways to do http data upload, see the POST section below. | |||
VERBOSE / DEBUG | |||
If curl fails where it isn't supposed to, if the servers don't let you in, | |||
if you can't understand the responses: use the -v flag to get verbose | |||
fetching. Curl will output lots of info and what it sends and receives in | |||
order to let the user see all client-server interaction (but it won't show | |||
you the actual data). | |||
curl -v ftp://ftp.upload.com/ | |||
To get even more details and information on what curl does, try using the | |||
--trace or --trace-ascii options with a given file name to log to, like | |||
this: | |||
curl --trace trace.txt www.haxx.se | |||
DETAILED INFORMATION | |||
Different protocols provide different ways of getting detailed information | |||
about specific files/documents. To get curl to show detailed information | |||
about a single file, you should use -I/--head option. It displays all | |||
available info on a single file for HTTP and FTP. The HTTP information is a | |||
lot more extensive. | |||
For HTTP, you can get the header information (the same as -I would show) | |||
shown before the data by using -i/--include. Curl understands the | |||
-D/--dump-header option when getting files from both FTP and HTTP, and it | |||
will then store the headers in the specified file. | |||
Store the HTTP headers in a separate file (headers.txt in the example): | |||
curl --dump-header headers.txt curl.haxx.se | |||
Note that headers stored in a separate file can be very useful at a later | |||
time if you want curl to use cookies sent by the server. More about that in | |||
the cookies section. | |||
POST (HTTP) | |||
It's easy to post data using curl. This is done using the -d <data> | |||
option. The post data must be urlencoded. | |||
Post a simple "name" and "phone" guestbook. | |||
curl -d "name=Rafael%20Sagula&phone=3320780" \ | |||
http://www.where.com/guest.cgi | |||
How to post a form with curl, lesson #1: | |||
Dig out all the <input> tags in the form that you want to fill in. (There's | |||
a perl program called formfind.pl on the curl site that helps with this). | |||
If there's a "normal" post, you use -d to post. -d takes a full "post | |||
string", which is in the format | |||
<variable1>=<data1>&<variable2>=<data2>&... | |||
The 'variable' names are the names set with "name=" in the <input> tags, and | |||
the data is the contents you want to fill in for the inputs. The data *must* | |||
be properly URL encoded. That means you replace space with + and that you | |||
write weird letters with %XX where XX is the hexadecimal representation of | |||
the letter's ASCII code. | |||
Example: | |||
(page located at http://www.formpost.com/getthis/ | |||
<form action="post.cgi" method="post"> | |||
<input name=user size=10> | |||
<input name=pass type=password size=10> | |||
<input name=id type=hidden value="blablabla"> | |||
<input name=ding value="submit"> | |||
</form> | |||
We want to enter user 'foobar' with password '12345'. | |||
To post to this, you enter a curl command line like: | |||
curl -d "user=foobar&pass=12345&id=blablabla&ding=submit" (continues) | |||
http://www.formpost.com/getthis/post.cgi | |||
While -d uses the application/x-www-form-urlencoded mime-type, generally | |||
understood by CGI's and similar, curl also supports the more capable | |||
multipart/form-data type. This latter type supports things like file upload. | |||
-F accepts parameters like -F "name=contents". If you want the contents to | |||
be read from a file, use <@filename> as contents. When specifying a file, | |||
you can also specify the file content type by appending ';type=<mime type>' | |||
to the file name. You can also post the contents of several files in one | |||
field. For example, the field name 'coolfiles' is used to send three files, | |||
with different content types using the following syntax: | |||
curl -F "coolfiles=@fil1.gif;type=image/gif,fil2.txt,fil3.html" \ | |||
http://www.post.com/postit.cgi | |||
If the content-type is not specified, curl will try to guess from the file | |||
extension (it only knows a few), or use the previously specified type (from | |||
an earlier file if several files are specified in a list) or else it will | |||
using the default type 'text/plain'. | |||
Emulate a fill-in form with -F. Let's say you fill in three fields in a | |||
form. One field is a file name which to post, one field is your name and one | |||
field is a file description. We want to post the file we have written named | |||
"cooltext.txt". To let curl do the posting of this data instead of your | |||
favourite browser, you have to read the HTML source of the form page and | |||
find the names of the input fields. In our example, the input field names | |||
are 'file', 'yourname' and 'filedescription'. | |||
curl -F "file=@cooltext.txt" -F "yourname=Daniel" \ | |||
-F "filedescription=Cool text file with cool text inside" \ | |||
http://www.post.com/postit.cgi | |||
To send two files in one post you can do it in two ways: | |||
1. Send multiple files in a single "field" with a single field name: | |||
curl -F "pictures=@dog.gif,cat.gif" | |||
2. Send two fields with two field names: | |||
curl -F "docpicture=@dog.gif" -F "catpicture=@cat.gif" | |||
To send a field value literally without interpreting a leading '@' | |||
or '<', or an embedded ';type=', use --form-string instead of | |||
-F. This is recommended when the value is obtained from a user or | |||
some other unpredictable source. Under these circumstances, using | |||
-F instead of --form-string would allow a user to trick curl into | |||
uploading a file. | |||
REFERRER | |||
A HTTP request has the option to include information about which address | |||
that referred to actual page. Curl allows you to specify the | |||
referrer to be used on the command line. It is especially useful to | |||
fool or trick stupid servers or CGI scripts that rely on that information | |||
being available or contain certain data. | |||
curl -e www.coolsite.com http://www.showme.com/ | |||
NOTE: The Referer: [sic] field is defined in the HTTP spec to be a full URL. | |||
USER AGENT | |||
A HTTP request has the option to include information about the browser | |||
that generated the request. Curl allows it to be specified on the command | |||
line. It is especially useful to fool or trick stupid servers or CGI | |||
scripts that only accept certain browsers. | |||
Example: | |||
curl -A 'Mozilla/3.0 (Win95; I)' http://www.nationsbank.com/ | |||
Other common strings: | |||
'Mozilla/3.0 (Win95; I)' Netscape Version 3 for Windows 95 | |||
'Mozilla/3.04 (Win95; U)' Netscape Version 3 for Windows 95 | |||
'Mozilla/2.02 (OS/2; U)' Netscape Version 2 for OS/2 | |||
'Mozilla/4.04 [en] (X11; U; AIX 4.2; Nav)' NS for AIX | |||
'Mozilla/4.05 [en] (X11; U; Linux 2.0.32 i586)' NS for Linux | |||
Note that Internet Explorer tries hard to be compatible in every way: | |||
'Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)' MSIE for W95 | |||
Mozilla is not the only possible User-Agent name: | |||
'Konqueror/1.0' KDE File Manager desktop client | |||
'Lynx/2.7.1 libwww-FM/2.14' Lynx command line browser | |||
COOKIES | |||
Cookies are generally used by web servers to keep state information at the | |||
client's side. The server sets cookies by sending a response line in the | |||
headers that looks like 'Set-Cookie: <data>' where the data part then | |||
typically contains a set of NAME=VALUE pairs (separated by semicolons ';' | |||
like "NAME1=VALUE1; NAME2=VALUE2;"). The server can also specify for what | |||
path the "cookie" should be used for (by specifying "path=value"), when the | |||
cookie should expire ("expire=DATE"), for what domain to use it | |||
("domain=NAME") and if it should be used on secure connections only | |||
("secure"). | |||
If you've received a page from a server that contains a header like: | |||
Set-Cookie: sessionid=boo123; path="/foo"; | |||
it means the server wants that first pair passed on when we get anything in | |||
a path beginning with "/foo". | |||
Example, get a page that wants my name passed in a cookie: | |||
curl -b "name=Daniel" www.sillypage.com | |||
Curl also has the ability to use previously received cookies in following | |||
sessions. If you get cookies from a server and store them in a file in a | |||
manner similar to: | |||
curl --dump-header headers www.example.com | |||
... you can then in a second connect to that (or another) site, use the | |||
cookies from the 'headers' file like: | |||
curl -b headers www.example.com | |||
While saving headers to a file is a working way to store cookies, it is | |||
however error-prone and not the preferred way to do this. Instead, make curl | |||
save the incoming cookies using the well-known netscape cookie format like | |||
this: | |||
curl -c cookies.txt www.example.com | |||
Note that by specifying -b you enable the "cookie awareness" and with -L | |||
you can make curl follow a location: (which often is used in combination | |||
with cookies). So that if a site sends cookies and a location, you can | |||
use a non-existing file to trigger the cookie awareness like: | |||
curl -L -b empty.txt www.example.com | |||
The file to read cookies from must be formatted using plain HTTP headers OR | |||
as netscape's cookie file. Curl will determine what kind it is based on the | |||
file contents. In the above command, curl will parse the header and store | |||
the cookies received from www.example.com. curl will send to the server the | |||
stored cookies which match the request as it follows the location. The | |||
file "empty.txt" may be a nonexistent file. | |||
Alas, to both read and write cookies from a netscape cookie file, you can | |||
set both -b and -c to use the same file: | |||
curl -b cookies.txt -c cookies.txt www.example.com | |||
PROGRESS METER | |||
The progress meter exists to show a user that something actually is | |||
happening. The different fields in the output have the following meaning: | |||
% Total % Received % Xferd Average Speed Time Curr. | |||
Dload Upload Total Current Left Speed | |||
0 151M 0 38608 0 0 9406 0 4:41:43 0:00:04 4:41:39 9287 | |||
From left-to-right: | |||
% - percentage completed of the whole transfer | |||
Total - total size of the whole expected transfer | |||
% - percentage completed of the download | |||
Received - currently downloaded amount of bytes | |||
% - percentage completed of the upload | |||
Xferd - currently uploaded amount of bytes | |||
Average Speed | |||
Dload - the average transfer speed of the download | |||
Average Speed | |||
Upload - the average transfer speed of the upload | |||
Time Total - expected time to complete the operation | |||
Time Current - time passed since the invoke | |||
Time Left - expected time left to completion | |||
Curr.Speed - the average transfer speed the last 5 seconds (the first | |||
5 seconds of a transfer is based on less time of course.) | |||
The -# option will display a totally different progress bar that doesn't | |||
need much explanation! | |||
SPEED LIMIT | |||
Curl allows the user to set the transfer speed conditions that must be met | |||
to let the transfer keep going. By using the switch -y and -Y you | |||
can make curl abort transfers if the transfer speed is below the specified | |||
lowest limit for a specified time. | |||
To have curl abort the download if the speed is slower than 3000 bytes per | |||
second for 1 minute, run: | |||
curl -Y 3000 -y 60 www.far-away-site.com | |||
This can very well be used in combination with the overall time limit, so | |||
that the above operation must be completed in whole within 30 minutes: | |||
curl -m 1800 -Y 3000 -y 60 www.far-away-site.com | |||
Forcing curl not to transfer data faster than a given rate is also possible, | |||
which might be useful if you're using a limited bandwidth connection and you | |||
don't want your transfer to use all of it (sometimes referred to as | |||
"bandwidth throttle"). | |||
Make curl transfer data no faster than 10 kilobytes per second: | |||
curl --limit-rate 10K www.far-away-site.com | |||
or | |||
curl --limit-rate 10240 www.far-away-site.com | |||
Or prevent curl from uploading data faster than 1 megabyte per second: | |||
curl -T upload --limit-rate 1M ftp://uploadshereplease.com | |||
When using the --limit-rate option, the transfer rate is regulated on a | |||
per-second basis, which will cause the total transfer speed to become lower | |||
than the given number. Sometimes of course substantially lower, if your | |||
transfer stalls during periods. | |||
CONFIG FILE | |||
Curl automatically tries to read the .curlrc file (or _curlrc file on win32 | |||
systems) from the user's home dir on startup. | |||
The config file could be made up with normal command line switches, but you | |||
can also specify the long options without the dashes to make it more | |||
readable. You can separate the options and the parameter with spaces, or | |||
with = or :. Comments can be used within the file. If the first letter on a | |||
line is a '#'-letter the rest of the line is treated as a comment. | |||
If you want the parameter to contain spaces, you must enclose the entire | |||
parameter within double quotes ("). Within those quotes, you specify a | |||
quote as \". | |||
NOTE: You must specify options and their arguments on the same line. | |||
Example, set default time out and proxy in a config file: | |||
# We want a 30 minute timeout: | |||
-m 1800 | |||
# ... and we use a proxy for all accesses: | |||
proxy = proxy.our.domain.com:8080 | |||
White spaces ARE significant at the end of lines, but all white spaces | |||
leading up to the first characters of each line are ignored. | |||
Prevent curl from reading the default file by using -q as the first command | |||
line parameter, like: | |||
curl -q www.thatsite.com | |||
Force curl to get and display a local help page in case it is invoked | |||
without URL by making a config file similar to: | |||
# default url to get | |||
url = "http://help.with.curl.com/curlhelp.html" | |||
You can specify another config file to be read by using the -K/--config | |||
flag. If you set config file name to "-" it'll read the config from stdin, | |||
which can be handy if you want to hide options from being visible in process | |||
tables etc: | |||
echo "user = user:passwd" | curl -K - http://that.secret.site.com | |||
EXTRA HEADERS | |||
When using curl in your own very special programs, you may end up needing | |||
to pass on your own custom headers when getting a web page. You can do | |||
this by using the -H flag. | |||
Example, send the header "X-you-and-me: yes" to the server when getting a | |||
page: | |||
curl -H "X-you-and-me: yes" www.love.com | |||
This can also be useful in case you want curl to send a different text in a | |||
header than it normally does. The -H header you specify then replaces the | |||
header curl would normally send. If you replace an internal header with an | |||
empty one, you prevent that header from being sent. To prevent the Host: | |||
header from being used: | |||
curl -H "Host:" www.server.com | |||
FTP and PATH NAMES | |||
Do note that when getting files with the ftp:// URL, the given path is | |||
relative the directory you enter. To get the file 'README' from your home | |||
directory at your ftp site, do: | |||
curl ftp://user:passwd@my.site.com/README | |||
But if you want the README file from the root directory of that very same | |||
site, you need to specify the absolute file name: | |||
curl ftp://user:passwd@my.site.com//README | |||
(I.e with an extra slash in front of the file name.) | |||
SFTP and SCP and PATH NAMES | |||
With sftp: and scp: URLs, the path name given is the absolute name on the | |||
server. To access a file relative to the remote user's home directory, | |||
prefix the file with /~/ , such as: | |||
curl -u $USER sftp://home.example.com/~/.bashrc | |||
FTP and firewalls | |||
The FTP protocol requires one of the involved parties to open a second | |||
connection as soon as data is about to get transfered. There are two ways to | |||
do this. | |||
The default way for curl is to issue the PASV command which causes the | |||
server to open another port and await another connection performed by the | |||
client. This is good if the client is behind a firewall that don't allow | |||
incoming connections. | |||
curl ftp.download.com | |||
If the server for example, is behind a firewall that don't allow connections | |||
on other ports than 21 (or if it just doesn't support the PASV command), the | |||
other way to do it is to use the PORT command and instruct the server to | |||
connect to the client on the given (as parameters to the PORT command) IP | |||
number and port. | |||
The -P flag to curl supports a few different options. Your machine may have | |||
several IP-addresses and/or network interfaces and curl allows you to select | |||
which of them to use. Default address can also be used: | |||
curl -P - ftp.download.com | |||
Download with PORT but use the IP address of our 'le0' interface (this does | |||
not work on windows): | |||
curl -P le0 ftp.download.com | |||
Download with PORT but use 192.168.0.10 as our IP address to use: | |||
curl -P 192.168.0.10 ftp.download.com | |||
NETWORK INTERFACE | |||
Get a web page from a server using a specified port for the interface: | |||
curl --interface eth0:1 http://www.netscape.com/ | |||
or | |||
curl --interface 192.168.1.10 http://www.netscape.com/ | |||
HTTPS | |||
Secure HTTP requires SSL libraries to be installed and used when curl is | |||
built. If that is done, curl is capable of retrieving and posting documents | |||
using the HTTPS protocol. | |||
Example: | |||
curl https://www.secure-site.com | |||
Curl is also capable of using your personal certificates to get/post files | |||
from sites that require valid certificates. The only drawback is that the | |||
certificate needs to be in PEM-format. PEM is a standard and open format to | |||
store certificates with, but it is not used by the most commonly used | |||
browsers (Netscape and MSIE both use the so called PKCS#12 format). If you | |||
want curl to use the certificates you use with your (favourite) browser, you | |||
may need to download/compile a converter that can convert your browser's | |||
formatted certificates to PEM formatted ones. This kind of converter is | |||
included in recent versions of OpenSSL, and for older versions Dr Stephen | |||
N. Henson has written a patch for SSLeay that adds this functionality. You | |||
can get his patch (that requires an SSLeay installation) from his site at: | |||
http://www.drh-consultancy.demon.co.uk/ | |||
Example on how to automatically retrieve a document using a certificate with | |||
a personal password: | |||
curl -E /path/to/cert.pem:password https://secure.site.com/ | |||
If you neglect to specify the password on the command line, you will be | |||
prompted for the correct password before any data can be received. | |||
Many older SSL-servers have problems with SSLv3 or TLS, that newer versions | |||
of OpenSSL etc is using, therefore it is sometimes useful to specify what | |||
SSL-version curl should use. Use -3, -2 or -1 to specify that exact SSL | |||
version to use (for SSLv3, SSLv2 or TLSv1 respectively): | |||
curl -2 https://secure.site.com/ | |||
Otherwise, curl will first attempt to use v3 and then v2. | |||
To use OpenSSL to convert your favourite browser's certificate into a PEM | |||
formatted one that curl can use, do something like this (assuming netscape, | |||
but IE is likely to work similarly): | |||
You start with hitting the 'security' menu button in netscape. | |||
Select 'certificates->yours' and then pick a certificate in the list | |||
Press the 'export' button | |||
enter your PIN code for the certs | |||
select a proper place to save it | |||
Run the 'openssl' application to convert the certificate. If you cd to the | |||
openssl installation, you can do it like: | |||
# ./apps/openssl pkcs12 -in [file you saved] -clcerts -out [PEMfile] | |||
RESUMING FILE TRANSFERS | |||
To continue a file transfer where it was previously aborted, curl supports | |||
resume on http(s) downloads as well as ftp uploads and downloads. | |||
Continue downloading a document: | |||
curl -C - -o file ftp://ftp.server.com/path/file | |||
Continue uploading a document(*1): | |||
curl -C - -T file ftp://ftp.server.com/path/file | |||
Continue downloading a document from a web server(*2): | |||
curl -C - -o file http://www.server.com/ | |||
(*1) = This requires that the ftp server supports the non-standard command | |||
SIZE. If it doesn't, curl will say so. | |||
(*2) = This requires that the web server supports at least HTTP/1.1. If it | |||
doesn't, curl will say so. | |||
TIME CONDITIONS | |||
HTTP allows a client to specify a time condition for the document it | |||
requests. It is If-Modified-Since or If-Unmodified-Since. Curl allow you to | |||
specify them with the -z/--time-cond flag. | |||
For example, you can easily make a download that only gets performed if the | |||
remote file is newer than a local copy. It would be made like: | |||
curl -z local.html http://remote.server.com/remote.html | |||
Or you can download a file only if the local file is newer than the remote | |||
one. Do this by prepending the date string with a '-', as in: | |||
curl -z -local.html http://remote.server.com/remote.html | |||
You can specify a "free text" date as condition. Tell curl to only download | |||
the file if it was updated since January 12, 2012: | |||
curl -z "Jan 12 2012" http://remote.server.com/remote.html | |||
Curl will then accept a wide range of date formats. You always make the date | |||
check the other way around by prepending it with a dash '-'. | |||
DICT | |||
For fun try | |||
curl dict://dict.org/m:curl | |||
curl dict://dict.org/d:heisenbug:jargon | |||
curl dict://dict.org/d:daniel:web1913 | |||
Aliases for 'm' are 'match' and 'find', and aliases for 'd' are 'define' | |||
and 'lookup'. For example, | |||
curl dict://dict.org/find:curl | |||
Commands that break the URL description of the RFC (but not the DICT | |||
protocol) are | |||
curl dict://dict.org/show:db | |||
curl dict://dict.org/show:strat | |||
Authentication is still missing (but this is not required by the RFC) | |||
LDAP | |||
If you have installed the OpenLDAP library, curl can take advantage of it | |||
and offer ldap:// support. | |||
LDAP is a complex thing and writing an LDAP query is not an easy task. I do | |||
advice you to dig up the syntax description for that elsewhere. Two places | |||
that might suit you are: | |||
Netscape's "Netscape Directory SDK 3.0 for C Programmer's Guide Chapter 10: | |||
Working with LDAP URLs": | |||
http://developer.netscape.com/docs/manuals/dirsdk/csdk30/url.htm | |||
RFC 2255, "The LDAP URL Format" http://curl.haxx.se/rfc/rfc2255.txt | |||
To show you an example, this is now I can get all people from my local LDAP | |||
server that has a certain sub-domain in their email address: | |||
curl -B "ldap://ldap.frontec.se/o=frontec??sub?mail=*sth.frontec.se" | |||
If I want the same info in HTML format, I can get it by not using the -B | |||
(enforce ASCII) flag. | |||
ENVIRONMENT VARIABLES | |||
Curl reads and understands the following environment variables: | |||
http_proxy, HTTPS_PROXY, FTP_PROXY | |||
They should be set for protocol-specific proxies. General proxy should be | |||
set with | |||
ALL_PROXY | |||
A comma-separated list of host names that shouldn't go through any proxy is | |||
set in (only an asterisk, '*' matches all hosts) | |||
NO_PROXY | |||
If a tail substring of the domain-path for a host matches one of these | |||
strings, transactions with that node will not be proxied. | |||
The usage of the -x/--proxy flag overrides the environment variables. | |||
NETRC | |||
Unix introduced the .netrc concept a long time ago. It is a way for a user | |||
to specify name and password for commonly visited ftp sites in a file so | |||
that you don't have to type them in each time you visit those sites. You | |||
realize this is a big security risk if someone else gets hold of your | |||
passwords, so therefore most unix programs won't read this file unless it is | |||
only readable by yourself (curl doesn't care though). | |||
Curl supports .netrc files if told so (using the -n/--netrc and | |||
--netrc-optional options). This is not restricted to only ftp, | |||
but curl can use it for all protocols where authentication is used. | |||
A very simple .netrc file could look something like: | |||
machine curl.haxx.se login iamdaniel password mysecret | |||
CUSTOM OUTPUT | |||
To better allow script programmers to get to know about the progress of | |||
curl, the -w/--write-out option was introduced. Using this, you can specify | |||
what information from the previous transfer you want to extract. | |||
To display the amount of bytes downloaded together with some text and an | |||
ending newline: | |||
curl -w 'We downloaded %{size_download} bytes\n' www.download.com | |||
KERBEROS FTP TRANSFER | |||
Curl supports kerberos4 and kerberos5/GSSAPI for FTP transfers. You need | |||
the kerberos package installed and used at curl build time for it to be | |||
used. | |||
First, get the krb-ticket the normal way, like with the kinit/kauth tool. | |||
Then use curl in way similar to: | |||
curl --krb private ftp://krb4site.com -u username:fakepwd | |||
There's no use for a password on the -u switch, but a blank one will make | |||
curl ask for one and you already entered the real password to kinit/kauth. | |||
TELNET | |||
The curl telnet support is basic and very easy to use. Curl passes all data | |||
passed to it on stdin to the remote server. Connect to a remote telnet | |||
server using a command line similar to: | |||
curl telnet://remote.server.com | |||
And enter the data to pass to the server on stdin. The result will be sent | |||
to stdout or to the file you specify with -o. | |||
You might want the -N/--no-buffer option to switch off the buffered output | |||
for slow connections or similar. | |||
Pass options to the telnet protocol negotiation, by using the -t option. To | |||
tell the server we use a vt100 terminal, try something like: | |||
curl -tTTYPE=vt100 telnet://remote.server.com | |||
Other interesting options for it -t include: | |||
- XDISPLOC=<X display> Sets the X display location. | |||
- NEW_ENV=<var,val> Sets an environment variable. | |||
NOTE: the telnet protocol does not specify any way to login with a specified | |||
user and password so curl can't do that automatically. To do that, you need | |||
to track when the login prompt is received and send the username and | |||
password accordingly. | |||
PERSISTENT CONNECTIONS | |||
Specifying multiple files on a single command line will make curl transfer | |||
all of them, one after the other in the specified order. | |||
libcurl will attempt to use persistent connections for the transfers so that | |||
the second transfer to the same host can use the same connection that was | |||
already initiated and was left open in the previous transfer. This greatly | |||
decreases connection time for all but the first transfer and it makes a far | |||
better use of the network. | |||
Note that curl cannot use persistent connections for transfers that are used | |||
in subsequence curl invokes. Try to stuff as many URLs as possible on the | |||
same command line if they are using the same host, as that'll make the | |||
transfers faster. If you use a http proxy for file transfers, practically | |||
all transfers will be persistent. | |||
MULTIPLE TRANSFERS WITH A SINGLE COMMAND LINE | |||
As is mentioned above, you can download multiple files with one command line | |||
by simply adding more URLs. If you want those to get saved to a local file | |||
instead of just printed to stdout, you need to add one save option for each | |||
URL you specify. Note that this also goes for the -O option (but not | |||
--remote-name-all). | |||
For example: get two files and use -O for the first and a custom file | |||
name for the second: | |||
curl -O http://url.com/file.txt ftp://ftp.com/moo.exe -o moo.jpg | |||
You can also upload multiple files in a similar fashion: | |||
curl -T local1 ftp://ftp.com/moo.exe -T local2 ftp://ftp.com/moo2.txt | |||
IPv6 | |||
curl will connect to a server with IPv6 when a host lookup returns an IPv6 | |||
address and fall back to IPv4 if the connection fails. The --ipv4 and --ipv6 | |||
options can specify which address to use when both are available. IPv6 | |||
addresses can also be specified directly in URLs using the syntax: | |||
http://[2001:1890:1112:1::20]/overview.html | |||
When this style is used, the -g option must be given to stop curl from | |||
interpreting the square brackets as special globbing characters. Link local | |||
and site local addresses including a scope identifier, such as fe80::1234%1, | |||
may also be used, but the scope portion must be numeric and the percent | |||
character must be URL escaped. The previous example in an SFTP URL might | |||
look like: | |||
sftp://[fe80::1234%251]/ | |||
IPv6 addresses provided other than in URLs (e.g. to the --proxy, --interface | |||
or --ftp-port options) should not be URL encoded. | |||
MAILING LISTS | |||
For your convenience, we have several open mailing lists to discuss curl, | |||
its development and things relevant to this. Get all info at | |||
http://curl.haxx.se/mail/. Some of the lists available are: | |||
curl-users | |||
Users of the command line tool. How to use it, what doesn't work, new | |||
features, related tools, questions, news, installations, compilations, | |||
running, porting etc. | |||
curl-library | |||
Developers using or developing libcurl. Bugs, extensions, improvements. | |||
curl-announce | |||
Low-traffic. Only receives announcements of new public versions. At worst, | |||
that makes something like one or two mails per month, but usually only one | |||
mail every second month. | |||
curl-and-php | |||
Using the curl functions in PHP. Everything curl with a PHP angle. Or PHP | |||
with a curl angle. | |||
curl-and-python | |||
Python hackers using curl with or without the python binding pycurl. | |||
Please direct curl questions, feature requests and trouble reports to one of | |||
these mailing lists instead of mailing any individual. |
@@ -0,0 +1,53 @@ | |||
_ _ ____ _ | |||
___| | | | _ \| | | |||
/ __| | | | |_) | | | |||
| (__| |_| | _ <| |___ | |||
\___|\___/|_| \_\_____| | |||
README | |||
Curl is a command line tool for transferring data specified with URL | |||
syntax. Find out how to use curl by reading the curl.1 man page or the | |||
MANUAL document. Find out how to install Curl by reading the INSTALL | |||
document. | |||
libcurl is the library curl is using to do its job. It is readily | |||
available to be used by your software. Read the libcurl.3 man page to | |||
learn how! | |||
You find answers to the most frequent questions we get in the FAQ document. | |||
Study the COPYING file for distribution terms and similar. If you distribute | |||
curl binaries or other binaries that involve libcurl, you might enjoy the | |||
LICENSE-MIXING document. | |||
CONTACT | |||
If you have problems, questions, ideas or suggestions, please contact us | |||
by posting to a suitable mailing list. See http://curl.haxx.se/mail/ | |||
All contributors to the project are listed in the THANKS document. | |||
WEB SITE | |||
Visit the curl web site for the latest news and downloads: | |||
http://curl.haxx.se/ | |||
CVS | |||
To download the very latest source off the CVS server do this: | |||
cvs -d :pserver:anonymous@cool.haxx.se:/cvsroot/curl login | |||
(just press enter when asked for password) | |||
cvs -d :pserver:anonymous@cool.haxx.se:/cvsroot/curl co curl | |||
(you'll get a directory named curl created, filled with the source code) | |||
NOTICE | |||
Curl contains pieces of source code that is Copyright (c) 1998, 1999 | |||
Kungliga Tekniska Högskolan. This notice is included here to comply with the | |||
distribution terms. |
@@ -0,0 +1,368 @@ | |||
SNF Command Line & SNFMulti Engine / Client Change Log | |||
------------------------------------------------------------------------------ | |||
20080626 - Version 3.0, It's official. | |||
Changed build information. | |||
20080524 - Version V2-9rc2.25.7 | |||
Optimized networking library for additional speed & stability by moving | |||
receive buffer allocation from heap to stack (automatic). | |||
Optimized timing parameters in SNFClient for improved speed. Polling dealys | |||
are now reduced to 10ms from 30ms. | |||
Removed speed-bug in SNFClient, 100ms guard time between retries was always | |||
executed after an attempt (even a successful attempt). The guard time is now | |||
condition and only fires on unsuccessful attempts. | |||
Updated XCI server logic to ensure non-blocking sockets for clients in all | |||
socket implementations. | |||
20080424 - Version V2-9rc2.24.6 | |||
Refactored snfScanData.clear() to reduce heap work and fragments. | |||
Added mutex to scanMessageFile() entry point just in case some app attempts to | |||
put multiple threads through a single engine handler. scanMessage() is already | |||
protected and fully wraped by the new scanMessageFile() mutex. | |||
Added non-specific runtime exception handling to XHDR injection code. | |||
Added 2 retries w/ 300ms delay to remove original message in XHDR inject code. | |||
If remove fails after 3 attempts the injector throws. | |||
Added 2 retries w/ 300ms delay to rename temp file to msg in XHDR inject code. | |||
If rename fails after 3 attempts the injector throws. | |||
20080416 - Version V2-9rc2.23.6 | |||
Fixed bug where SNCY open() would fail on some Win* platforms with | |||
WSAEINVAL instead of the standard EINPROGRESS or EALREADY which were expected. | |||
Also added WSAEWOULDBLOCK to cover other "ambiguities" in windows sockets | |||
implementations. InProgress() on Win* now test for any of: | |||
WSAEINPROGRESS, WSAEALREADY, WSAEWOULDBLOCK, WSAEINVAL | |||
20080413 - Version V2-9rc2.22.6 | |||
Fixed bug in TCPHost.open() where EALREADY was not counted as a version of | |||
EINPROGRESS. This would cause open() to throw an unnecessary exception when | |||
an open() required extra time. | |||
20080413 - Version V2-9rc2.21.6 | |||
Extended timeout for SYNC session open() to the full session length. This way | |||
if a session takes a long time to open it still has a shot at success. | |||
20080411 - Version V2-9rc2.20.6 | |||
Adjusted snfNETmgr to use non-blocking open in SYNC sessions. Open timeout | |||
is 1/3 of the session timeout. Session timeout is 2 * Session pacing. Open | |||
polling uses golden spiral delay from 10ms to 340ms. | |||
20080410 - Version V2-9rc2.19.6 | |||
Adjusted XCI manager to use new snfCFGPacket paradigm in checkCFG(). | |||
Adjusted snf_RulebaseHandler::addRulePanic() to use MyMutex and eliminated | |||
the AutoPanicMutex and waiting scheme. | |||
Refactored scanMessage() to use a ScopeMutex() rather than lock()/unlock(). | |||
Refactored scanMessage() to use MyCFGPacket.isRulePanic() test. | |||
Redesigned snfCFGPacket handling to automate grab() / drop() functions. | |||
Fixed lock-up bug: Redesigned AutoPanic posting and checking mechanisms to | |||
eliminate potential dead-lock condition. Under some conditions a precisely | |||
timed auto-panic posting could cause the RulebaseHandler mutex and the | |||
AutoPanicMutex to become intertwined leading to a cascading deadlock. When | |||
this occurred all XCI processing threads and eventually the XCI listener | |||
thread would become blocked waiting to get the current configuration. | |||
20080409 - Version V2-9rc2.18.6 | |||
Enhanced XCI exception handling and logging to provide additional detail. | |||
Added code to explicitely check for zero length files in scanMessagFile(). | |||
Previously a zero length file would cause the CBFR module of the filter | |||
chain to throw an invalid buffer exception. Now if the message file is empty | |||
scanMessageFile() will throw a FileError stating FileEmpty!. | |||
20080407 - Version V2-9rc2.17.6 | |||
Enhanced exception reporting in snfXCImrg | |||
20080405 - SNFServer V2-9rc2.16.6 | |||
Reduced safetly limits on status reports to 100K for status reports and 100K | |||
for samples. Previous values were 10M. Most full sessions from the busiest | |||
systems are < 50K total. | |||
Recoded sendDataTimeout() to break uploads into 512 byte chunks and insert | |||
delays only when a chunk is fragmented. This methodology improves reliability | |||
on Win* systems without any significant penalty on systems that don't need | |||
socket sends() to be in smaller chunks. | |||
Fixed TCPClient::transmit() and TCPHost::transmit() bug where returned byte | |||
count might be -1. Now returned byte counts can only be 0 or more. | |||
20080403 - SNFServer V2-9rc2.15.5 | |||
Minor modifications to networking module to better support non-blocking open() | |||
Updated SNFClient with new timing and non-blocking open(). Worst case return | |||
time from SNFClient estimated at 200 seconds (theoretically impossible). No- | |||
connection return time from SNFClient estimated at 20 seconds. | |||
20080326 - SNFServer V2-9rc2.15.4 | |||
Refactored snfNETmgr::sync() to consolidate non-blocking io routines. | |||
Added detailed thread status data to XCI listener thread. | |||
Fixed minor bug in main (not changing revision), Debug flag for internal use | |||
was left on in the last build cycle. It is commented out now. | |||
20080325 - SNFServer V2-9rc2.14.4 | |||
Updated snfNETmgr with comprehensive thread status data. | |||
Refactored snfNETmgr::sync() to check a Timeout, removed TCPWatchdog. | |||
20080325 - SNFServer V2-9rc2.13.4 | |||
Upgraded TCPWatcher code to use new threading features (type, status). | |||
20080324 - SNFServer v2-9rc2.12.4 | |||
Added a "Rulebase Getter" feature as part of the snf_Reloader. When enabled | |||
the Rulebase Getter will launch a user defineable system() call whenever a | |||
new rulebase file is available. The call will be repeated until the condition | |||
is cleared by a successful update of the rulebase file. The Rulebase Getter | |||
will wait a configurable "guard time" between attempts. The default system() | |||
call is "getRulebase" with a guard time of 3 minutes. In most cases this will | |||
launch the provided getRulebase script which should be present in the start | |||
location of SNFServer on most systems. Best practice is to configure the full | |||
path to the update script. The system() call is made in a separate thread so | |||
that if the system() call hangs for some reason only the Rulebase Getter is | |||
stuck. | |||
Built thread monitoring function for SNFServer.exe (Full status report / sec). | |||
The thread monitoring report is turned on when the program is renamed to | |||
SNFDebugServer.exe or if "debug" appears in the file path to the program. | |||
Refactored XCI channels to leverage new thread monitoring. | |||
Refactored Threading to eliminate inline code. | |||
Improved exception handling/reporting in scanMessageFile(). | |||
Updated scanMessagFile() header injection code to accommodate messages with | |||
no body. Previous version would throw an exception when it could not find an | |||
injection point. The new version makes the injection point byte 0 and puts | |||
the injected headers at the top of the message using it's best guess about the | |||
type of line endings (CRLF or LF) to use. | |||
Updated Threading library to include high level thread state tracking and | |||
naming. Also creates a global Threads object that can produce a real-time | |||
status report on all threads. | |||
Updated Networking library to use SO_REUSEADDR by default on listeners. | |||
20080318 - SNF2-9rc1.11.exe Consolidated several mods/fixes | |||
Corrected scan error logging bug. Was posting <s/> now posts <e/>. | |||
Updated scan error logging to be more uniform with non-scan errors. | |||
Developed various script prototypes for postfix integration & automated | |||
updates on win* systems using the new UpdateReady.txt file mechanism. | |||
Fixed a bug in scanMessageFile() where an \n\n style insertion point | |||
would never be detected. | |||
Modified scanMessageFile() header injection to strip <CR> from line ends | |||
when the message file provided does not use them. The line-end style of | |||
the message file is detected while locating the insertion point. If the | |||
insertion point (first blank line) does not use <CR><LF> then the SNF | |||
generated X-Headers are stripped of <CR> in a tight loop before injection. | |||
Enhanced error and exception reporting in SNFMulti.cpp scanMessageFile(). | |||
Enhanced exception handling in networking module. All exceptions now | |||
throw descriptive runtime_error exceptions. | |||
20080306 - SNF2-9rc1.8.exe (FIRST RELEASE CANDIDATE for VERSION 3!) | |||
Added Drilldown Header Directive Functions - When the candidate source IP | |||
comes from a header matching a drilldown directive the IP is marked "Ignore" | |||
in GBUdb and the candidate is no longer eligible to be the source for that | |||
message. This allows SNF to follow the trusted chain of devices (by IP) down | |||
to the actual source of the message. It is handy for ignoring net blocks | |||
because it can match partial IPs but it is designed to allow SNF to learn | |||
it's way through the servers at large ISPs so that the original source for | |||
each message can be evaluated directly. | |||
Added Source Header Directive Functions - This feature allows SNF to acquire | |||
the source IP for a message from a specific header rather than searching | |||
through the Received headers in the message. This is useful when the original | |||
source for a message is not represented in Received headers. For example: | |||
Hotmail places the originating source IP in a special header and does not | |||
provide a Received header for that IP. This feature is protected from abuse | |||
by a "Context" feature which only activates the source header directive when | |||
specific content is found in a specific received header. Using the above | |||
example, this feature can be configured so that a Hotmail source header would | |||
only be read if the top Recieved header contained "hotmail.com [" indicating | |||
that the ptr lookup for the header matched the hotmail domain. Note: When a | |||
source is pulled from a header directive that source is put into a synthetic | |||
Received header and injected into the scanning stream (not the message) as | |||
the first Received header. | |||
Added forced source IP to XCI - It is now possible to "inject" or "force" | |||
the source IP for any message by providing that IP in the XCI request or | |||
directly in a scan...() function call. This allows the calling application | |||
to provide the source IP for a message ahead of any Received headers that | |||
might be in the message. This is useful when the calling application knows | |||
the original source IP for the message but that IP is not represented in | |||
the Received headers and it is not desireable to use the Source Header | |||
Directive mechanism. | |||
Added forced source IP mode to SNFClient - It is now possible to call the | |||
SNFClient utility with an IP4Address using the syntax: | |||
SNFClient -source=12.34.56.78 | |||
The -source mode of SNFClient exercises the forced source IP feature in | |||
the XCI (see above) | |||
Added Status Report features to SNFClient and XCI - It is now possible to | |||
request the latest status.second, status.minute, or status.hour data via | |||
the XCI and SNFClient. The syntax for requesting a status report using the | |||
SNFClient is: | |||
SNFClient -status.second | |||
SNFClient -status.minute | |||
SNFClient -status.hour | |||
In addition to providing status reports the SNFClient in this mode will | |||
return a nonzero value (usually 99) if it is unable to get a status report | |||
from SNFServer. This feature can be used to verify that SNFServer is up | |||
and responding. If SNFServer is OK then the result code returned is 0. | |||
Added result codes to SNFClient -test and XCI IP test functions - The XCI | |||
engine has been upgraded to provide the range value for the IP under test | |||
as well as the symbolic result code associated with that range. This allows | |||
the -test function to provide results that are consistent with the GBUdb | |||
configuration without additional processing: For example, if the IP falls | |||
in the Caution range then the Caution result code will be returned just | |||
as if a message had been scanned with the same IP and no pattern match | |||
occurred. The same is true for Truncate and Black range hits. | |||
Added Timestamp and Command Line Parameter data to SNFClient.exe.err - When | |||
an error occurs with SNFClient that may not appear in the SNFServer logs an | |||
entry is appended to the SNFClient.exe.err file. That in itself is not new. | |||
The new feature is that the entries added to the SNFClient.exe.err file now | |||
include timestamp and command line data to aid in debugging. | |||
Added BIG-ENDIAN Conversion - When the SNFServer program is compiled on a | |||
system that uses a BIG-ENDIAN processor (such as a power-mac) the rulebase | |||
load process now includes a routine to convert the token matrix from it's | |||
native LITTLE-ENDIAN format to a BIG-ENDIAN format. This solves a bug where | |||
Power-Mac (and presumably other BIG-ENDIAN systems) could compile and run | |||
the SNF* software but were unable to capture spam because the token matrix | |||
in the rulebase file was misinterpreted. | |||
Note: The BIG-ENDIAN Conversion feature is still considered experimental | |||
because it has not yet been thoroughly tested. | |||
Updated the Configuration Log to include all of the current configuration | |||
features and to improve it's readability. | |||
20080207 - SNF2-9b1.7.exe | |||
SYNC Timeout now 2x SYNC Schedule | |||
SNFServer now produces an UpdateReady.txt file when the UTC timestamp on | |||
the SYNC server is newer than the UTC timestamp of the active rulebase. It | |||
is presumed that a suitable update script or program will run periodically | |||
and download a fresh rulebase file if the UpdateReady.txt file is present. | |||
The update script should remove the UpdateReady.txt file when it completes | |||
a successful download of the new rulebase file. | |||
Added available rulebase UTC in status reports <udate utc.../> | |||
Added Automatic path fixup for ending / or \ | |||
Added option to use local time in log rotation <rotation localtime='no'/> | |||
The default is still utc. | |||
20071102 - SNF2-9b1.6.exe | |||
Increased MAX_EVALS from 1024 to 2048. | |||
Adjusted defult range envelopes in snf_engine.xml to be more conservative. | |||
20071017 - SNF2-9b1.5.exe | |||
Added a missing #include directive to the networking.hpp file. The | |||
missing #include was not a factor on Linux and Windows systems but | |||
caused compiler errors on BSD systems. | |||
Corrected a bug in the GBUdb White Range code where any message with a | |||
white range source IP was being forced to the white result code. The | |||
engine now (correctly) only forces the result and records the event when | |||
a black pattern rule was matched and the White Range IP causes that | |||
scan result to be overturned. If the scan result was not a black pattern | |||
match then the original scan result is allowed to pass through. | |||
Corrected a bug in the Header Analysis filter chain module that would | |||
cause the first header in the message to be ignored in some cases. | |||
Corrected an XML log format problem so that <s/> elements are correctly | |||
open ended <s ....> or closed (empty) <s..../> according to whether they | |||
have subordinate elements. | |||
Adjusted the GBUdb header info format. The order of the Confidence | |||
figure and Probabilty figure is now the same as in the XML log files | |||
(C then P). The confidence and probability figures are now preceeded | |||
with c= and p= respectively so that it's easy to tell which is which. | |||
20071009 - SNF2-9b1.4.exe | |||
Tightened up the XCI handler code and removed the watchdog. The watchdog | |||
would restart the listener if there were no connections in 5 minutes. It | |||
was originally added to provide additional stability, however in practice | |||
there have been no "stalled listeners". Also, a stalled listener would | |||
likely be a sign of a different problem that the watchdog would tend to | |||
hide. | |||
Modified and refactored the XCI configuration management code. All XCI config | |||
changes and up-down operations are now handled in a single function except | |||
upon exit from the main XCI thread where XCI_shutdown() is always called. | |||
Added some more detailed exception handling code to the XCI component so that | |||
more data will be logged in the event of an error. | |||
20071008 - SNF2-9b1.2.exe | |||
Added support for passing Communigate Message Files directly. Communigate adds | |||
data to the top of the message file. That data stops at the first blank line and | |||
the rfc822 message begins. The SNFServer engine can now be told to ignore this | |||
extra data using the following option: | |||
<msg-file type='cgp'/> <!-- type='cgp' for communigate message files --> | |||
If the msg-file type is anything other than 'cgp' then it will treat the message | |||
file as a standard rfc822 message in the usual way. The default setting is | |||
<msg-file type='rfc822'/> | |||
@@ -0,0 +1,9 @@ | |||
# List of IPs to Ignore on startup | |||
# Each IP in this list is set to Ignore in GBUdb when | |||
# The configuration is loaded. | |||
# Hash mark on the beginning of a line indicates a comment. | |||
# Comments after an IP are also ignored. | |||
# One line per IP. Sorry, no CIDR yet. | |||
# Be sure to list ALL of your gateways :-) | |||
127.0.0.1 # ignore localhost, of course. |
@@ -0,0 +1,39 @@ | |||
<FILTER> | |||
<ACTIVE>1</ACTIVE> | |||
<TITLE>SNIFFER</TITLE> | |||
<READONLY>0</READONLY> | |||
<CONDITION> | |||
<AND>1</AND> | |||
<LOGICALNOT>0</LOGICALNOT> | |||
<EXPRESSION>6</EXPRESSION> | |||
<CONTAINTYPE>8</CONTAINTYPE> | |||
<MESSAGESIZESMALLER>0</MESSAGESIZESMALLER> | |||
<MESSAGESIZE>1</MESSAGESIZE> | |||
</CONDITION> | |||
<CONDITION> | |||
<AND>1</AND> | |||
<LOGICALNOT>0</LOGICALNOT> | |||
<EXPRESSION>4</EXPRESSION> | |||
<CONTAINTYPE>8</CONTAINTYPE> | |||
<CONTAIN>C:\Alligate\SNF\SNFClient.exe</CONTAIN> | |||
<MESSAGESIZESMALLER>0</MESSAGESIZESMALLER> | |||
<MESSAGESIZE>2</MESSAGESIZE> | |||
</CONDITION> | |||
<ACCEPT>0</ACCEPT> | |||
<REJECT>0</REJECT> | |||
<DELETE>0</DELETE> | |||
<ENCRYPT>0</ENCRYPT> | |||
<PRIORITY>0</PRIORITY> | |||
<FLAGS>0</FLAGS> | |||
<SCORE>500</SCORE> | |||
<MARKSPAM>0</MARKSPAM> | |||
<STOP>0</STOP> | |||
<EXECUTE>0</EXECUTE> | |||
<FORWARD>spam@appriver.com</FORWARD> | |||
<TARPITSENDER>1</TARPITSENDER> | |||
<STRIPALL>0</STRIPALL> | |||
<MOVETOFOLDER>~spam</MOVETOFOLDER> | |||
<HEADER> | |||
<VAL>0X-SNIFFER-FLAG: Yes</VAL> | |||
</HEADER> | |||
</FILTER> |
@@ -0,0 +1 @@ | |||
For an up to date description of the install instructions please visit: www.armresearch.com |
@@ -0,0 +1,146 @@ | |||
MDaemon Plugin V2.9rc* (V3) installation instructions | |||
------------------------------------------------------------------------------ | |||
1. Locate your \MDaemon directory (Usually c:\MDaemon) | |||
2. Create the directory \MDaemon\SNF | |||
3. Copy the distribution files to \MDaemon\SNF | |||
4. Edit identity.xml in notepad. | |||
4.1. Replace licensid with your SNF license ID. | |||
4.2. Replace authenticationxx with your SNF authentication code. | |||
5. Adjust/Create your Plugins.dat file (\MDaemon\App\Plugins.dat) | |||
5.1. If you already have a Plugins.dat file | |||
5.1.1. Copy the contents of the Plugins.dat file in the distribution | |||
to the Plugins.dat file you have. | |||
5.1.2. If you have a [Message Sniffer] section in your Plugins.dat | |||
file then make a copy of it (for backup) then remove that | |||
section. (This will disable your previous Message Sniffer | |||
installation) | |||
5.2. If you do not already have a Plugins.dat file | |||
5.2.1. Copy the Plugins.dat file from the distribution to your | |||
\MDaemon\App directory. | |||
6. Copy the snf-groups.cf into \MDaemon\SpamAssassin\rules | |||
7. Download your SNF rulebase file and place it in your SNF directory. | |||
7.1. Once you've signed up for a 30 Day free Trial or purchased a license for | |||
SNF you will receive update notifications via email. These notifications | |||
contain instructions on how to download your rulebase file. You can get | |||
your 30 Day Free Trial started by visiting www.armresearch.com. | |||
7.2. We have included an update script and utilities that you can use to | |||
automate updates to your rulebase file. The SNFServer engine that runs | |||
inside the plugin will produce an UpdateReady.txt file any time the local | |||
rulbase file is older than the latest available update. The included | |||
getRulebase.cmd script checks for this file and uses the open source | |||
wget and gzip utilities to download, validate, and replace your rulebase | |||
file automatically. | |||
7.2.1. Edit the top of the getRulebase.cmd file to establish the correct | |||
working directory, authentication string, and license ID for your | |||
rulebase files. | |||
7.2.2. Verify that the <update-script/> section of your snfmdplugin.xml file | |||
points to the correct location of the getRulebase.cmd script. This new | |||
feature will automatically run the getRulebase.cmd script whenever a | |||
newer rulebase file is available on our servers. | |||
8. Edit the GBUdbIgnoreList.txt file in notepad. | |||
8.1 Add the IP of any gateways you have as well as any systems you | |||
have that send mail through your mail server. | |||
8.2 It is very important to populate your GBUdbIgnoreList if you have | |||
gateways ahead of your mail server or else GBUdb will learn that | |||
those systems are responsible for sending spam! The GBUdb engine | |||
uses the ignore list to determine the actual source IP of the message. | |||
The first IP it sees in the headers that is not on the ignore list | |||
is determined to be the source IP for the message. Since most email | |||
"in the wild" these days are spam, any gateways that are not listed | |||
will be seen to be sending mostly spam - in error, of course. | |||
8.3 You cannot enter network blocks in the GBUdbIgnoreList.txt file. If | |||
you wish to ignore (mark as infrastructure) blocks of IPs then you should | |||
use the <drilldown/> section of the snfmdplugin.xml file to enter | |||
patterns that match the network blocks you want to ignore. For example, | |||
if you want to ignore servers in the 12.34.56.0/24 network block then | |||
you would enter a drilldown rule like: | |||
<drilldown> | |||
... | |||
<received ordinal='0' find='[12.34.56.'/> | |||
The rule tells GBUdb to learn to ignore any IP in the top (ordinal 0) | |||
received header if that header contains the string '[12.34.56.'. Of | |||
course that string will match every IP in the 12.34.56.0/24 class C | |||
block so any servers in that block which deliver mail to the SNF equiped | |||
server will be learned as infrastructure (ignore flag set). | |||
9. Review and adjust your snfmdplugin.xml file | |||
9.1. Check the paths at the top of the file and make sure they are complete and | |||
correct. In most cases the defaults will work, but if you've installed | |||
MDaemon & SNF on a different drive or in a different directory it would | |||
be best to update these paths: | |||
9.1.1. Find/Check <snf><node identity.../> | |||
9.1.2. Find/Check <snf><node><paths><log path.../> | |||
9.1.3. Find/Check <snf><node><paths><rulebase path.../> | |||
9.1.4. Find/Check <snf><node><paths><workspace path.../> | |||
9.2. If you have any addresses where people legitimately send spam such as an | |||
abuse reporting address or support address then you should enter that | |||
address into the <snf><node><gbudb><training><bypass/> section of the | |||
snfmdplugin.xml file. For example an abuse reporting address might look | |||
like this: | |||
<bypass> | |||
... | |||
<header name='To:' find='spam@example.com'/> | |||
The rule tells GBUdb to bypass it's training mechanism if it finds a | |||
'To:' header in a message that contains 'spam@example.com'. This should | |||
prevent customer's IPs from being learned as spam sources when they send | |||
messages to spam@example.com. | |||
9.3. Your system practices and policies may require additional rules in order | |||
to get the best performance from the GBUdb system. For more information | |||
please check out www.armresearch.com, support@armresearch.com, and our | |||
community list sniffer@sortmonster.com. | |||
10. Restart MDaemon. | |||
11. Verify the SNF plugin is installed | |||
11.1. In the plug-ins log tab you should see: | |||
Attempting to load 'SNF' plugin | |||
* ConfigFunc: ConfigFunc@4 (Ok, ready to use) | |||
* StartupFunc: Startup@4 (Ok, ready to use) | |||
* ShutdownFunc: Shutdown@4 (Ok, ready to use) | |||
* PreMessageFunc: (NULL) | |||
* PostMessageFunc: MessageFunc@8 (Ok, ready to use) | |||
* SMTPMessageFunc: MessageIPFunc@8 (Ok, ready to use) | |||
* SMTPMessageFunc2: (NULL) | |||
* SMTPMessageFunc3: (NULL) | |||
* DomainPOPMessageFunc: (NULL) | |||
* MultiPOPMessageFunc: (NULL) | |||
* Result: success (plugin DLL loaded in slot 0) | |||
---------- | |||
SNF plugin is starting up | |||
SNFMulti Engine Version 2.9rc11 Build: Mar 20 2008 15:18:30 | |||
SNF MDaemon Plugin Version 2-9rc4 Build: Mar 20 2008 15:17:20 | |||
SNF Config: C:\MDaemon\SNF\SNFMDPlugin.xml | |||
---------- | |||
Note that the slot may be different if you have other plugins. | |||
11.2. When your system processes a message you should see something like: | |||
SNF MessageScan: c:\mdaemon\queues\local\md50000000039.msg, Result=0 | |||
If you have a valid AntiVirus for MDaemon license you should also see | |||
a line similar to this: | |||
SNF IPScan: C:\MDaemon\Queues\Inbound\md50000000029.msg, 192.168.0.102, {Ugly, p=-1, c=0.303425, Normal} Allowed. | |||
11.3. In your messages you should see some new headers similar to: | |||
X-MessageSniffer-GBUdb-Result: 0, 192.168.0.102, Ugly -1 0.303425 Source Normal | |||
X-MessageSniffer-Scan-Result: 0 | |||
X-MessageSniffer-Patterns: | |||
0-0-0-998-c |
@@ -0,0 +1,56 @@ | |||
License & Terms of Service | |||
AS A SUBSCRIBER TO THE MESSAGE SNIFFER SERVICE YOU AGREE TO THE FOLLOWING TERMS AND CONDITIONS. | |||
ARM RESEARCH LABS MAY ALTER THESE TERMS AND CONDITIONS AT ANY TIME AND ANY SUCH CHANGES WILL BE REFLECTED HERE. WE RESERVE THE RIGHT TO DECIDE WHICH PATTERNS WILL OR WILL NOT BE CODED INTO OUR RULE BASE AND HOW THESE RULES WILL BE CLASSIFIED. WE WILL MAKE OUR BEST EFFORT TO ACCOMMODATE REASONABLE REQUESTS BASED ON THE SUM OF OUR SUBSCRIBERS COMMENTS, NON-SUBSCRIBER COMMENTS, OUR OWN RESEARCH, AND OUR OWN JUDGMENT. | |||
OUR SYSTEM IS INTENDED FOR THE SOLE USE OF OUR SUBSCRIBER BASE AND IS DEVELOPED AND MAINTAINED EXCLUSIVELY FOR THAT PURPOSE. THIS SYSTEM IS NOT INTENDED AS A GENERAL EMAIL OR CONTENT RATING SYSTEM NOR AS ANY PUBLIC SERVICE NOR AS A PUBLIC UTILITY AND THEREFORE SHOULD NOT BE EVALUATED NOR INTERPRETED IN ANY OF THESE CONTEXTS. | |||
WE DO NOT FILTER EMAIL CONTENT. RATHER, WE PROVIDE A MECHANISM FOR IDENTIFYING THIS CONTENT SO THAT IT MIGHT BE FILTERED ACCORDING TO THE SPECIFIC NEEDS OF OUR SUBSCRIBER BASE. THE DECISION TO FILTER OR OTHERWISE TREAT ANY EMAIL CONTENT BASED ON OUR SERVICE IS STRICTLY THAT OF THE SUBSCRIBER. | |||
THE MESSAGE SNIFFER SOFTWARE AND SERVICE IS PROVIDED AS-IS. YOU, THE SUBSCRIBER, ASSUME ALL RISKS AND AGREE TO INDEMNIFY AND HOLD ARM RESEARCH LABS HARMLESS FOR ANY DAMAGES. YOUR SOLE REMEDY IF YOU ARE DISSATISFIED FOR ANY REASON IS TO DISCONTINUE USE OF THE PRODUCT AND RECEIVE A REFUND FOR THE REMAINDER OF YOUR CURRENT SUBSCRIPTION. | |||
Message Sniffer Software License and Limited Warranty... | |||
THIS LICENSE AGREEMENT ("LICENSE") IS AN AGREEMENT BETWEEN YOU AND ARM RESEARCH LABS ("ARM"). ARM IS WILLING TO LICENSE THE ENCLOSED SOFTWARE TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE. PLEASE READ THIS LICENSE CAREFULLY BEFORE USING THE SOFTWARE, AS BY USING THE SOFTWARE YOU INDICATE THAT YOU AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE, ARM IS UNWILLING TO LICENSE THE SOFTWARE TO YOU AND YOU SHOULD PROMPTLY RETURN THE UNUSED SOFTWARE TO THE PLACE WHERE YOU OBTAINED IT AND YOUR MONEY WILL BE REFUNDED. | |||
1. Grant of License. The application, demonstration, system and all other software, data files and related documentation accompanying this License, whether on CD-ROM, delivered electronically, or on any other media (the "Software") are licensed to you by ARM according to the terms of this License. This license allows you to use the Software on a single computer. You may also make one additional copy of the Software in the form in which it is provided to you for backup purposes. In addition, you may print portions of the documentation for your own reference provided you do not disclose any portion of the software or documentation to any third party. You must reproduce, on all copies you make of the Software, the ARM copyright notice and any other proprietary legends that are on the original copy of the Software. | |||
2. Restrictions. The Software contains copyrighted material, trade secrets, and other proprietary material of ARM and it's licensors. You agree that in order to protect those proprietary materials, except as expressly permitted by applicable legislation, you will not decompile, reverse engineer, disassemble or otherwise reduce all or any part of the Software to human-readable form unless ARM provided it to you in human-readable form. You may not modify, rent, lease, loan, distribute or create derivative works based upon the Software in whole or in part for any purpose. | |||
3. Ownership. The Software and documentation are licensed, not sold, to you for use only under the terms of this License, and ARM reserves all rights not expressly granted to you in this License. You own the media (if any) on which the Software and documentation are recorded but ARM and/or ARM's licensors retain title to the Software and related documentation, and all intellectual property rights therein. | |||
4. Termination. This License is effective until terminated. You may terminate this License at any time by destroying all copies of the Software and related documentation in your possession or control. This License will be terminated immediately by ARM if you fail to comply with any provision of this License. Upon termination you must destroy all copies of the Software and related documentation in your possession or control. | |||
5. Limited Warranty on Media (If applicable). ARM warrants the media on which the Software is recorded to be free from defects in materials and workmanship under normal use for a period of ninety (90) days from the date of purchase as evidenced by a copy of the receipt. ARM's entire liability and your exclusive remedy will be the replacement of the media not meeting ARM's limited warranty returned to ARM with a copy of the receipt. ARM will have no responsibility to replace any media damaged by accident, abuse or misapplication. | |||
ANY IMPLIED WARRANTIES ON THE MEDIA, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF DELIVERY. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY BY JURISDICTION. | |||
6. Limited Warranty on Software. THE SOFTWARE IS WARRANTED TO PERFORM SUBSTANTIALLY AS DESCRIBED IN THE DOCUMENTATION WHEN IT IS USED ACCORDING TO THE GUIDELINES SET FORTH THEREIN AND FOR THE PURPOSE IT WAS INTENDED. YOU ACKNOWLEDGE AND AGREE THAT THE SOFTWARE MAY CONTAIN ERRORS AND THAT USE OF THE SOFTWARE AND RELATED DOCUMENTATION IS AT YOUR SOLE RISK. SHOULD THE SOFTWARE OR RELATED DOCUMENTATION PROVE DEFECTIVE, YOU (AND NOT ARM OR ANY ARM REPRESENTATIVE) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IF THE SOFTWARE FAILS TO PERFORM SUBSTANTIALLY AS DESCRIBED IN THE DOCUMENTATION, AND ARM IS UNABLE OR UNWILLING TO CORRECT THE SOFTWARE AFTER A REASONABLE EFFORT, YOUR SOLE REMEDY WILL BE TO RETURN THE SOFTWARE TO ARM FOR A REFUND. ARM EXPRESSLY DISCLAIMS ALL OTHER WARRANTIES WITH RESPECT TO THE SOFTWARE AND RELATED DOCUMENTATION, WHETHER SUCH WARRANTIES ARE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. YOU ACKNOWLEDGE AND AGREE THAT THE SOFTWARE HAS NOT BEEN DESIGNED, TESTED, OR MANUFACTURED FOR USE IN APPLICATIONS WHERE THE FAILURE, MALFUNCTION, OR ANY INACCURACY OF THE APPLICATION CARRIES A RISK OF DEATH, SERIOUS BODILY INJURY, OR DAMAGE TO TANGIBLE PROPERTY, INCLUDING, BUT NOT LIMITED TO, USE IN FACTORY CONTROL SYSTEMS, MEDICAL DEVICES OR FACILITIES, NUCLEAR FACILITIES, AIRCRAFT OR AUTOMOBILE NAVIGATION OR COMMUNICATION, EMERGENCY SYSTEMS, OR OTHER APPLICATIONS WITH A SIMILAR DEGREE OF POTENTIAL HAZARD. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY ARM OR ANY OF ITS EMPLOYEES, REPRESENTATIVES, OR RESELLERS SHALL CREATE ANY WARRANTY IN ADDITION TO THOSE GIVEN HEREIN. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. | |||
7. Limitation of Liability. UNDER NO CIRCUMSTANCES SHALL ARM BE LIABLE FOR ANY INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES THAT RESULT FROM THE USE OR INABILITY TO USE THE SOFTWARE OR RELATED DOCUMENTATION UNDER ANY THEORY, INCLUDING CONTRACT, TORT, OR NEGLIGENCE, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT SHALL ARM'S TOTAL LIABILITY TO YOU FOR ALL DAMAGES, LOSSES, AND CAUSES OF ACTION (WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR OTHERWISE) EXCEED THE AMOUNT PAID BY YOU FOR THE SPECIFIC LICENSE OF THE SOFTWARE AND RELATED DOCUMENTATION TO WHICH THE LIABILITY IS RELATED. | |||
8. Controlling Law and Severability. THIS LICENSE SHALL BE GOVERNED BY AND CONSTRUED IN ACCORDANCE WITH THE LAWS OF THE UNITED STATES AND THE STATE OF VIRGINIA, EXCEPT FOR ITS CONFLICT OF LAWS PRINCIPLES. If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License shall be enforced to the maximum extent permissible so as to effect the intent of the parties, and the remainder of this License shall continue in full force and effect. | |||
9. Complete Agreement. This License constitutes the entire agreement between the parties with respect to the use of the Software and related documentation and supersedes all prior or contemporaneous understandings or agreements, written or oral, regarding such subject matter. No amendment to or modification of this License will be binding unless in writing and signed by an authorized officer of ARM. | |||
Copyright 2005-2006 Arm Research Labs, LLC | |||
Copyright 2002-2004 MicroNeil Research Corporation / Sortmonster | |||
Use of the Message Sniffer rulebase is covered by the License & TOS | |||
as published on our web site: | |||
http://www.armresearch.com/message-sniffer/license-TOS.asp | |||
Reseller, and OEM licensing is also available. | |||
For info please visit this page: | |||
http://kb.armresearch.com/index.php?title=Message_Sniffer.Resellers | |||
For up to date information about Message Sniffer visit: | |||
http://www.armresearch.com/message-sniffer/ | |||
support@sortmonster.com |
@@ -0,0 +1,106 @@ | |||
MINIMI ( Minimal IMail Insert for SNF) | |||
This program makes it possible to scan messages on IMail using | |||
SNF_Server without the need for additional software. | |||
The SNFIMailShim.exe program is called in place of the normal IMail | |||
delivery agent (smtp32.exe). SNFIMailShim.exe locks the message in | |||
the IMail/spool and then contacts the SNF_Server for scanning. When | |||
the scan is completed SNFIMailShim.exe takes some appropriate action | |||
on the message based on it's configuration. If the message is to be | |||
delivered then SNFIMailShim.exe will unlock the message and call the | |||
original delivery agent (smtp32.exe). | |||
Depending upon the result code from SNF_Server, MINIMI can take one | |||
of the following actions: | |||
pass - Allow the message to be delivered normally* | |||
hold - Move the D and Q file for the message to a folder. | |||
drop - Delete the D and Q file and NOT call smtp32.exe. | |||
* Messages may be altered by SNF_Server before delivery. Most commonly | |||
SNF_Server might inject headers indicating data about the scan. IMail | |||
rules can then be used to react to these headers. | |||
____________ | |||
Installation | |||
Copy the SNFIMailShim.exe and SNFIMailShim.xml files to the IMail | |||
directory -- the same directory where smtp32.exe is found. | |||
Adjust the contents of SNFIMailShim.xml according to your needs. | |||
Especially make sure that the following elements are correct for your | |||
system: | |||
<delivery program='d:\IMail\smtp32.exe'/> | |||
The <delivery/> element describes the program that will be called by | |||
MINIMI to deliver messages. This is normally IMail's smtp32.exe. | |||
<hold path='d:\IMail\spool\spam\'/> | |||
The <hold/> element describes the full path to the directory where | |||
held messages will be moved by default. Be sure to include the \ at | |||
the end - this "path" is prepended to the Q and D file before it is | |||
written to disc. | |||
Note: You can set the mode (pass, hold, drop) for each result code | |||
that may come from SNF_Server. The result code generally represents | |||
the rule group that matched the message -- roughly analogous to the | |||
"type of spam". A zero result [generally] indicates that no patterns | |||
matched the message. | |||
IMPORTANT: Be sure that any paths you reference in the configuration | |||
exist on the system before proceeding. | |||
Final Step: Assuming you already have SNF_Server running you can now | |||
update IMail to use SNFIMailShim.exe for delivery. | |||
*IMail Administrator | |||
localhost | |||
Services | |||
SMTP | |||
Advanced | |||
Delivery Application | |||
IMPORTANT: Be sure to enter the full path to SNFIMailShim.exe | |||
Apply, Stop SMTP, Start SMTP | |||
SNF_Server will produce logs and status information indicating that | |||
messages are now being scanned. | |||
_______________ | |||
Operation Notes | |||
If MINIMI encounters problems it will create .err files in the spool. | |||
The .err files will be named for the message files and will contain | |||
information about the error. | |||
Normally you should not see .err files! If you don't see .err files | |||
and SNF_Server is showing messages being scanned then MINIMI is ok. | |||
When a message is locked, MIMINI makes a copy of the Q file named | |||
with a ~ in place of the Q and an extension of .lck. The original | |||
Q file is deleted (not renamed). The .lck file is created before the | |||
Q file is deleted for safety. | |||
If something goes wrong with MINIMI then you may find a .lck file. If | |||
you need to recover the original Q file, simply rename the .lck file | |||
to the original form. | |||
MINIMI is a lightweight utility - it is intended to do as little as | |||
possible, to do it quickly, with as few resources as possible, and | |||
to do it reliably. | |||
HOWEVER -- if you have a problem on a busy server then .lck and .err | |||
files may proliferate quickly! | |||
Have fun! | |||
_M | |||
madscientist@armresearch.com |
@@ -0,0 +1,41 @@ | |||
<AlligateMailShim> | |||
<delivery program='none'/> <!-- inert settings include '', none, None, NONE, and SNF4Alligate.exe --> | |||
<!-- any other setting will result in SNF4Alligate determining a result, but not taking an action. --> | |||
<!-- and handing off the file to the next problem in the chain defined by delivery program. --> | |||
<hold path='C:\Alligate\Hold\'/> | |||
<!-- This defines the default location to put messages marked for hold mode. --> | |||
<!-- This will be used if not expressly defined. --> | |||
<!-- The resulting actions include the following modes: --> | |||
<!-- nonzero modes: pass (0 - default), hold (1), drop (2) --> | |||
<!-- The nonzero tag defines the default response for nonzero results that are not expressly defined below. --> | |||
<nonzero mode='pass'/> | |||
<!-- For Alligate Gateway install, the default performance mode is to insert X_Headers and pass all messages. --> | |||
<result code='1' mode='pass' /> <!-- Custom White Rules --> | |||
<result code='20' mode='pass' /> <!-- Truncate--> | |||
<result code='40' mode='pass' /> <!-- Caution--> | |||
<result code='47' mode='pass' /> <!-- Travel --> | |||
<result code='48' mode='pass' /> <!-- Insurance --> | |||
<result code='49' mode='pass' /> <!-- AV-Push --> | |||
<result code='50' mode='pass' /> <!-- Media-Theft --> | |||
<result code='51' mode='pass' /> <!-- Spamware --> | |||
<result code='52' mode='pass' /> <!-- Snake-Oil --> | |||
<result code='53' mode='pass' /> <!-- Scam-Phishing --> | |||
<result code='54' mode='pass' /> <!-- Porn-Dating-Adult --> | |||
<result code='55' mode='pass' /> <!-- Malware --> | |||
<result code='56' mode='pass' /> <!-- Ink-Toner --> | |||
<result code='57' mode='pass' /> <!-- Get-Rich --> | |||
<result code='58' mode='pass' /> <!-- Debt-Credit --> | |||
<result code='59' mode='pass' /> <!-- Casinos-Gambling --> | |||
<result code='60' mode='pass' /> <!-- General --> | |||
<result code='61' mode='pass' /> <!-- Abstract --> | |||
<result code='62' mode='pass' /> <!-- Obfuscation --> | |||
<result code='63' mode='pass' /> <!-- Black --> | |||
<!-- This is a sample line that is defining a seperate location for its hold location: --> | |||
<!-- <result code='63' mode='pass' path='C:\Alligate\Hold_Black_Messages_Here\'/> --> <!-- Black --> | |||
</AlligateMailShim> |
@@ -0,0 +1,182 @@ | |||
SNFClient Readme | |||
Command line client for SNF. This utility formats and processes SNF_XCI | |||
requests through the SNF Engine working on the local machine. In general | |||
this utility can be used as a replacement for the earlier SNF command | |||
line scanner. It is also useful for other uses such as debugging and | |||
communicating with GBUdb. | |||
Note: Unlike prior versions of SNF, this command line utility does not | |||
need to be "branded" (renamed for the SNF license id). | |||
_________ | |||
Help Mode | |||
SNFClient.exe | |||
When called with no command line parameters the utility produces | |||
help and version information. | |||
__________ | |||
Debug Mode | |||
SNFDebugClient.exe | |||
When "debug" or "Debug" appears in the path to the program name | |||
or if the program's name is altered to include the word "debug" or | |||
"Debug" then the program will produce additional information about | |||
it's operation to aid in debugging problems. This includes the | |||
entire raw SNF_XCI request and response. | |||
__________________ | |||
Message Scan Modes | |||
These modes are used to scan email message files (the data part of | |||
smtp). This utility can be used as a drop-in replacement for previous | |||
verions of SNF (Message Sniffer) for scanning messages. However, this | |||
new version does not need to be "branded" (renamed for the license id) | |||
and will ignore the authentication string if it is provided. Also, | |||
since the newer version of SNF uses a client-server model and not a | |||
peer-server model, there is no need for a "persistent" mode. | |||
If "persistent" is passed to this utility on the command line as it | |||
would be used in prior versions of SNF then it will be treated like | |||
a file name and the scan will normally fail since a file named | |||
"persistent" is not likely to exist. | |||
SNFClient.exe <FileNameToScan> | |||
Scan Mode: Scans <FileNameToScan> and returns a result code. | |||
SNFClient.exe <authenticationxx> <FileNameToScan> | |||
Compatibility Mode: Ignores <authenticationxx> then scans the | |||
<FileNameToScan> and returns a result code. This mode provides | |||
drop-in compatibility with previous versions of SNF. | |||
SNFClient.exe -xhdr <FileNameToScan> | |||
XHeader Mode: Scans <FileNameToScan> and returns the result. Also | |||
outputs the contents of the X-Headers created by the SNF engine. If | |||
the SNF engine is configured to inject these headers then they will | |||
also have been injected into the <FileNameToScan>. | |||
The SNF Engine can be configured to provide the X-Headers only to | |||
the API without injecting them. In this case the XHeader Mode will | |||
display the X-Headers that would be injected, but they will not | |||
have been injected into the <FileNameToScan>. | |||
If the SNF Engine is configured not to produce X-Headers (none) then | |||
the XHeader Mode will not produce X-Headers because they will not | |||
have been generated by the engine. | |||
(note: -xhdr and -source options can be combined) | |||
SNFClient.exe -source=<IP4Address> <FileNameToScan> | |||
Source-IP Mode: Scans <FileNameToScan> and returns the result. The | |||
provided source IP is injected into the scan as the first Received | |||
header so that the scanning engine will presume the IP is the source | |||
of the message. This allows you to pre-define the source IP for the | |||
message when there is no other received header or when the received | |||
headers may be incorrect or may not present the actual source of | |||
the message. | |||
(note: -xhdr and -source options can be combined) | |||
_____________________________ | |||
SNFServer Status Report Modes | |||
SNFClient.exe -status.second | |||
SNFClient.exe -status.minute | |||
SNFClient.exe -status.hour | |||
This mode returns the latest posted status report as indicated. | |||
Normally these status reports are also posted to files in the | |||
SNFServer workspace. | |||
In this mode the SNFClient will return a result code (error level) | |||
of 0 when the request is successful and 99 (or some nonzero value) | |||
when the request is not successful. This allows the SNFClient to | |||
be used to verify that the SNFServer is running. | |||
Note: In most other modes the SNFClient returns a fail-safe 0 | |||
result code to avoid tagging messages as spam when there are errors. | |||
________________________ | |||
XCI Server Command Modes | |||
These features will expand as needed in later versions. | |||
SNFClient.exe -shutdown | |||
If the SNF Engine is running in an application that accepts SNF_XCI | |||
server commands then this mode will send that command. The shutdown | |||
command may have no effect if the application does not use the SNF_XCI | |||
server commnand interface or does not recognize the command. | |||
___________ | |||
GBUdb Modes | |||
These modes are used to communicate with the GBUdb system on the | |||
local node. It is possible to test (read out) an IP record or make | |||
any of a number of changes to IP data in the GBUdb. | |||
SNFClient.exe -test <IP4Address> | |||
Returns the current GBUdb statistics for the <IP4Address> | |||
SNFClient also returns a result code that matches the GBUdb range | |||
for the tested IP. These ranges are defined in the SNFServer | |||
configuration file. By default they are: | |||
20 - Truncate | |||
63 - Black | |||
40 - Caution | |||
0 - Normal | |||
SNFClient.exe -set <IP4Address> <flag> <bad> <good> | |||
Creates or updates the data for <IP4Address> as provided. The | |||
<IP4Address> must be provided as well as at least one of | |||
<flag>, <bad>, and <good>. If <flag>, <bad>, or <good> are | |||
to be left unchanged then they should be entered as a dash "-". | |||
Examples: | |||
Set all data for an IP. The flag will be "ugly", the bad count | |||
will be 0 and the good count will be 1000. | |||
SNFClient.exe -set 12.34.56.78 Ugly 0 1000 | |||
Set the flag to "ignore" and do not change the counts. | |||
SNFClient.exe -set 12.34.56.78 ignore - - | |||
Set the good count to 400 and do not change anything else. | |||
SNFClient.exe -set 12.34.56.78 - - 400 | |||
SNFClient.exe -good <IP4Address> | |||
Creates or updates statistics for the <IP4Address>. Increases the | |||
good count by one. (Record a good event) | |||
SNFClient.exe -bad <IP4Address> | |||
Creates or updates statistics for the <IP4Address>. Increases the | |||
bad count by one. (Record a bad event) | |||
SNFClient.exe -drop <IP4Address> | |||
Removes all local data for the <IP4Address>. Anything the local | |||
system "knows" about the IP is forgotten. Next time the IP is | |||
encountered it will be treated as new. | |||
____________________ | |||
For More Information | |||
See www.armresearch.com | |||
Copyright (C) 2007-2008 Arm Research Labs, LLC. | |||
@@ -0,0 +1,11 @@ | |||
<SNFIMailShim> | |||
<delivery program='d:\IMail\smtp32.exe'/> | |||
<hold path='d:\IMail\spool\spam\'/> | |||
<!-- nonzero modes: pass (0 - default), hold (1), drop (2) --> | |||
<nonzero mode='pass'/> | |||
<!-- | |||
<result code='1' mode='pass'/> | |||
<result code='20' mode='drop'/> | |||
<result code='40' mode='hold' path='d:\IMail\spool\caution\'/> | |||
--> | |||
</SNFIMailShim> |
@@ -0,0 +1,198 @@ | |||
SNF_Server V3.0 installation brief | |||
This is a generalized guide. For specific platform guides see: | |||
http://www.armresearch.com/support/articles/installation/index.jsp | |||
Create a directory for SNF_Server. ( c:\SNF or /var/spool/snfilter ) | |||
Copy all of the files to that directory. | |||
Make a copy of the SNFServer<version>.exe file and give it the name | |||
SNFServer.exe. Later on if newer versions are provided you will | |||
be able to keep track of them by name and swap newer versions into | |||
place by copying them over your SNFServer.exe file. If you decide | |||
you have to go back to a previous version then you will be able to | |||
do that easily by deleting your SNFServer.exe file and copying the | |||
version you wish to use into place. | |||
Modify the identity.xml file to match your SNF license ID and your | |||
authentication string. | |||
Download your .snf file and place that in the SNF_Server working | |||
directory. | |||
RULEBASE UPDATES (NEW!): The latest version of the SNFServer engine | |||
includes a mechanism that will run an a script when the rulebase file | |||
on our server is newer than the active file in SNF. By default this | |||
feature is configured to run the included getRulebase script. If | |||
the script is not successful it will be launched again every 3 minutes | |||
until the rulebase file is successfully updated. | |||
Be sure to modify the top of the getRulebase script to include | |||
your correct license ID, authentication string, and working directory. | |||
Be sure to verify that the <update-script/> section of your snf_engine | |||
file is correct (points to the correct location of getRulebase). | |||
getRulebase uses wget and gzip (included for your convenience in | |||
the Win* distribution. See About-Wget-and-Gzip.txt.). These are open | |||
source utilities for downloading files from web servers and unzipping | |||
those files -- in this case, SNF rulebase files. | |||
If you have any gateways or other internal systems that will relay | |||
mail to SNF then include their IPs in GBUdbIgnoreList.txt. The GBUdb | |||
component of SNF uses the IPs in this list to determine the actual | |||
source IP for a message by reviewing the Received headers. Each | |||
Received header is evaluated in turn. If the source (connect) IP is | |||
found in the Ignore list then that Received IP is considered to be | |||
part of your infrastructure and is ignored. The first Received IP | |||
found that is NOT in the Ignore list is selected as the source IP. | |||
The GBUdbIgnoreList is a "safety net" that ensures the listed IPs are | |||
present in your GBUdb with their Ignore flag set. It is loaded every | |||
time the configuration is changed, SNFServer is started, or a new | |||
rulebase is loaded. This way if your GBUdb database is lost then your | |||
critical infrastructure will be re-listed in the new .gbx file that | |||
is created. | |||
The ignore list allows only SINGLE IP ENTRIES. This can be a problem | |||
in some cases - such as when you want to ignore large blocks of network | |||
addresses. | |||
SNF can learn to Ignore large blocks of IPs using the <drilldown/> | |||
feature. For example if you want to ignore all of 12.34.56.0/24 then | |||
you can make an entry in the <drilldown/> training section like this: | |||
<training on-off='on'> | |||
... | |||
<drilldown> | |||
<received ordinal='0' find='[12.34.56.'/> | |||
</drilldown> | |||
... | |||
</training> | |||
GBUdb learns the behavior of source IPs so it is important that GBUdb | |||
knows any friendly sources that might send spammy messages to your | |||
server or else it will learn that those sources are not to be trusted. | |||
Since not all friendly spam sources can be identified by IP ahead of | |||
time, there are features in the <training/> section of snf_engine.xml | |||
that allow you to adjust the training scenarios to compensate. The | |||
most likely of these is that you may wish to bypass training for | |||
messages that are to your support addresses or spam submission | |||
addresses. For example: | |||
<training on-off='on'> | |||
... | |||
<bypass> | |||
<header name='To:' find='support@example.com'/> | |||
<header name='To:' find='spam@example.com'/> | |||
</bypass> | |||
... | |||
</training> | |||
Evaluate the snf_engine.xml file carefully. In most cases the | |||
default settings are appropriate, however you may want to alter | |||
some of the settings to match your system policies or particular | |||
installation. | |||
IMPORTANT: Be sure that any file paths / directories referenced in | |||
the configuration file exist on your system and that SNF has full | |||
access rights to these - especially the SNF working directory. | |||
** If you selected a working directory for SNF other than c:\SNF\ | |||
then be sure you have changed these paths in the top of your | |||
snf_engine.xml file. Pay close attentiont to these 5 elements: | |||
<node identity='c:/SNF/identity.xml'> | |||
<log path='c:/SNF/'/> | |||
<rulebase path='c:/SNF/'/> | |||
<workspace path='c:/SNF/'/> | |||
<update-script ... call='c:/SNF/getRulebase.cmd' ... /> | |||
Once you are happy with your configuration and you have all of your | |||
files and directories in place (including your .snf file) then you | |||
can start SNF_Server. | |||
The command line (from inside the SNF workspace) is: | |||
SNFServer.exe snf_engine.xml | |||
That is: SNFServer <configuration> | |||
If you want to lauch SNFServer from some other location it would be | |||
best to use the entire path for both the SNFServer engine and the | |||
configuration file: | |||
c:\SNF\SNFServer.exe c:\SNF\snf_engine.xml | |||
You should begin by testing SNFServer by running it in a command line | |||
window where you can watch it's output. | |||
Once you are happy with it then you will probably want to run it as | |||
a service using a utility such as the srvany utility from the win2k | |||
toolkit, or detached as a daemon on *nix systems (snfctrl file example | |||
included). | |||
This section of our site might be helpful: | |||
http://www.armresearch.com/support/articles/installation/serviceSetup/index.jsp | |||
SNFServer is the server side of a client/server system. In order to | |||
scan messages you will need to use the client utility (SNFClient.exe | |||
or SNFIMailShim.exe) to scan messages. | |||
SNFClient.exe is a drop-in replacement for the production (2-3.x) | |||
SNF program when it is called from Declude or mxGuard or other similar | |||
software. There is no need to "brand" the SNFClient.exe | |||
program and it is not necessary to include the authentication string | |||
on the command line -- however, if you do it will be accepted and | |||
ignored without an error. | |||
SNFServer MUST be running for SNFClient to work. If SNFClient cannot | |||
reach SNFServer then it will wait for quite a while as it attempts to | |||
make contact. | |||
Here are a few ways to call SNFClient.exe: | |||
SNFClient.exe -shutdown | |||
Sends the Shutdown command to the SNF_Server. | |||
SNFClient.exe authenticationxx filetoscan | |||
Compatibility mode - ignores authenticationxx and scans filetoscan. | |||
SNFClient.exe filetoscan | |||
Normal scan mode - scans filetoscan. | |||
SNFClient.exe -xhdr filetoscan | |||
XHDR scan mode - scans filetoscan and returns X Headers. | |||
See the SNFClient_Readme.txt file for details. | |||
The SNF Client/Server pair communicate using short XML messages via a local | |||
TCP connection (typically to port 9001). Examples of SNF_XCI messages are | |||
included in snf_xci.xml (not a well formed xml file! - just some examples). | |||
It is possible to communicate directly with the SNF_Server engine via TCP | |||
from your software using the SNF_XCI (SNF XML Command Interface) protocol. The | |||
server expects to see one connection per request. The client sends an SNF_XCI | |||
request to the server. The server responds with an appropriate SNF_XCI | |||
formatted response and terminates the connection. | |||
Requests and responses are expected to terminate with a newline character. | |||
You can see the XCI protocol at work by running the SNFClient in debug mode | |||
(SNFdebugClient). | |||
If you run into trouble check out our web site: www.armresearch.com and/or | |||
contact us by email: support@armresearch.com | |||
____________________ | |||
For More Information | |||
See www.armresearch.com | |||
Copyright (C) 2007-2008 Arm Research Labs, LLC. |
@@ -0,0 +1,14 @@ | |||
[Settings] | |||
ServiceName=MessageSnifferSvc | |||
CheckProcessSeconds = 30 | |||
[Process0] | |||
CommandLine = [[INSERTSNFPATHEXEHERE]] | |||
WorkingDir= [[INSERTSNFPATHHERE]] | |||
PauseStart= 1000 | |||
PauseEnd= 1000 | |||
UserInterface = Yes | |||
Restart = Yes | |||
UserName = | |||
Domain = | |||
Password = | |||
@@ -0,0 +1,90 @@ | |||
06/26/2008, 17:11:27 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 17:11:27 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 17:11:27 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 17:11:27 | |||
MessageSnifferSvc | |||
06/26/2008, 17:11:27 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 17:40:01 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 17:40:01 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 17:40:01 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 17:40:01 | |||
MessageSnifferSvc | |||
06/26/2008, 17:40:01 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 17:44:02 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 17:44:02 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 17:44:02 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 17:44:02 | |||
MessageSnifferSvc | |||
06/26/2008, 17:44:02 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 17:47:13 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 17:47:13 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 17:47:13 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 17:47:13 | |||
MessageSnifferSvc | |||
06/26/2008, 17:47:13 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 18:57:41 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 18:57:41 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 18:57:41 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 18:57:41 | |||
MessageSnifferSvc | |||
06/26/2008, 18:57:41 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 19:00:00 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 19:00:00 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 19:00:00 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 19:00:00 | |||
MessageSnifferSvc | |||
06/26/2008, 19:00:00 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 19:06:57 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 19:06:57 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 19:06:57 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 19:06:57 | |||
MessageSnifferSvc | |||
06/26/2008, 19:06:57 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 19:26:51 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 19:26:51 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 19:26:51 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 19:26:51 | |||
MessageSnifferSvc | |||
06/26/2008, 19:26:51 | |||
OpenService failed, error code = 1060 | |||
06/26/2008, 19:44:30 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.exe | |||
06/26/2008, 19:44:30 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.ini | |||
06/26/2008, 19:44:30 | |||
D:\Downloads\SNFServerDevelopment\StdTestpackage\XYNTService.log | |||
06/26/2008, 19:44:30 | |||
MessageSnifferSvc | |||
06/26/2008, 19:44:30 | |||
OpenService failed, error code = 1060 |
@@ -0,0 +1,80 @@ | |||
XYSystem Components Help | |||
[Copyright] | |||
[Table of Contents] | |||
XYNTService | |||
XYNTService is an NT service program that can be used to start and stop other programs. If you are using Windows NT 4.0 or later, it is recommended that you start XYRoot, XYDataManager, XYDispatcher, and other server processes using XYNTService. When started by XYNTService, the processes will be able to run without user login to the operating system. Only authorized persons are allowed to start and stop the processes. | |||
Here is how to use XYNTService. | |||
Using XYNTService To Start And Stop Other Processes | |||
First, the environment variable XYSYSTEMSERVICE_INIFILE represents the full path of the configuration file. If this environment variable is not defined, the default configuration file will be XYNTService.ini in the same directory as the executable. The ProcCount value in the Settings section of the configuration file is the total number of processes that XYNTService needs to start. For each of these processes, the CommandLine value in the ProcessX section of the configuration file is the command used to start the process, here X is the index (between 0 and ProcCount-1 ) of the process. When XYNTService is started, it will start all the processes defined in the configuration file. When XYNTService is stopped, the processes started by it will also be stopped in the reverse order with an exception noted later. | |||
To install the XYNTService, run the following at the command prompt: | |||
XYNTService -i | |||
Note that some programs may need to access a user's registry settings. If these programs are started by XYNTService, then XYNTService needs to be run under the corresponding user's account. This can be configured using the Services icon in the control panel. | |||
To uninstall the XYNTService, run the following at the command prompt: | |||
XYNTService -u | |||
By default, the installed NT service will be started automatically whenever the machine is rebooted. It can also be started and stopped using the Services icon in the control panel. | |||
Here is a sample configuration file for XYNTService: | |||
[Settings] | |||
ProcCount=3 | |||
LogFile=XYNTService.log | |||
[Process0] | |||
CommandLine=XYRoot | |||
UserInterface=No | |||
PauseStart=1000 | |||
PauseEnd=1000 | |||
[Process1] | |||
CommandLine=XYDataManager | |||
UserInterface=No | |||
PauseStart=1000 | |||
PauseEnd=1000 | |||
[Process2] | |||
CommandLine=java XYRoot.XYRoot XYRootJava.ini | |||
UserInterface=No | |||
PauseStart=1000 | |||
PauseEnd=1000 | |||
The parameter UserInterface indicates whether the process has a visible user interface. The parameter PauseStart indicates the number of milliseconds to wait after starting the current process. The parameter PauseEnd indicates the number milliseconds to wait before terminating the current process by force, this will give the current process a chance to shutdown itself. | |||
Note that a process started by XYNTService is visible only when the UserInterface parameter is Yes and XYNTService is running under the default system account. | |||
While XYNTService is running, it also possible to bounce a process it had started. The following command, for example, will shutdown and restart Process2 defined in the .ini file: | |||
XYNTService -b 2 | |||
To shutdown and restart XYNTService itself (which will bounce all processes defined in the .ini file), use this command: | |||
XYNTService -b | |||
Using XYNTService To Start And Stop Other Services | |||
In addition, XYNTService has the capability to start and stop other services. To start the IIS server (theMicrostoft Web Server), for example, you need only to execute the following command line: | |||
XYNTService -r IISADMIN | |||
The following command line will kill the IIS server: | |||
XYNTService -k IISADMIN | |||
The general syntax of using XYNTService to start another service is: | |||
XYNTService -r NameOfServiceToStart [other parameters for the given service] | |||
The general syntax of using XYNTService to stop another service is: | |||
XYNTService -k NameOfServiceToStop | |||
In particular, you can use the above commands to start and stop XYNTService itself. | |||
[Table of Contents] |
@@ -0,0 +1,70 @@ | |||
@ECHO OFF | |||
SETLOCAL | |||
REM ----- Edit This Section -------- | |||
SET SNIFFER_PATH=c:\SNF | |||
SET AUTHENTICATION=authenticationxx | |||
SET LICENSE_ID=licensid | |||
REM -------------------------------- | |||
CD /d %SNIFFER_PATH% | |||
echo Running SNF getRulebase.cmd > getRulebase.txt | |||
if not exist UpdateReady.txt echo No UpdateReady.txt >> getRulebase.txt | |||
if not exist UpdateReady.txt goto DONE | |||
REM The next line may cause trouble if your system stops while this | |||
REM script is running. It is not needed when this script is run | |||
REM from SNF's <update-script/> feature since only one copy will run | |||
REM at a time. However, if you are going to run a version of this | |||
REM script as a scheduled task you will want to uncomment the next | |||
REM line to make sure only one copy runs at a time-- just be sure to | |||
REM clean out any stale .lck files after a restart. | |||
REM if exist UpdateReady.lck echo getRulebase.cmd locked/running >> getRulebase.txt | |||
REM if exist UpdateReady.lck goto DONE | |||
:DOWNLOAD | |||
copy UpdateReady.txt UpdateReady.lck > nul | |||
if exist %LICENSE_ID%.new del %LICENSE_ID%.new | |||
echo. | |||
curl -v "http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf" -o %LICENSE_ID%.new -S -R -z %LICENSE_ID%.snf -H "Accept-Encoding:gzip" --compressed -u sniffer:ki11sp8m 2>> getRulebase.txt | |||
if %ERRORLEVEL% NEQ 0 del %LICENSE_ID%.new 2> nul | |||
if not exist %LICENSE_ID%.new echo New rulebase file NOT downloaded >> getRulebase.txt | |||
if not exist %LICENSE_ID%.new goto CLEANUP | |||
snf2check.exe %LICENSE_ID%.new %AUTHENTICATION% 2>> getRulebase.txt | |||
if errorlevel 1 goto CLEANUP | |||
echo New rulebase file tested OK >> getRulebase.txt | |||
if exist %LICENSE_ID%.old del %LICENSE_ID%.old | |||
if exist %LICENSE_ID%.snf rename %LICENSE_ID%.snf %LICENSE_ID%.old | |||
rename %LICENSE_ID%.new %LICENSE_ID%.snf | |||
if exist UpdateReady.txt del UpdateReady.txt | |||
if exist UpdateReady.lck del UpdateReady.lck | |||
:CLEANUP | |||
if exist %LICENSE_ID%.new del %LICENSE_ID%.new | |||
if exist UpdateReady.lck del UpdateReady.lck | |||
:DONE | |||
echo Done >> getRulebase.txt | |||
REM This is a good place to add a line that will email getrulebase.txt to | |||
REM yourself so that you know what just happened. | |||
ENDLOCAL |
@@ -0,0 +1,4 @@ | |||
<!-- Change 'licenseid' and 'authenticationxx' to match your license info --> | |||
<snf><identity licenseid='licensid' authentication='authenticationxx'/></snf> | |||
@@ -0,0 +1,2 @@ | |||
SNFClient.exe -shutdown | |||
@@ -0,0 +1,80 @@ | |||
## Basic rules for detecting Message Sniffer header emissions | |||
## so that they can be given scores in subsequent SpamAssassin | |||
## scanning. Modify the scores and headers as needed for your | |||
## system. | |||
score SNF_IPTRUNCATE 10 | |||
describe SNF_IPTRUNCATE IP Source consistently sends spam | |||
header SNF_IPTRUNCATE X-MessageSniffer-Scan-Result =~ /20/ | |||
score SNF_IPCAUTION 3 | |||
describe SNF_IPCAUTION New IP source mixed scan results | |||
header SNF_IPCAUTION X-MessageSniffer-Scan-Result =~ /40/ | |||
score SNF_IPBLACK 4 | |||
describe SNF_IPBLACK Static IP rules and GBUdb Black | |||
header SNF_IPBLACK X-MessageSniffer-Scan-Result =~ /63/ | |||
score SNF_OBFUSCATION 5 | |||
describe SNF_OBFUSCATION Obfuscation detection | |||
header SNF_OBFUSCATION X-MessageSniffer-Scan-Result =~ /62/ | |||
score SNF_ABSTRACT 5 | |||
describe SNF_ABSTRACT Abstracted spam patterns | |||
header SNF_ABSTRACT X-MessageSniffer-Scan-Result =~ /61/ | |||
score SNF_GENERAL 5 | |||
describe SNF_GENERAL General spam content - unclassified | |||
header SNF_GENERAL X-MessageSniffer-Scan-Result =~ /60/ | |||
score SNF_GAMBLE 5 | |||
describe SNF_GAMBLE Gambling and Casino spam patterns | |||
header SNF_GAMBLE X-MessageSniffer-Scan-Result =~ /59/ | |||
score SNF_DEBT 5 | |||
describe SNF_DEBT Debt and Credit offer spam patterns | |||
header SNF_DEBT X-MessageSniffer-Scan-Result =~ /58/ | |||
score SNF_GETRICH 5 | |||
describe SNF_GETRICH Home Biz, Stock Push, get rich quick | |||
header SNF_GETRICH X-MessageSniffer-Scan-Result =~ /57/ | |||
score SNF_TONER 5 | |||
describe SNF_TONER Ink and Toner offer spam patterns | |||
header SNF_TONER X-MessageSniffer-Scan-Result =~ /56/ | |||
score SNF_MALWARE 5 | |||
describe SNF_MALWARE Virus, worm, and exploit patterns | |||
header SNF_MALWARE X-MessageSniffer-Scan-Result =~ /55/ | |||
score SNF_ADULT 5 | |||
describe SNF_ADULT Porn and Adult spam patterns | |||
header SNF_ADULT X-MessageSniffer-Scan-Result =~ /54/ | |||
score SNF_SCAM 5 | |||
describe SNF_SCAM Phishing, 419, and other scam patterns | |||
header SNF_SCAM X-MessageSniffer-Scan-Result =~ /53/ | |||
score SNF_SNAKEOIL 5 | |||
describe SNF_SNAKEOIL Drugs, diet aids, health scams | |||
header SNF_SNAKEOIL X-MessageSniffer-Scan-Result =~ /52/ | |||
score SNF_SPAMWARE 5 | |||
describe SNF_SPAMWARE Spamming tools and spam hosting offers | |||
header SNF_SPAMWARE X-MessageSniffer-Scan-Result =~ /51/ | |||
score SNF_DATATHEFT 5 | |||
describe SNF_DATATHEFT Movies, software, unlimited downloads | |||
header SNF_DATATHEFT X-MessageSniffer-Scan-Result =~ /50/ | |||
score SNF_AVPUSH 5 | |||
describe SNF_AVPUSH Antivirus software push | |||
header SNF_AVPUSH X-MessageSniffer-Scan-Result =~ /49/ | |||
score SNF_INSURANCE 5 | |||
describe SNF_INSURANCE Insurance offer patterns | |||
header SNF_INSURANCE X-MessageSniffer-Scan-Result =~ /48/ | |||
score SNF_TRAVEL 5 | |||
describe SNF_TRAVEL Travel offer patterns | |||
header SNF_TRAVEL X-MessageSniffer-Scan-Result =~ /47/ |
@@ -0,0 +1,150 @@ | |||
<!-- SNFMulti V3.0 Configuration File, Setup: Typical of Win* Client / Server --> | |||
<!-- http://www.armresearch.com/support/articles/software/snfServer/config/snfEngine.jsp --> | |||
<snf> | |||
<node identity='c:/SNF/identity.xml'> | |||
<paths> | |||
<log path='c:/SNF/'/> | |||
<rulebase path='c:/SNF/'/> | |||
<workspace path='c:/SNF/'/> | |||
</paths> | |||
<logs> | |||
<rotation localtime='no'/> | |||
<status> | |||
<second log='yes' append='no'/> | |||
<minute log='yes' append='no'/> | |||
<hour log='no' append='no'/> | |||
</status> | |||
<scan> | |||
<identifier force-message-id='no'/> | |||
<classic mode='none' rotate='yes' matches='unique'/> | |||
<xml mode='file' rotate='yes' matches='all' performance='yes' gbudb='yes'/> | |||
<xheaders> | |||
<output mode='inject'/> | |||
<version on-off='off'>X-MessageSniffer-Version</version> | |||
<license on-off='off'>X-MessageSniffer-License</license> | |||
<rulebase on-off='off'>X-MessageSniffer-RulebaseUTC</rulebase> | |||
<identifier on-off='on'>X-MessageSniffer-Identifier</identifier> | |||
<gbudb on-off='on'>X-GBUdb-Analysis</gbudb> | |||
<result on-off='on'>X-MessageSniffer-Scan-Result</result> | |||
<matches on-off='on'>X-MessageSniffer-Rules</matches> | |||
<black on-off='off'>X-MessageSniffer-Spam: Yes</black> | |||
<white on-off='off'>X-MessageSniffer-White: Yes</white> | |||
<clean on-off='off'>X-MessageSniffer-Clean: Yes</clean> | |||
<symbol on-off='off' n='0'>X-MessageSniffer-SNF-Group: OK</symbol> | |||
<symbol on-off='off' n='20'>X-MessageSniffer-SNF-Group: Truncated</symbol> | |||
<symbol on-off='off' n='40'>X-MessageSniffer-SNF-Group: Caution</symbol> | |||
<symbol on-off='off' n='63'>X-MessageSniffer-SNF-Group: Black</symbol> | |||
<symbol on-off='off' n='62'>X-MessageSniffer-SNF-Group: Obfuscation</symbol> | |||
<symbol on-off='off' n='61'>X-MessageSniffer-SNF-Group: Abstract</symbol> | |||
<symbol on-off='off' n='60'>X-MessageSniffer-SNF-Group: General</symbol> | |||
<symbol on-off='off' n='59'>X-MessageSniffer-SNF-Group: Casinos-Gambling</symbol> | |||
<symbol on-off='off' n='58'>X-MessageSniffer-SNF-Group: Debt-Credit</symbol> | |||
<symbol on-off='off' n='57'>X-MessageSniffer-SNF-Group: Get-Rich</symbol> | |||
<symbol on-off='off' n='56'>X-MessageSniffer-SNF-Group: Ink-Toner</symbol> | |||
<symbol on-off='off' n='55'>X-MessageSniffer-SNF-Group: Malware</symbol> | |||
<symbol on-off='off' n='54'>X-MessageSniffer-SNF-Group: Porn-Dating-Adult</symbol> | |||
<symbol on-off='off' n='53'>X-MessageSniffer-SNF-Group: Scam-Phishing</symbol> | |||
<symbol on-off='off' n='52'>X-MessageSniffer-SNF-Group: Snake-Oil</symbol> | |||
<symbol on-off='off' n='51'>X-MessageSniffer-SNF-Group: Spamware</symbol> | |||
<symbol on-off='off' n='50'>X-MessageSniffer-SNF-Group: Media-Theft</symbol> | |||
<symbol on-off='off' n='49'>X-MessageSniffer-SNF-Group: AV-Push</symbol> | |||
<symbol on-off='off' n='48'>X-MessageSniffer-SNF-Group: Insurance</symbol> | |||
<symbol on-off='off' n='47'>X-MessageSniffer-SNF-Group: Travel</symbol> | |||
</xheaders> | |||
</scan> | |||
</logs> | |||
<network> | |||
<sync secs='30' host='sync.messagesniffer.net' port='25'/> | |||
<update-script on-off='on' call='c:/SNF/getRulebase.cmd' guard-time='180'/> | |||
</network> | |||
<xci on-off='on' port='9001'/> | |||
<gbudb> | |||
<database> | |||
<condense minimum-seconds-between='600'> | |||
<time-trigger on-off='on' seconds='86400'/> | |||
<posts-trigger on-off='off' posts='1200000'/> | |||
<records-trigger on-off='off' records='600000'/> | |||
<size-trigger on-off='on' megabytes='150'/> | |||
</condense> | |||
<checkpoint on-off='on' secs='3600'/> | |||
</database> | |||
<regions> | |||
<white on-off='on' symbol='0'> | |||
<edge probability='-1.0' confidence='0.4'/> | |||
<edge probability='-0.8' confidence='1.0'/> | |||
<panic on-off='on' rule-range='1000'/> | |||
</white> | |||
<caution on-off='on' symbol='40'> | |||
<edge probability='0.4' confidence='0.0'/> | |||
<edge probability='0.8' confidence='0.5'/> | |||
</caution> | |||
<black on-off='on' symbol='63'> | |||
<edge probability='0.8' confidence='0.2'/> | |||
<edge probability='0.8' confidence='1.0'/> | |||
<truncate on-off='on' probability='0.9' peek-one-in='5' symbol='20'/> | |||
<sample on-off='on' probability='0.8' grab-one-in='5' passthrough='no' passthrough-symbol='0'/> | |||
</black> | |||
</regions> | |||
<training on-off='on'> | |||
<bypass> | |||
<!-- <header name='To:' find='spam@example.com'/> --> | |||
<!-- <header name='Received:' ordinal='1' find='friendlyhost.com'/> --> | |||
</bypass> | |||
<drilldown> | |||
<!-- <received ordinal='0' find='[12.34.56.'/> where we want to ignore 12.34.56.0/24 --> | |||
<!-- <received ordinal='0' find='mixed-source.com'/> --> | |||
<!-- <received ordinal='1' find='mixed-source-internal.com'/> --> | |||
</drilldown> | |||
<source> | |||
<!-- <header name='X-Use-This-Source:' received='mixedsource.com [' ordinal='0' /> --> | |||
<!-- <header name='X-Originating-IP:' received='hotmail.com [' ordinal='0' /> --> | |||
</source> | |||
<white> | |||
<result code='1'/> | |||
<!-- <header name='Received:' ordinal='0' find='.friendlyhost.com'/> --> | |||
</white> | |||
</training> | |||
</gbudb> | |||
<rule-panics> | |||
<!-- | |||
<rule id='123456'/> | |||
<rule id='123457'/> | |||
--> | |||
</rule-panics> | |||
<platform/> | |||
<msg-file type='rfc822'/> | |||
</node> | |||
</snf> | |||
@@ -0,0 +1,52 @@ | |||
<!-- SNF Xml Command Interface Examples --> | |||
<!-- Scanner --> | |||
<snf><xci><scanner><scan file='filepath'/></scanner></xci></snf> | |||
<snf><xci><scanner><result code='63'/></scanner></xci></snf> | |||
<snf><xci><scanner><scan file='filepath' xhdr='yes' log='no' ip='12.34.56.78'/></scanner></xci></snf> | |||
<snf><xci><scanner><result code='63'><xhdr> | |||
X-Signature-Violations: | |||
57-1404199-965-976-m | |||
57-1404199-1352-1363-m | |||
57-1404199-965-976-f | |||
</xhdr></result></scanner></xci></snf> | |||
<!-- GBUdb --> | |||
<snf><xci><gbudb><set ip='12.34.56.78' type='good'/></gbudb></xci></snf> <!-- Set flag to good on ip --> | |||
<snf><xci><gbudb><set ip='12.34.56.78' type='bad'/></gbudb></xci></snf> <!-- Set flag to bad on ip --> | |||
<snf><xci><gbudb><set ip='12.34.56.78' type='ugly'/></gbudb></xci></snf> <!-- Set flag to ugly on ip --> | |||
<snf><xci><gbudb><set ip='12.34.56.78' type='ignore'/></gbudb></xci></snf> <!-- Set flag to ignore on ip --> | |||
<snf><xci><gbudb><set ip='12.34.56.78' type='ugly' b='1' g='0'/></gbudb></xci></snf> <!-- Set flag and counts on ip --> | |||
<snf><xci><gbudb><good ip='12.34.56.78'/></gbudb></xci></snf> <!-- Record a "good" event on ip --> | |||
<snf><xci><gbudb><bad ip='12.34.56.78'/></gbudb></xci></snf> <!-- Record a "bad" event on ip --> | |||
<snf><xci><gbudb><test ip='12.34.56.78'/></gbudb></xci></snf> <!-- Return the state of ip --> | |||
<snf><xci><gbudb><drop ip='12.34.56.78'/></gbudb></xci></snf> <!-- Forget the IP --> | |||
<!-- GBUdb Result, always --> | |||
<snf><xci><gbudb><result ip='12.34.56.78' type='ugly' p='1.0' c='0.001' b='1' g='0' range='caution' code='40'/></gbudb></xci></snf> | |||
<!-- status report request --> | |||
<snf><xci><report><request><status class='second'/></request></report></xci></snf> | |||
<!-- status report result --> | |||
<snf><xci><report><response><!-- actual status report --></response></report></xcl></snf> | |||
<!-- Server --> | |||
<snf><xci><server><command command='shutdown'/></server></xci></snf> | |||
<snf><xci><server><response message='shutdown in progress' code='0'/></server></xci></snf> | |||
<!-- Specialized Server Requests --> | |||
<snf><xci><server><command command='systemdefinedcommand'> | |||
<system-defined/><command/><elements/> | |||
</command></server></xci></snf> | |||
<snf><xci><server><response message='shutdown in progress' code='0'> | |||
<system-defined/><response/><elements/> | |||
</response></server></xci></snf> | |||
<!-- XCI Error Response --> | |||
<snf><xci><error message="What was that?"/></xci></snf> | |||
@@ -0,0 +1,156 @@ | |||
<!-- SNFMulti V3.0 Configuration File, Setup: Typical of MDaemon Plugin --> | |||
<!-- http://www.armresearch.com/support/articles/software/snfServer/config/snfEngine.jsp --> | |||
<snf> | |||
<node identity='/MDaemon/SNF/identity.xml'> | |||
<paths> | |||
<log path='/MDaemon/SNF/'/> | |||
<rulebase path='/MDaemon/SNF/'/> | |||
<workspace path='/MDaemon/SNF/'/> | |||
</paths> | |||
<logs> | |||
<rotation localtime='no'/> | |||
<status> | |||
<second log='yes' append='no'/> | |||
<minute log='yes' append='no'/> | |||
<hour log='no' append='no'/> | |||
</status> | |||
<scan> | |||
<identifier force-message-id='no'/> | |||
<classic mode='none' rotate='no' matches='none'/> | |||
<xml mode='file' rotate='yes' matches='all' performance='yes' gbudb='yes'/> | |||
<xheaders> | |||
<output mode='inject'/> | |||
<version on-off='off'>X-MessageSniffer-Version</version> | |||
<license on-off='off'>X-MessageSniffer-License</license> | |||
<rulebase on-off='off'>X-MessageSniffer-RulebaseUTC</rulebase> | |||
<identifier on-off='off'>X-MessageSniffer-Identifier</identifier> | |||
<gbudb on-off='on'>X-MessageSniffer-GBUdb-Result</gbudb> | |||
<result on-off='on'>X-MessageSniffer-Scan-Result</result> | |||
<matches on-off='on'>X-MessageSniffer-Patterns</matches> | |||
<black on-off='off'>X-MessageSniffer-Spam: Yes</black> | |||
<white on-off='off'>X-MessageSniffer-White: Yes</white> | |||
<clean on-off='off'>X-MessageSniffer-Clean: Yes</clean> | |||
<symbol on-off='off' n='0'>X-MessageSniffer-SNF-Group: OK</symbol> | |||
<symbol on-off='off' n='20'>X-MessageSniffer-SNF-Group: Truncated</symbol> | |||
<symbol on-off='off' n='40'>X-MessageSniffer-SNF-Group: Caution</symbol> | |||
<symbol on-off='off' n='63'>X-MessageSniffer-SNF-Group: Black</symbol> | |||
<symbol on-off='off' n='62'>X-MessageSniffer-SNF-Group: Obfuscation</symbol> | |||
<symbol on-off='off' n='61'>X-MessageSniffer-SNF-Group: Abstract</symbol> | |||
<symbol on-off='off' n='60'>X-MessageSniffer-SNF-Group: General</symbol> | |||
<symbol on-off='off' n='59'>X-MessageSniffer-SNF-Group: Casinos-Gambling</symbol> | |||
<symbol on-off='off' n='58'>X-MessageSniffer-SNF-Group: Debt-Credit</symbol> | |||
<symbol on-off='off' n='57'>X-MessageSniffer-SNF-Group: Get-Rich</symbol> | |||
<symbol on-off='off' n='56'>X-MessageSniffer-SNF-Group: Ink-Toner</symbol> | |||
<symbol on-off='off' n='55'>X-MessageSniffer-SNF-Group: Malware</symbol> | |||
<symbol on-off='off' n='54'>X-MessageSniffer-SNF-Group: Porn-Dating-Adult</symbol> | |||
<symbol on-off='off' n='53'>X-MessageSniffer-SNF-Group: Scam-Phishing</symbol> | |||
<symbol on-off='off' n='52'>X-MessageSniffer-SNF-Group: Snake-Oil</symbol> | |||
<symbol on-off='off' n='51'>X-MessageSniffer-SNF-Group: Spamware</symbol> | |||
<symbol on-off='off' n='50'>X-MessageSniffer-SNF-Group: Media-Theft</symbol> | |||
<symbol on-off='off' n='49'>X-MessageSniffer-SNF-Group: AV-Push</symbol> | |||
<symbol on-off='off' n='48'>X-MessageSniffer-SNF-Group: Insurance</symbol> | |||
<symbol on-off='off' n='47'>X-MessageSniffer-SNF-Group: Travel</symbol> | |||
</xheaders> | |||
</scan> | |||
</logs> | |||
<network> | |||
<sync secs='30' host='sync.messagesniffer.net' port='25'/> | |||
<update-script on-off='on' call='/MDaemon/SNF/getRulebase.cmd' guard-time='180'/> | |||
</network> | |||
<xci on-off='on' port='9001'/> | |||
<gbudb> | |||
<database> | |||
<condense minimum-seconds-between='600'> | |||
<time-trigger on-off='on' seconds='86400'/> | |||
<posts-trigger on-off='off' posts='1200000'/> | |||
<records-trigger on-off='off' records='600000'/> | |||
<size-trigger on-off='on' megabytes='150'/> | |||
</condense> | |||
<checkpoint on-off='on' secs='3600'/> | |||
</database> | |||
<regions> | |||
<white on-off='on' symbol='0'> | |||
<edge probability='-1.0' confidence='0.4'/> | |||
<edge probability='-0.8' confidence='1.0'/> | |||
<panic on-off='on' rule-range='1000'/> | |||
</white> | |||
<caution on-off='on' symbol='40'> | |||
<edge probability='0.4' confidence='0.0'/> | |||
<edge probability='0.8' confidence='0.5'/> | |||
</caution> | |||
<black on-off='on' symbol='63'> | |||
<edge probability='0.8' confidence='0.2'/> | |||
<edge probability='0.8' confidence='1.0'/> | |||
<truncate on-off='on' probability='0.9' peek-one-in='5' symbol='20'/> | |||
<sample on-off='on' probability='0.8' grab-one-in='5' passthrough='no' passthrough-symbol='0'/> | |||
</black> | |||
</regions> | |||
<training on-off='on'> | |||
<bypass> | |||
<!-- <header name='To:' find='spam@example.com'/> --> | |||
<!-- <header name='Received:' ordinal='1' find='friendlyhost.com'/> --> | |||
</bypass> | |||
<drilldown> | |||
<!-- <received ordinal='0' find='[12.34.56.'/> where we want to ignore 12.34.56.0/24 --> | |||
<!-- <received ordinal='0' find='mixed-source.com'/> --> | |||
<!-- <received ordinal='1' find='mixed-source-internal.com'/> --> | |||
</drilldown> | |||
<source> | |||
<!-- <header name='X-Use-This-Source:' received='mixedsource.com [' ordinal='0' /> --> | |||
<!-- <header name='X-Originating-IP:' received='hotmail.com [' ordinal='0' /> --> | |||
</source> | |||
<white> | |||
<result code='1'/> | |||
<!-- <header name='Received:' ordinal='0' find='.friendlyhost.com'/> --> | |||
</white> | |||
</training> | |||
</gbudb> | |||
<rule-panics> | |||
<!-- | |||
<rule id='123456'/> | |||
<rule id='123457'/> | |||
--> | |||
</rule-panics> | |||
<!-- Platform Specific Configuration --> | |||
<platform> | |||
<mdaemon> | |||
<ip-test on-off='on'/> | |||
<configurator command='start notepad' append-path='yes'/> | |||
</mdaemon> | |||
</platform> | |||
<msg-file type='rfc822'/> | |||
</node> | |||
</snf> | |||