> >This would happen if both servers must use a gateway server for antivirus or > >SPAM filtering by relaying all mail to gateway. Yes... this does override > >peering. > > great, then using IMGate in conjunction with Imail peering would work, and > therefore all re-delivery disappears. NOW we have scaleable peering solution.
If the servers are peered, they still send out VRFYs to determine how to rewrite the address, then they would resend the message through the default gateway host (IMGate). IMGate can cut out the extra step with inbound email from the internet if configured to map users to a specific server - so it never hits the wrong server in the first place and preventing the emails from hitting your gateway twice. > >As the number of peered servers increases, so does the number of VRFY > >inquiries to determine where a single message should go. With peering VRFY > >inquiries are done before sending through a gateway (if specified), so sending > >all email through a gateway does not reduce any of the chatty VRFYs. > > but VRFYs are "cheap" (and useless in the IMGate context) VRFYs would still be required by IMail peers to resolve the correct server before forwarding to 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: Delivery to non-local address with multiple IMail peers: Server1 on segment A contacts server2 on WAN segment B, does VRFY, fails, ... , contacts server5 on WAN segment E, VRFY success, email is delivered directly from server1 to server5. Delivery to non-local address with IMGate Peer: 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. This could allow you to easily add 10s or hundreds of IMail servers, just adding a couple IMGates behind load-balancing. Of course, the issue then becomes a matter of maintaining several IMail servers through a unified interface. -ives 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/
