We have tried EWall previously. I like a lot of things about EWall. However, we found that it really was not reliable enough for the amount = of email we were dealing with. We received several updates for EWall that fixed some of the reliability concerns, but not all of them. The = programmer is extremely responsive to bug reports and such, but the EWall product = has not proven itself to be reliable enough for large ISP grade deployments. = I imagine someday EWall will be debugged enough for such high volume deployments, but not yet.
I honestly think the best solution will be to write a dll that handles communicating with SpamD and ClamD as well as the logic for deciding = what to do based on the responses from SA & ClamAV. That will yield the best performance in the Windows environment. The logical first step for me = is to write everything I need into a single native Win32 process and call that process from XMail. With any luck, maybe XMail will someday have = options for hooking into dll based filters and then I can recompile my filters = as a dll file. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] = On Behalf Of Jason J. Ellingson Sent: Friday, November 05, 2004 6:10 PM To: [EMAIL PROTECTED] Subject: [xmail] Re: [****SPAM****] RE: Re: Spam Filters 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 = =3D 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 = =3D there would be one additional process running overall (ClamD). =3D20 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 = =3D full path to the file or folder that needs to be scanned. SpamC actually =3D sends the file over the wire to SpamD. I wish ClamAV shot the file over the = =3D wire, because then I would cluster ClamD on a bunch of FreeBSD boxes like I = =3D 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 = =3D handle the spam and virus scanning. That solution would be nice because it =3D would mean the message only needed to get sent over the wire once and the =3D 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 = =3D AV code into that one VC++ project. That would reduce the number of =3D launched processes to one per email hit, which would be a huge improvement over = =3D my existing solution. Then if/when there are dll hooks for filters in =3D XMail, I could quickly recompile my VC++ code as a dll. =3D20 I have written ISAPI and WSAPI stuff before for IIS and Website Pro, so = =3D I have seen first hand the gains when switching from a CGI to an ISAPI. = =3D The gains are huge. In the case of XMail, the filters are perfect =3D 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] - 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]
