"Nonetheless, our observed problems with IMail's anti-spam involved overall system stability and feature flexibility, rather than, shall we say, the "repeat performance" or predictability of individual anti-spam features"
It's rather disappointing that there needs to be any consideration given to using an add-on product in the first place. Especially when IMail has the features built in that you're paying someone else to supply. It's so frustrating that the product advertises these features as a great benefit but then I have to look elsewhere because the features have issues with stability, flexibility, performance or otherwise. I appreciate your suggestions but when I learned about the development life cycle there was a part at the end called testing!! Given all the problems that people have had with this latest so called upgrade I wonder if there is even any testing done. Not to mention that there are add-on products that are not so much an add-on as they are a replacement because IMail does such a crappy job in the first place. If my boss wasn't so bloody cheap, I would have burnt this product long ago and sent IPSwitch the ashes. Rant over, I feel better now, thanks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sanford Whiteman Sent: Friday, April 02, 2004 11:57 AM To: Remo Pistor Subject: Re[6]: [IMail Forum] SPAM filtering with 8.1 > I've been through this with you once before so I just want to get > some things strait because it seems that you don't believe what's > happening or you think it's a user error. Frankly, we use Declude, so it's certainly _not_ that I have full faith in the built-in anti-spam features. :) Nonetheless, our observed problems with IMail's anti-spam involved overall system stability and feature flexibility, rather than, shall we say, the "repeat performance" or predictability of individual anti-spam features. I just wonder, then, exactly how you are observing "kinda, sorta" behavior with aliases, as opposed to either full functionality or no functionality at all. > I guarantee if you inspect the headers on [delivered spam] you will > find that some of them have x-header that were inserted by the SPAM > filter and should have been caught by the rules but did not. What you need to test is whether adding such headers manually to identical messages, then sending one message to a new user at a new domain with just a single mailbox redirection rule, and sending a second message to a standard alias pointing to the exact same user, results in different behavior. I can't duplicate any such difference in rule processing. The next step would seem to be to ensure that your test messages fail the same tests, letting the headers get created by the engine, and try to narrow the behavior down to DNSBLs, stat filtering, etc. Turning off QM will enable you to see the messages in the exact form seen by the delivery process (which runs the rules). Maybe it's only under load--certainly could be--but in a barebones situation I doubt you'll be able to show a "kinda, sorta" behavior. Anyway, my main objection was actually to the then-unsupported "my aliases receive more spam" claim, which sounded a lot like what one of our clients might say without realizing that the aliases, to the outside world, are completely different addresses. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/ 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/ 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/
