> plumbing implies "no user involvement", and once the plumbing is > installed, even the plumbers never touch it. ie, hands free > maintenance.
Peering offers more one-time "plumbing, " as you put it, and less continuous maintenance than using a non-peering gateway against more than one mailbox server for the same domain. Eschewing peering in a multi-mailbox-server environment requires the continuous reimport of alias tables after any user is added, renamed, or moved. This may be a simple "one-touch" script after every update to the userbase, or performed on a periodic basis, but it is not real-time or error-free, as is ideal (people will live with what they think is the best solution because they haven't been exposed to alternatives, or because there are other great functional areas offered by an alternative solution, but that does not diminish the importance of hands-free user maintenance in general criteria). It's relevant to highlight that when using a IMail gateway without any peering, you can export and import alias tables there as well to provide envelope rejection and/or inbound routing to multiple servers. > peering, always increases SMTP traffic between peers... I don't see an object here: increases it over what? Peering is presented here, and in the IMail manual, as an alternative to a single mailbox server. I didn't see this as a debate over about turning an existing static-routed server farm into a peer server farm and worrying about its SMTP carrying capacity before and after peering is introduced. It's about the decision to implement, or continue to use, a peer server farm instead of a single mailbox server. So an "increase" is logically impossible. All you will see in a proper implementation of peering is an increase in user performance relative to the performance of a single server. Could user performance *then* be increased again by the addition of a third-party or IMail 8 remote delivery gateway on top of peering? Yes. Can a third-party or IMail 8 gateway do what peering does for the management of mandatory user resources? No. Can peering do what some third-party MXs can do for anti-spam protection? No. Can an IMail 8 MX do what some third-party MXs can do for anti-spam protection? No. > and requires users to remember which peer they must connect to for > reading mailboxes, which itself requires new DNS subdomains of > peer1.domain.com, peer2.domain.com, and pushes that info to the > users level. There's no plain-vanilla that allows multiple mailbox servers, yet does not require users and/or their MUAs to know where their mail is hosted, so this isn't an argument for plain-vanilla over peering. It's a good argument for application proxies/intelligent load balancing/shared storage over peering, but that's a no-brainer if you have loads of cash to throw into middleware, no? Also, the use of "peer1" as a hostname would be about the worst naming practice. If you have branches in AZ and MI, is it that easy to forget to go to http://arizona.example.com? Most multinational enterprises don't think so. In addition, a local nameserver (or, even without DNS, Windows name resolution) simplifies this to http://mail. No matter how you simplify or extend your naming conventions, when multiple mailbox/web servers are required for user-acceptable performance but you don't have the budget to put in transparent load-balancing/routing as well, you *must* end up with multiple hosts. >> and would also allow branch office managers to manage their own >> userbase without any communications with HQ , if desired. > This is the ONLY advantage of peering, so they darn better desire it, to > offset the disadvantages. I'm understanding that from the outside, you still don't see how and why peering works, but I will attempt to give some more use cases in a follow-up e-mail. -Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] ------------------------------------ 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/
