> I agree that it's better to have those options than not at all...and > as you suggest, I definitely don't use them. But what I am opposed > to is allowing email from the internet directly in through the > firewall to an server that is in your internal corporate network > that is running Imail without doing any scanning on the emails at > all before they enter your network.
But there's no reason to assume that the IMail MX is not segregated in a DMZ. Though my guess is that, in most IMail deployments, the latter practice isn't followed, but the two are unrelated. > That's what I am trying to get at...that I personally can't > understand why people would want to allow unfiltered content > directly into their internal network. It's "unfiltered" in the sense that if there's a way of exploiting SMTPD, and the SMTPD is also a mailbox server, then your mailboxes are owned automatically. But if you own the SMTPD, it's trivial to sniff the traffic on the way to the mailbox server, so you're up the creek no matter what. It's a similar issue to allowing access to a DMZ-based reverse HTTP proxy that might have a vulnerability. Putting it in a DMZ isn't going to do much good. If one port needs to be user-facing, that port is vulnerable, and that server has readily decryptable data passing through it, the rest is history. > Imail 2006 is only brand new....and I don't understand how any of us > can be sure that there are no possible flaws that could allow Imail > to be manipulated into allowing access to your network. Well, I'm not running IMail 8.2x yet in production. :) I think that the SMTPD can be assumed to be unchanged from 8.2x. It hasn't been out for too long, but it's not yesterday, either. IMail vets may take chances on it because the performance is that much better than the previous version. Newbies will roll it out because they have no reason to think that a major-label product is vulnerable. Whether this is wise will take a while to shake out. > I'm sorry if my last message sounded rude and harsh...but from a > security stand-point, Network Security 101 states you should be > using a DMZ to filter all traffic before letting it into your > network. That's what I was getting at. True enough, but compared to SMTP32 from prior to 8.2x, the new one is evidently more resilient. And if you were getting _accidentally_ DoSed before just because you had too many connections, that's going to make you more likely to plug in the more scaleable version of the same product, despite the possibility of undiscovered issues that might impact more than just stability. --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/ 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/
