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/
