> >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.
Len, maybe I'm missing something. If you have IMail peering enabled, it will always check its peer list first using VRFY, prior to sending to the default gateway (even if you have "send all remote mail through gateway" enabled). Before the server sends the message, the recipient is rewritten from [EMAIL PROTECTED] to [EMAIL PROTECTED] and passed onto either your default gateway or directly to the peer. The rewrite with IP ensures that when the email is sent to the gateway server it cannot be sent back to that same box (due to DNS or MX resolutions). Try it out actually. If you have peering enabled, it will VRFY to another server and then deliver the email to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] In either case you will see the VRFY attempts in the logs, prior to actual delivery of the email. The only way to skip VRFY is to disable it. Lets say I am server1 and my domain is nowhere.com. If I send to a user not on my list ([EMAIL PROTECTED]), it is considered a local-domain, non-local user and checks with peering tables to see if a server can be resolved for delivery (using VRFY, replacing nowhere.com with [x.x.x.x]). If the user isn't the same domain, like [EMAIL PROTECTED], it's automatically forwarded to the gateway since it isn't a local domain user that is part of the peered domain of nowhere.com. > > 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. > > yep, perfect solution! :)) except IMGate has VRFY turned off. Is it possible to configure IMGate to respond to VRFY requests from an IMail peer? Just for local access or trusted IPs? Or would you need a virtual interface with another postfix instance running? > 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. Peering offers a simple way of keeping all users in the same logical address domain in IMail without fiddling with host and reply-to aliases and such. Otherwise you would just setup mail servers as individual sub-domains and map aliases from a mail hub. -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/
