G- I've considered switching to a Linux based solution many times before. The lack of a decent GUI interface for Postfix is the one thing that keeps me with iMail.
Right now, I'm developing a project with another network admin (one who knows Linux a lot better than I know Windows) to create something similar to IMgate, but that runs the Postfix MTA on Debian Linux. Our prototype acts as a bridging firewall type of appliance, and does the usual virus scanning, DNSRBLs, internal blacklists, and some other checks as well. The idea is to have a box that runs in front of iMail, without the need to change IPs of the main mail server. It also uses Spam Assassin to tag messages, but leaves it to iMail to decide what to do with the messages based upon the tagged headers. It's a lot like IMgate in many respects, just a little different, and hopefully a little easier to administrate (via a web browser) than learning BSD or Linux. I hope to have something together in the next few weeks. It's been a lot of fun to work on so far. Working with ASSP has given me some other new ideas to throw into the thing. William Van Hefner > Point taken. The inability ti interface spam/virus solutions DIRECTLY with > IMail to cause rejects rather than delete/bounce has me me working on > trying to convert any of my clients using IMail over to a *nix SMTP > solution (using PostFix most likely). Bounces have become useless (and > often destructive) with the rampant address forging today. Even Declude > Junkmail has made changes to the "BOUNCE" action that force an > admin to pay > close attention to the manual to get it to work -- and the manual > says DON'T > DO IT!! > > It seems a multi machine strategey is now needed with IMail. IMGate to > reject some stuff (including unknow users) with ASSP behind that to do > Bayesian filtering on the ones that pass. And probably Declude Junkmail > with a weighting system on the IMail machine to give you a few more > delivery sorting options. > > Running a complete linux solution could handle many of these > tasks right at > the SMTPD level with Postfix accepting input from the screening programs > and REJECTing the mail at that level. Failure notification is provided and > no bounces are necessary. > > IMail is trying to build all the scanning/filtering/rejecting functions > directly into an already "flaky" SMTPD engine. It already takes careful > hardware configuration just to get it to reliably handle the same load a > Postfix setup can handle on pretty much whatever (modern) machine you drop > it on. Adding all the extra functions is just going to require multiple > licenses so heavy loads can be balanced across multiple servers. > > I have three customers using IMail now. I'm going to try to > convert the one > using only a single domain on his mail server some time this year if I > can't get the spam management cost level down some. We keep > having to throw > more hardware at it. I'm going to add ASSP next -- or maybe IMGate, I > haven't decided which will do me the best and I have only one machine > available for adding to the network. > > G > > On Thu, 29 Jan 2004 08:09:38 -0800 > William Van Hefner said something about RE: [IMail Forum] ASSP: > > > I only have Declude A/V running on our server, so that may be correct. > > However, it is MUCH more efficient to block the SMTP transmission based > > upon a DNSRBL before the spam gets through, than accepting the message > > (and having to process it) in the first place. If you accept the message > > for delivery (rather than blocking) then you have to decide what to do > > with the message as well (bounce? deliver to recipient? tag? use in a > > weighting system?). That takes mucho more resources and is a much bigger > > headache from a policy standpoint. > > > > I would rather just return a 5XX reject message to someone that is on > > SpamCop. Let their mail admin deal with their blacklisted server > > problems. Better them than me. I guess that all depends upon your > > religion though, and whether you lean more towards Len or Scott's > > viewpoint of what should be blocked. I see merits in both arguments, but > > on the most reliable DNSRBLs I use, I would much rather block than waste > > all that processing on filtering. > > > > William Van Hefner > > > > > Hmmm seems if your running Declude on the IMail box the DNSRBLs > > > could still be used with Declude's "HOPS 1" option. This tells declude > > > that the top IP is your gateway and the next IP should be where all > > > tests start. > > > > > > G > > > > > > On Thu, 29 Jan 2004 00:34:13 -0800 > > > William Van Hefner said something about [IMail Forum] ASSP: > > > > > > > make iMail's own DNSRBL look-up feature useless, since it would only > > > > be doing lookups on the IP address of your own mail server, not the > > > > address of the originating sender. All your iMail box will do is a > > > > lookup of the IP address 127.0.0.1. > > > > > > > > William Van Hefner > > -- > Gerald V. Livingston II > > Configure your Email to send TEXT ONLY -- See the following page: > http://expita.com/nomime.html > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > --- > [This E-mail scanned for viruses by Declude Virus] > > > --- [This E-mail scanned for viruses by Declude Virus] To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
