Re: [Declude.JunkMail] OT: Store and Forward Spam Filtering to Multiple IPs

[Matt]

Sandy, Naturally Ipswitch's method is a major root of the issue.  I like IMail's Spool and it's simplicity in finding and understanding messages.  MS SMTP however encodes the equivalent of the Q file and it is important to be able to see that information.  So all other things being equal, I would prefer to stick with maintaining a list of text entries where only a couple of my clients have redundant capabilities and are seemingly quite satisfied rather than moving everything off to MS SMTP and complicating every day tasks of diagnosis.  Besides that, MS SMTP's logs don't always reflect the absolute truth about the session.  They log things that don't happen, and they miss logging things that do.  IMail's logs are quite nice to read. I don't think that MS SMTP would be optimal for this unless you desired to stick to a single server.  Postfix would probably be the right way to go if you spend a lot of time digging through logs and spool files like I seem to have to do virtually every day (mostly to verify that things were acting correctly on our end when there is a suggestion that it might not). If IMail allowed for multiple forwarding IP's per domain, I would consider setting up some bogus DNS entries.  I'm not totally sure that IMail's method can't be tricked in some way.  I can see the possibility that it could be and I'm all about finding ways to make software do what it wasn't supposed to be able to do :) Matt Sanford Whiteman wrote: It's a lot of work to create an extra level of complexity to handle something that is almost never an issue and can be resolved smoothly if there ever was. I heartily disagree. It doesn't take a company with tens of thousands of accounts to justify the use of the MX algorithm for unpublished servers, or other means of load-balancing mailbox servers. All it takes is a company with more than one mailbox server. For example, a client with 50 users spread across 5 small offices, each of which routes directly to the others: deny them multiple entry points from your service and you've created a single point of failure for the whole company, instead of just having a single point of failure for each office. Of course, the same goes for multiple mailbox servers at a single location. Sure, you'll say, but that all that has to happen is that you're contacted by the client, or you detect the outage yourself, and you re-hard-code the mailroute. But I'm not comfortable having to manually switch anything that's mission-critical, since that means no vacation, and since there's an existing algorithm that works absolutely perfectly for this function, I see no reason not to take advantage of it. I kinda feel that the fact that Ipswitch's archaic implementation of store-and-forward doesn't let you do this is the real reason you're taking a stand against it. Other mail systems have been able to do this for decades, and the "complexity" has long been deemed totally acceptable; once it's set up, it's not complex at all. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.