VRFYs would still be required by IMail peers to resolve the correct server before forwarding to IMGate.
no. An Imail local user on peerA creates a message for a [EMAIL PROTECTED] on PeerB. Imail relays the msg to [EMAIL PROTECTED] to IMGate (imail does not need to rewrite the @domain part), who looks up non-localuser and send to the correct IMGate.
The only way to reduce chatty VRFYs with several IMail peers is to actually replace the IPs of all those peers with an IP or two for IMGate as the peer (two IMGate IPs in case one fails). In this arrangement IMGate would need to be setup with address maps to the correct servers and able to respond to VRFYs for the trusted IPs of the remote mail servers. This way IMGate could be configured as the actual IMail peer and would then become the center mailhub. This would reduce VRFY lookups to other remote locations. For example:
yes, that would keep the VRFYs "in house", good idea.
Server1 on segment A contacts IMGate on WAN segment Q, does VRFY, VRFY success, email is delivered to IMGate, IMGate looks up user's address and redelivers to server5 on WAN segment E.
yep, perfect solution! :)) except IMGate has VRFY turned off.
This could allow you to easily add 10s or hundreds of IMail servers, just adding a couple IMGates behind load-balancing.
not load balancing, IMGate as mail-routing hub
Of course, the issue then becomes a matter of maintaining several IMail servers through a unified interface.
the only justification for peering is to allow local admin for a peer, so no need for an admin on one peer site to admin an Imail on a remote peer site. If user-level admin was an problem, you wouldn't be doing Imail peering in the first place, since peering complicates user level admin by distributing it.
Len
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/
