Hmmm... if you wanted to have a central server do both the AV and Spam checks, then you couldn't use SpamC. SpamC only send emails less than 250k in size to SpamD.
I think the idea of EWall is best here. It is an invisible "middle-man" than can do ALL of the scanning (virus and spam) BEFORE it gets to the XMail server... but WHILE it is still in its SMTP session (neither the sending, nor receiving computers know someone is in the middle). Plus, EWall can switch the receiving SMTP server if one is down (auto failover)... meaning, you could have multiple "transparent proxies" pointing to multiple servers... the ultimate in failover! It can monitor attacks and block/tar-pit them.... ANYTHING you can imagine. I own the eWall Site version (bought it before it skyrocketted in price). The unlimited XMail version is only $129.95 and they have a free trial version you can test with. I don't use eWall right now because the LSP isn't perfected yet... otherwise it was great at killing harvesters and offloading the work of AV and Spam scanning from my primary mail servers. EWall is at www.sssolutions.net/ew/ ------------------------------------------------------------ Jason J Ellingson Technical Consultant 615.301.1682 : nashville 612.605.1132 : minneapolis www.ellingson.com [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shiloh Jennings Sent: Friday, November 05, 2004 5:50 PM To: [EMAIL PROTECTED] Subject: [xmail] Re: [****SPAM****] RE: Re: Spam Filters Yes, there is a client called clamdscan that can call clamd. ClamD can = stay running. However, that does not reduce the number of processes running. The same number of processes would need to be launched per email, and = there would be one additional process running overall (ClamD). =20 There is one limitation in that ClamD cannot be run on a separate server like SpamD can. All the the client portion of ClamAV does is send the = full path to the file or folder that needs to be scanned. SpamC actually = sends the file over the wire to SpamD. I wish ClamAV shot the file over the = wire, because then I would cluster ClamD on a bunch of FreeBSD boxes like I = did with SpamD. Another idea I had was to merge the AV functions into SpamD somehow. If I did that, then I would just use SpamC, and SpamD would = handle the spam and virus scanning. That solution would be nice because it = would mean the message only needed to get sent over the wire once and the = email servers would not need to run AV software. Regarding merging everything into one process, I have been thinking down similar lines to what you are talking about. I have been thinking about rewriting the perl script in VC++, and then merging the SpamC and client = AV code into that one VC++ project. That would reduce the number of = launched processes to one per email hit, which would be a huge improvement over = my existing solution. Then if/when there are dll hooks for filters in = XMail, I could quickly recompile my VC++ code as a dll. =20 I have written ISAPI and WSAPI stuff before for IIS and Website Pro, so = I have seen first hand the gains when switching from a CGI to an ISAPI. = The gains are huge. In the case of XMail, the filters are perfect = candidates for writing as in-process dll files instead of spawning additional processes. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
