> Sorry for the confusion. No problem...but you're still a bit confused. :)
> The situation is I have two different hosts that are responsible for the > domain.com. Okay, let's stop right there. As I tried to describe earlier, if a host performs local delivery to a domain, this means that, unless specifically told otherwise, it will consider an address @ that domain to be nonexistent (and generate a 5xx error during the SMTP transaction) unless it is found in its directory of users for that domain. Conversely, if a host performs remote delivery (relaying) to a domain, this means that, unless specifically told otherwise, it will consider an address @ that domain to be deliverable to any one of the other MXs for that domain, but NOT to itself. Without realizing it, you are looking for your hosts to consider the same domain to be both local and remote, depending on the username (the 'local-part') of the recipient address. Make sure you understand this concept before continuing, and realize that making your systems perform in this way is non-traditional, and may not be easy, or even possible, depending on the software platforms in use. You are probably wondering by now, "Well, then what the h*** are primary and secondary MXs for? Aren't they a traditional use of SMTP, and don't they do this by definition?" The answer is no: no matter the number of MX records, in traditional SMTP, the *final* recipient domain usually has only one mailbox server (server that performs local delivery to mailboxes). "You mean every address @hugeisp.net ends up on the same POP3 server?" you ask. Again, no: through the use of that manage routing and aliasing, [EMAIL PROTECTED] can be routed straight through to the mailbox server for hugeisp.net without any modification, while [EMAIL PROTECTED] can be translated before delivery into [EMAIL PROTECTED] and routed to the mailbox server for mail2.hugeisp.net, [EMAIL PROTECTED] can be translated in transit into [EMAIL PROTECTED], and so forth. You are essentially implementing a variation of this whenever you give a mobile user a local alias for their (AOL) address, without a local mailbox. But back to your setup. You are trying to extend IMail beyond SMTP's basic local delivery vs. remote delivery decision, trying to partition a single domain across local and remote mailboxes. You could do this in a user-by-user way, by making sure that imail.domain.com and exchange.domain.com are the MXs for their respective hostnames, then creating user aliases on the IMail server that translate [EMAIL PROTECTED] into [EMAIL PROTECTED] But Ipswitch also has a very cool peering function (read up on it, like I suggested) that is able, in essence, to automatically look for any domain.com address that it doesn't have a local mailbox for on another server that you designate by IP address. So with peering in place, you wouldn't have to manage any non-local aliases on the IMail side--just leave people out of the local database and they'll automatically looked up on the remote server (you do have to make a one-time change to the Exchange SMTP greeting, but that is a drop in the bucket). Yet there's always a catch when you're not only stretching SMTP but mixing platforms, too. IMail peering is great, but it only works bidirectionally between IMail servers; Exchange has no such wildcard function to go back in the other direction (things are somewhat different if you are using an all-Exchange network, as you can have transparently distributed mailbox servers). So if someone tries to send to a non-Exchange user through the Exchange box, unless Exchange has the non-local address [EMAIL PROTECTED] (or, in AD, the Full Name of the user) aliased to [EMAIL PROTECTED], the mail will fail, as it does now. > Sounds like I need something in the wins hosts file to detail their > existence to each other. Not WINS (LMHOSTS), I suppose you mean, but HOSTS. But no, that won't help either. Make sense now? -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/
