> hmm, you make up the your straw-man problems and solve them, the > rest of will fix the real problems :))
I'll work on that, while you work on not always throwing IMGate at issues, even with its positive side effects. :)) > The only real protection is internal firewalling. That's irrelevant. Firewalling one server from another is meaningless when you have to pass everything through the "primary" server, as in the architecture that was being addressed in that part of my port. I clearly meant that each subdomain could survive the other's downtime. > He runs two mail servers as independent mail domains, Imail as > students.school.com and Exchange as faculty.school.com. This was already dealt with and suggested in my first e-mail (see mail1.domain.com and mail2.domain.com) and in Dave's. > The email address translation works both ways, both in and out > through Imail. Just as in my original suggestion, only with old hardware to cross your fingers over and a new OS to learn, and more alias tables to maintain (though, as I have never denied, with the well- and oft-stated benefits of IMGate). Why more alias tables? In your setup, IMGate needs to know which school.com addresses are students and which are faculty; and IMail needs to know which are which, too, or it will fail delivery (unless you put one-way peering in the mix, which you didn't mention). Or were you suggesting that ALL mail go through IMGate to be rewritten before looping back to IMail/Exchange? That'd be even as far as management load goes, but with a terrific waste of resources all around: every loopback message will spend twice as long in the IMail spool, use twice the disk I/O, etc.. Would you, of all people, want to put IMail through that? Or perhaps you meant that users would actually use the subdomains for initial addressing? If so, you've abandoned a primary requirement stated in the original post...of course, solutions are a lot easier if you do that sort of thing. :) > No $ for new machines. We've been here many times before. 90% of the organizations that I have worked for and observed would not put out-of-warranty, non-fault-tolerant hardware in a mission-critical position. Maybe Chris' employer won't mind, but it's always been cavalier to assume that tightly-managed, -standardized, or -budgeted organizations will be able to follow this suggestion. In addition, I'd hate to be working against a raft of student wanna-be-hackers as a *nix newbie. IMO, it'd be more productive (and avoid the recurrent questioning) to add such caveats to the IMGate boilerplate, instead of just charging forth...many full-time sysadmins work under what we consultants would consider abject IT misery, in terms of extra boxes that haven't been scavenged for parts, a boss who listens (isn't that why we're consultants, anyway?), purchasing authority, bureaucratic disrespect, mandatory project bidding, inane first-level support issues that ambush self-tutorial time, et al. I can think of several medium-size clients of mine, in fact, who have great, redundant production systems, but essentially nothing on the shelf (they gave to charity--who knew?). In times past, picking up a couple of $1000.00 boxes for a compelling new project was a given, but with profits slipping, that's no more. > Fantastically better anti-mail-abuse as a freebie, AND they will > realize later that IMGate will turn out to be, retrospectively, the > biggest benefit of this project. :)) Yes, IMGate is a great answer to another question. It is a great thing to have for many reasons. But it doesn't simplify the architecture in any way I can see. -Sandy Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
