Re: [Clamav-users] RELOAD/VERSION issues
On Thu, Aug 18, 2005 at 04:00:19PM +0200, Marc Haber said:
Hi,
the clamd docs say quite clearly that it is necessary to either send
the RELOAD command to the daemon or to send SIGUSR2 to the daemon to
have it reload the database.
However, the VERSION command and clamdscan -V report the new database
version immediately after putting the new databases in place.
OK, I have been thinking about this a little more, and it looks to me
like the simplest thing may be to add an element to the cl_node root
struct containing version information.
So it would look something like:
struct cl_node {
unsigned int refcount;
unsigned int maxpatlen; /* maximal length of pattern in db */
+unsigned int version; /* version of db */
/* Extended Boyer-Moore */
int *bm_shift;
struct cli_bm_patt **bm_suffix;
/* Extended Aho-Corasick */
struct cli_ac_node *ac_root, **ac_nodetable;
unsigned int ac_partsigs, ac_nodes;
/* MD5 */
struct cli_md5_node **md5_hlist;
/* Zip metadata */
struct cli_meta_node *zip_mlist;
/* RAR metadata */
struct cli_meta_node *rar_mlist;
};
and something like this would have to be added to cli_loaddb:
root-version = cl_cvdhead(fd);
(with appropriate error checking of course - this is just a rough outline
of the idea).
Then the in memory version could be relatively easily queried, without the
overhead of scanning the on disk databases, and without the false answer.
Although perhaps this would fail if multiple databases are used (which of
course they always are)? I haven't thought through that part enough, I
guess. Because of course there is only one root, although many databases
are loaded into it, version would be overwritten each time, correct? So,
I guess some wrapper that does a string comparison for daily is in order,
although I don't immediately see if that will work - the cvd files are
unpacked and then loaded, so I am not sure what where the version check
should take place. Hmm, maybe time to stop rambling and start working :)
--
--
| Stephen Gran | lighthouse, n.: A tall building on the |
| [EMAIL PROTECTED] | seashore in which the government|
| http://www.lobefin.net/~steve | maintains a lamp and the friend of a|
|| politician. |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] RELOAD/VERSION issues
Stephen Gran said: On Thu, Aug 18, 2005 at 04:00:19PM +0200, Marc Haber said: Hi, the clamd docs say quite clearly that it is necessary to either send the RELOAD command to the daemon or to send SIGUSR2 to the daemon to have it reload the database. However, the VERSION command and clamdscan -V report the new database version immediately after putting the new databases in place. OK, I have been thinking about this a little more, and it looks to me like the simplest thing may be to add an element to the cl_node root struct containing version information. If I were king and could set priorities and someone has dev cycles to burn I'm much rather see a control channel added to clamd that listens on a separate port from the data port (3311, 'fristance). This new control port would be a tcp socket only and could be bound to the loopback interface or to a network interface, and it would allow queries from tools such as Big Brother, Big Sister, Auntie Em, or Network Node Manager, what ever. This allows using the more efficient Unix socket for the data passing while allowing remote access to the daemon for testing, querying, forcing reloads, etc. And while you're in there, who ever you might be, do it to freshclam's daemon mode, too. dp ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Using clamav-milter with sendmail.
Hi, I would like (only) postmaster to be sent notifications. This works fine until I include '--force-scan' in the clamav-milter startup. This directive seems to suppress the sending of all notifications. I have seen similar postings elsewhere but the problem doesn't seem to have been resolved. CLAMAV_FLAGS=' --timeout=0 --config-file=/etc/clamd.conf --max-children=10 --noreject --postmaster-only --headers --force-scan --local /var/milter/clmilter.sock' Any help would be greatly appreciated. Allan ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Restarting Freshclam
I've just installed ClamAV last night and after reading through the archives I setup a cronjob to restart freshclam on boot. I got a chance to test this today since my box decided that it wasn't going to play anymore, after the reboot I noticed two freshclam processes running, one with no variables and the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? -- Chris Registered Linux User 283774 http://counter.li.org 13:12:43 up 56 min, 1 user, load average: 0.17, 0.14, 0.16 Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Restarting Freshclam
Chris said: I've just installed ClamAV last night and after reading through the archives I setup a cronjob to restart freshclam on boot. I got a chance to test this today since my box decided that it wasn't going to play anymore, after the reboot I noticed two freshclam processes running, one with no variables and the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? I prefer to run freshclam out of cron as it means I don't need to create a daemon monitoring process for freshclam. I also prefer to use a randomizer to avoid piling on the servers - don't, for example, run cron at cardinal time points. Here's a script I adapted from an a submission in this list: #!/bin/bash sleep $[ RANDOM % 3000 ] /usr/local/bin/freshclam --quiet --daemon-notify=/usr/local/etc/clamd.conf exit It sleeps a random time then gathers the new database. It's more server friendly than lighting off at 0 * * * * in cron. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Restarting Freshclam
On Sun, Aug 21, 2005 at 01:51:02PM -0500, Chris said: On Sunday 21 August 2005 01:24 pm, Dennis Peterson wrote: the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? I prefer to run freshclam out of cron as it means I don't need to create a daemon monitoring process for freshclam. I also prefer to use a randomizer to avoid piling on the servers - don't, for example, run cron at cardinal time points. Here's a script I adapted from an a submission in this list: Since I had a cronjob to start freshclam on boot and it apparently was started by another means also, how to only have it run from the cronjob? er, disable the init script? Where that script lives is dependant on your platform. -- -- | Stephen Gran | Some of them want to use you, Some of | | [EMAIL PROTECTED] | them want to be used by you,| | http://www.lobefin.net/~steve | ...Everybody's looking for something. | || -- Eurythmics | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Restarting Freshclam
Chris wrote: I've just installed ClamAV last night and after reading through the archives I setup a cronjob to restart freshclam on boot. I got a chance to test this today since my box decided that it wasn't going to play anymore, after the reboot I noticed two freshclam processes running, one with no variables and the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? You have it all wrong, the -d parameter means (man freshclam): -d, --daemon Run in a daemon mode. This option requires --checks. So you either run freshclam once with -d or run it from cron without -d. And your statement about setup a cronjob to restart freshclam on boot is wrong, if you want something to start on boot you set that on the /etc/init.d directory and related /etc/rc?.d (or equivalent since this changes from Unix to Unix), you don't use cron for that. If you don't know what you are doing then start by reading the documentation. HTH -- René Berber ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Restarting Freshclam
On Sunday 21 August 2005 01:24 pm, Dennis Peterson wrote: the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? I prefer to run freshclam out of cron as it means I don't need to create a daemon monitoring process for freshclam. I also prefer to use a randomizer to avoid piling on the servers - don't, for example, run cron at cardinal time points. Here's a script I adapted from an a submission in this list: Since I had a cronjob to start freshclam on boot and it apparently was started by another means also, how to only have it run from the cronjob? -- Chris Registered Linux User 283774 http://counter.li.org 13:48:12 up 1:31, 1 user, load average: 0.14, 0.60, 0.73 Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Restarting Freshclam
On Sunday 21 August 2005 02:09 pm, René Berber wrote: Chris wrote: I've just installed ClamAV last night and after reading through the archives I setup a cronjob to restart freshclam on boot. I got a chance to test this today since my box decided that it wasn't going to play anymore, after the reboot I noticed two freshclam processes running, one with no variables and the other as I had set it up in the cronjob with -d -c 24. I take it then that the cronjob is not necessary to restart freshclam and that all variables are read from the /etc/freshclam.conf file. Is that a correct assumption? You have it all wrong, the -d parameter means (man freshclam): -d, --daemon Run in a daemon mode. This option requires --checks. So you either run freshclam once with -d or run it from cron without -d. I realize that, my cronjob reads freshclam -d -c 24 which runs in damon mode and makes 24 checks in a 24hr period. Or, at least that's the way I interpreted the man page. And your statement about setup a cronjob to restart freshclam on boot is wrong, if you want something to start on boot you set that on the /etc/init.d directory and related /etc/rc?.d (or equivalent since this changes from Unix to Unix), you don't use cron for that. When using webmin to setup a cronjob you have an option: When to execute Run on selected schedule .. Run at times selected below .. I have it set to Run on selected schedule - when system boots If you don't know what you are doing then start by reading the documentation. I read the man pages, maybe I misinterpreted them! HTH -- Chris Registered Linux User 283774 http://counter.li.org 14:14:59 up 1:58, 1 user, load average: 0.33, 0.37, 0.32 Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Restarting Freshclam
Chris wrote: [snip] So you either run freshclam once with -d or run it from cron without -d. I realize that, my cronjob reads freshclam -d -c 24 which runs in damon mode and makes 24 checks in a 24hr period. Or, at least that's the way I interpreted the man page. That is correct. My comment is about the use of cron, which usually is intended for running scheduled programs and that schedule implies repetition. [snip] When using webmin to setup a cronjob you have an option: When to execute Run on selected schedule .. Run at times selected below .. I have it set to Run on selected schedule - when system boots I've never seen cron used like this. So my comment before was apparently wrong, I'm not sure wich version of cron allows this when system boots option. If you don't know what you are doing then start by reading the documentation. I read the man pages, maybe I misinterpreted them! Perhaps I'm the one that has obsolete information, well what you describe certainly doesn't work on Solaris 9, perhaps it works on Solaris 10 and/or new Linux distributions (are you using Fedora Core 4?). Anyway, the problem you described is still there, something (perhaps that new cron) ran freshclam at least twice. The idea, if you want freshclam as daemon, is to run it once with the -d option, or run it periodically (using cron) without -d. HTH, sorry for my misunderstanding. -- René Berber ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Restarting Freshclam
On Sunday 21 August 2005 02:48 pm, René Berber wrote: When using webmin to setup a cronjob you have an option: When to execute Run on selected schedule .. Run at times selected below .. I have it set to Run on selected schedule - when system boots I've never seen cron used like this. So my comment before was apparently wrong, I'm not sure wich version of cron allows this when system boots option. Version 1.150 on cpollock.localdomain (Mandrakelinux 10.1) If you don't know what you are doing then start by reading the documentation. I read the man pages, maybe I misinterpreted them! Perhaps I'm the one that has obsolete information, well what you describe certainly doesn't work on Solaris 9, perhaps it works on Solaris 10 and/or new Linux distributions (are you using Fedora Core 4?). Anyway, the problem you described is still there, something (perhaps that new cron) ran freshclam at least twice. The idea, if you want freshclam as daemon, is to run it once with the -d option, or run it periodically (using cron) without -d. HTH, sorry for my misunderstanding. No problem, at least you didn't reply with a curt RTFM as I've gotten in other lists, and I'll be the first one to admit that I'm not even close to being an expert in anything, however I do make a point to read the man pages before jumping into anything. In Mandriva the init script for all services is in /etc/rc.d/init.d what I've done, and maybe this will work, is I moved the freshclam init script to another folder, took the script that was provided in another message, placed it in my /usr/local/bin folder and run it as a cronjob hourly. With the random sleep variable it should work. I'll find out next time my hourly syslog snippet is sent to me. -- Chris Registered Linux User 283774 http://counter.li.org 14:58:48 up 2:42, 2 users, load average: 0.34, 0.52, 0.50 Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk ~~ If a file takes more than 30 minutes to download, someone in your house will pick up the phone within the last 15 seconds -- Murphy's Laws of BBS'ing n°11 ~~ ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Restarting Freshclam
On Sun, Aug 21, 2005 at 02:48:55PM -0500, René Berber said: Chris wrote: I have it set to Run on selected schedule - when system boots I've never seen cron used like this. So my comment before was apparently wrong, I'm not sure wich version of cron allows this when system boots option. Many linux distros use vixie cron patched to allow @reboot syntax. I am not particularly surprised it is not portable :) If you don't know what you are doing then start by reading the documentation. I read the man pages, maybe I misinterpreted them! Perhaps I'm the one that has obsolete information, well what you describe certainly doesn't work on Solaris 9, perhaps it works on Solaris 10 and/or new Linux distributions (are you using Fedora Core 4?). Anyway, the problem you described is still there, something (perhaps that new cron) ran freshclam at least twice. The idea, if you want freshclam as daemon, is to run it once with the -d option, or run it periodically (using cron) without -d. HTH, sorry for my misunderstanding. Certainly the OP should run freshclam from a normal init script, if the idea is to start freshclam at boot. OP: locate the init script that starts freshclam, and set your options that way, and then skip the cron job. The init script method is the 'normal' way of doing things, and will be something that admins that come after you will quickly grok. Doing things in a non-standard way only raises the curve for others who have to follow you. -- -- | Stephen Gran | party, n.: A gathering where you meet | | [EMAIL PROTECTED] | people who drink so much you can't | | http://www.lobefin.net/~steve | even remember their names. | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Restarting Freshclam
On Sunday 21 August 2005 03:09 pm, Stephen Gran wrote:
Certainly the OP should run freshclam from a normal init script, if the
idea is to start freshclam at boot. OP: locate the init script that
starts freshclam, and set your options that way, and then skip the cron
job. The init script method is the 'normal' way of doing things, and
will be something that admins that come after you will quickly grok.
Doing things in a non-standard way only raises the curve for others who
have to follow you.
Gave up on the cronjob, I'll let freshclam start as per the init script. I did
try adding the sleep to the init script, but, when placing it after
${LOGFILE}, and running service freshclam start from the cli resulted in
the process starting Starting Clam AntiVirus Update Daemon: but the 'ok'
was not given. My guess is because of the sleep variable. Tried after the
daemon /usr/bin/freshclam \ however that resulted in the config file not
being found, lastly after --daemon which resulted in two freshclam processes
running, one owned by clamav and the other by root. I'll just leave the init
script as it was for now unless someone sees a good place to put the sleep
variable. FWIW Stephen this is a simple home system running nothing but
Mandriva Linux, not even networked to another computer. I'm simply running
clamav to see what virus's are making it through my ISP's virus blocker.
# See how we were called.
case $1 in
start)
gprintf Starting Clam AntiVirus Update Daemon:
touch ${LOGFILE}; chown ${USER}:${USER} ${LOGFILE}
sleep $[ RANDOM % 3000 ]
daemon /usr/bin/freshclam \
--config-file=/etc/freshclam.conf \
--quiet \
--daemon
RETVAL=$?
echo
[ $RETVAL -eq 0 ] touch /var/lock/subsys/freshclam
;;
--
Chris
Registered Linux User 283774 http://counter.li.org
15:25:42 up 3:09, 1 user, load average: 0.29, 0.46, 0.37
Mandriva Linux 10.1 Official, kernel 2.6.8.1-12mdk
~~
Nothing is ever as simple as it first seems
-- Murphy's In Laws n°1
~~
___
http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Clamav.net down again ?
Clamav.net down again ? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Clamav.net down again ?
On 21/08/05, Joanna Roman [EMAIL PROTECTED] wrote: Clamav.net down again ? No -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Restarting Freshclam
Chris said:
On Sunday 21 August 2005 03:09 pm, Stephen Gran wrote:
Certainly the OP should run freshclam from a normal init script, if the
idea is to start freshclam at boot. OP: locate the init script that
starts freshclam, and set your options that way, and then skip the cron
job. The init script method is the 'normal' way of doing things, and
will be something that admins that come after you will quickly grok.
Doing things in a non-standard way only raises the curve for others who
have to follow you.
Gave up on the cronjob, I'll let freshclam start as per the init script. I
did
try adding the sleep to the init script, but, when placing it after
${LOGFILE}, and running service freshclam start from the cli resulted in
the process starting Starting Clam AntiVirus Update Daemon: but the 'ok'
was not given. My guess is because of the sleep variable.
Ok - time to back up the bus and take another whack at this, and maybe
there's an opportunity to learn something, too.
* You can run freshclam in daemon mode and from cron - no harm, no foul,
just some wasted cpu cycles.
* What you can do but should never do is run freshclam in daemon mode from
cron as this will continue to launch new instances of freshclam each time
cron wakes up.
* If you run freshclam in daemon mode it decides when to check for a new
database. You pick the interval, but the start time of that interval
depends on freshclam and when you started it. Placing a sleep statement in
the startup only affects the initial start time. It will query at that
time n intervals/day where n is in the freshclam.conf file. It doesn't
hurt to put a randomizer in there but it probably doesn't accomplish the
good intentions you meant.
* If you run freshclam from cron you have the opportunity, and I say the
obligation, to randomize the actual query time. BTW, some crons will also
do this - I run Solaris and it does not. By placing the random sleep
period in the non-daemon mode freshclam launch script you guarantee to a
high degree that you are not part of a dogpile problem on the ClamAV
servers.
So, randomizing aside, what are the ups and downs?
Upside for cron:
* Well, cron is pretty damn robust. After using it for nearly 30 years I
have never had a cron failure. That being the case it is in my mind an
excellent tool for handling repeating tasks and that, my friend, is
exactly what freshclam is doing. It is an excellent candidate for cron.
* Because cron starts a new instance of freshclam the system cannot suffer
from ills such as memory leaks common to long-running daemons.
* You will not have to write a monitoring process to ensure that freshclam
is up, running, and doing useful things. Running from cron assures you it
will. On my system I am notified by email if there is a failure - most
commonly I see Server not synch'd type messages.
* You don't need to have a startup/shutdown script as you would if running
as a daemon.
* If you run from cron you can be a good network neighbor by randomizing
the query time and period. And I will buy you a beer for being so
intelligent, assuming you are of age.
Downside for cron:
* There is no daemon running. For daemons that have interactive interfaces
such as clamd this is a disadvantage. So far as I know freshclam has no
such interface but this is always a general consideration.
* If cron dies then freshclam dies. But if cron dies you got trouble in
River City, my friend.
* There is a system penalty for starting up processes vs. having them run
continuously. For example, you could run Apache out of inetd and it would
run fine and serve pages, but oh lordy would it be expensive and slow. The
same is true for clamd - you could run it from inetd but it would have to
start up and load the databases each time it ran. Not efficient.
Freshclam, though, runs perhaps hourly, and as such is not a significant
resource load.
* Cron starts a new instance according to the schedule you define. If an
earlier instances fail to run to completion and stop then you can have a
very large parade of freshclam instances running on your system. This is a
potentially fatal problem but indicates a serious problem in your
configuration. Clearly it is abnormal, but it's worth watching for. It's
never happened in my systems.
* Truth is there's not a serious downside I can think of when running it
out of cron.
Summary:
* If you run freshclam in daemon mode don't bother with randomizers - they
won't do anything useful.
* If you run freshclam in daemon mode consider adding a monitoring tool to
ensure it's doing something useful. Not a bad idea even when running from
cron.
* If you run freshclam in daemon mode then don't also run it out of cron.
* If you run it in cron then don't use the daemon switch.
* If you run it in cron then do use a randomizer such as the script I
provided, and collect your beer.
* If you run it in cron add a process table sniffer to see if other
instances are running, and of so, notify you
[Clamav-users] managed ClamAV relays?
I've inherited responsibility for (too) many Microsoft Small Business 200x servers. While many of these have some sort of antivirus on them (Symantec, McAfee, TrendMicro), I can never be sure that they're properly updated. I'd like a managed ClamAV relay to scan for garbage (phishing, virii, trojans, etc) *before* they even hits the mail servers. Any that slip through can then be taken care of whatever AV solution is (or isn't) properly updated. Not knowing where to go for this help, I went down the clamav.net page and emailed some of the companies there. One response I got from Linux Network Care seemed very reasonable for smaller domains. - setup: 40$/hour and one hour minimum for each domain - 5$/ per domain and 5000 emails per month Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers And if the managed box went down, mine would then automatically handle the email, right? Also, I'm assuming that a such a service would not affect my working http://mail.domain.com/exchange OWA (Outlook Web Access) setup. I would roll this solution myself, but I'm a bit concerned about who will babysit this after me. Roger ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Roger Rustad said: I've inherited responsibility for (too) many Microsoft Small Business 200x servers. While many of these have some sort of antivirus on them (Symantec, McAfee, TrendMicro), I can never be sure that they're properly updated. I'd like a managed ClamAV relay to scan for garbage (phishing, virii, trojans, etc) *before* they even hits the mail servers. Any that slip through can then be taken care of whatever AV solution is (or isn't) properly updated. Not knowing where to go for this help, I went down the clamav.net page and emailed some of the companies there. One response I got from Linux Network Care seemed very reasonable for smaller domains. - setup: 40$/hour and one hour minimum for each domain - 5$/ per domain and 5000 emails per month Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers And if the managed box went down, mine would then automatically handle the email, right? Also, I'm assuming that a such a service would not affect my working http://mail.domain.com/exchange OWA (Outlook Web Access) setup. I would roll this solution myself, but I'm a bit concerned about who will babysit this after me. Roger To compare, I don't charge a setup fee 'cuz I hate them, $10.00/month/domain with no limit on messages unless you require terrabyte throughput (AOL need not apply). All else is as you state. You also get spam filtering or not. That sed, those are pretty decent rates, but since this is not rocket science you can replicate all these services with a $700 server and a bunch of free software. And having sed that, you will burn up a lot of hours tuning it, and the best way to recover that cost is to resell your service. Now we're full circle as that is what I do. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
I'm assuming that none of this will affect Exchange connectivity. Say my MX record sends to clamRelayIP and then automatically forwards to my MTA (whatever flavor of Windoze SBS). I'll just config each client to connect to Exchange via http/proxy via whatever A record I create (e.g. exchange.domain.com). (Just checking) Roger Dennis Peterson wrote: Roger Rustad said: I've inherited responsibility for (too) many Microsoft Small Business 200x servers. While many of these have some sort of antivirus on them (Symantec, McAfee, TrendMicro), I can never be sure that they're properly updated. I'd like a managed ClamAV relay to scan for garbage (phishing, virii, trojans, etc) *before* they even hits the mail servers. Any that slip through can then be taken care of whatever AV solution is (or isn't) properly updated. Not knowing where to go for this help, I went down the clamav.net page and emailed some of the companies there. One response I got from Linux Network Care seemed very reasonable for smaller domains. - setup: 40$/hour and one hour minimum for each domain - 5$/ per domain and 5000 emails per month Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers And if the managed box went down, mine would then automatically handle the email, right? Also, I'm assuming that a such a service would not affect my working http://mail.domain.com/exchange OWA (Outlook Web Access) setup. I would roll this solution myself, but I'm a bit concerned about who will babysit this after me. Roger To compare, I don't charge a setup fee 'cuz I hate them, $10.00/month/domain with no limit on messages unless you require terrabyte throughput (AOL need not apply). All else is as you state. You also get spam filtering or not. That sed, those are pretty decent rates, but since this is not rocket science you can replicate all these services with a $700 server and a bunch of free software. And having sed that, you will burn up a lot of hours tuning it, and the best way to recover that cost is to resell your service. Now we're full circle as that is what I do. dp ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
At 19:16 21-08-2005, Roger Rustad wrote: Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers Your email servers may receive viruses by email if you have a MX record pointing to them. Regards, -sm ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Roger Rustad said: I'm assuming that none of this will affect Exchange connectivity. Say my MX record sends to clamRelayIP and then automatically forwards to my MTA (whatever flavor of Windoze SBS). I'll just config each client to connect to Exchange via http/proxy via whatever A record I create (e.g. exchange.domain.com). A common configuration is to set up multiple IP's for an MX record. This psuedo load balances the primary mail servers. You set up multiple IP's in DNS which causes your DNS server will rotate the IP's at each query, or you can have multiple IP's configured with equal MX costs. 10, for example, for any number of redundant primary systems, higher for secondary fall-back systems. And you can do both. In any event your own servers should be listed as MX records. As a matter of best practices to foil spammers, I recommend setting up MX records thusly: 10 primary servers 20...nn secondary servers 30...nn primary servers The actual numbers are not important, only the order, and that they be different. The servers with the highest cost are used by really not bright spammers who try to avoid hi-power primary servers, believing that the hi-MX cost systems are less capable filters. In many cases they are - this gets around that for the really unsophisticated spammer or virus infected Windows drones that relay spam 24/7. This is thoroughly off topic here but good to know stuff. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
SM said: At 19:16 21-08-2005, Roger Rustad wrote: Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers Your email servers may receive viruses by email if you have a MX record pointing to them. Regards, -sm Even that is not needed as port scanning is quite common, but any MX record is an automatic target for spam. I have an unlisted server that gets almost as much mail as its peers. Nearly 100% spam, needless to say, which is about 40% higher than its peers. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Good point, I stupidly didn't even consider that. If I have, say, exchange.domain.com, I'm assuming that's cool, as any @domain.com mail will go to the mx record, and not the A record. SM wrote: At 19:16 21-08-2005, Roger Rustad wrote: Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers Your email servers may receive viruses by email if you have a MX record pointing to them. Regards, -sm ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Why not just set in your firewall to only allow traffic and connections from whatever relay you've set? I'm worried about all of these Exchange users, though. How do I make sure that they can connect anywhere (cafe, cable modem, etc) and still make sure that spammers don't send crap to exchange.domain.com? Dennis Peterson wrote: SM said: At 19:16 21-08-2005, Roger Rustad wrote: Not sure what happens after 5000 emails, but I'm gessing that it would just forward directly to my MTA. I'm assuming that my MX records would be something like: --MX record 0 pointed at whatever ISP is managing this box --MX record 0+ on my email servers Your email servers may receive viruses by email if you have a MX record pointing to them. Regards, -sm Even that is not needed as port scanning is quite common, but any MX record is an automatic target for spam. I have an unlisted server that gets almost as much mail as its peers. Nearly 100% spam, needless to say, which is about 40% higher than its peers. dp ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
At 21:50 21-08-2005, Roger Rustad wrote: If I have, say, exchange.domain.com, I'm assuming that's cool, as any @domain.com mail will go to the mx record, and not the A record. Yes, mail to @domain won't go to exchange.domain as it is not listed as a MX. Regards, -sm ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Roger Rustad said: Why not just set in your firewall to only allow traffic and connections from whatever relay you've set? I'm worried about all of these Exchange users, though. How do I make sure that they can connect anywhere (cafe, cable modem, etc) and still make sure that spammers don't send crap to exchange.domain.com? This is a valid response for non-public mailers. If you have an MX record published then of course it needs to be open to all. However, if you wish to have a hands-off failover system you really need to have adequate MX records and any MX record needs to be backed up with a fully capable mail server that meets your business needs, functionally. Performance wise, it can be a slow system as SMTP is blissfully gentle with slow systems, but it does need to handle the crap the world is tossing your way. Your architecture needs to be built around acceptable system failures. In most cases the primary systems are sufficiently redundant that they can be your only MX records. From a business perspective, though, it means all your email eggs are in one basket and if that basket fails owing to a bankruptcy or other non-technical failure you are left explaining it to the boss. That's where your own systems come into play - if you outsource this critical service you need a hands-off recover for any failure of your primary. Failing that you need to keep your DNS TTL times quite short so you can redirect your MX records to your systems and have the world respond in a timely fashion. What you are facing is a classic trust scenario - if you don't support MX records with your own servers you are at the mercy of your mail service provider 100% + time to redirect MX records + TTL. On the other hand, if you publish MX records for your own systems you need to provide all anti-spam/anti-virus services your business requires because not everyone is honorable about selecting mail servers in the order you define - especially spammers. Kind of reminds me of a Dirty Harry movie - so punk; did I shoot five or six? Go ahead :) This is why it is hugely important to know exactly what you need and what your ESP can provide. In the best case the ESP is adequately redundant, solvent, and competent, so you can omit your own systems's MX records. Being a krusty old geek I'd not, but I also don't have to. That's the best position to be in. What does this buy you? Quite a bit, actually. Right now, for some businesses, up to 80% of all email is unwanted. Either spam or viruses, etc. An ESP can filter all this for you, well, a hell of a lot of it, at least, using expensive processes you don't have to replicate, nor train to learn. They distribute the costs across their customer base. Good return on economies of scale and all that. You get only the healty 20% of mail so your tech requirements are quite a bit less, and you don't spend a lot of time building inane regular expressions for SpamAssassin, et al, to get rid of the debris. Costs are quite a bit less for you - effectively fighting spam is not cheap if you are carrying the entire cost burden. And we haven't even talked about keep your domain off blacklists - that is a whole nuther off-topic. When you shop around, ask. You have a right to know. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
I suppose a spammer could, say, resolve exchange.domain.com and then send mail to user@IPaddress I dunno much about spammers' antics. Is this sort of thing common? SM wrote: At 21:50 21-08-2005, Roger Rustad wrote: If I have, say, exchange.domain.com, I'm assuming that's cool, as any @domain.com mail will go to the mx record, and not the A record. Yes, mail to @domain won't go to exchange.domain as it is not listed as a MX. Regards, -sm ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
SM said: At 21:50 21-08-2005, Roger Rustad wrote: If I have, say, exchange.domain.com, I'm assuming that's cool, as any @domain.com mail will go to the mx record, and not the A record. Yes, mail to @domain won't go to exchange.domain as it is not listed as a MX. Regards, -sm Rubbish. dp ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] managed ClamAV relays?
Roger Rustad said: I suppose a spammer could, say, resolve exchange.domain.com and then send mail to user@IPaddress I dunno much about spammers' antics. Is this sort of thing common? It is the norm. dp ___ http://lurker.clamav.net/list/clamav-users.html
