> >Len, maybe I'm missing something. If you have IMail peering enabled, it will > >always check its peer list first using VRFY, > > agreed, we can't turn that off.
Hmmm... I thought there would be an issue if you turned off peering, but apparently it attempts to deliver to the gateway if the user isn't found on the local server, regardless of peering or not. Peering can be eliminated entirely. I wasn't aware of that. > > 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] > > are you sure it is actually re-written to a numeric part or does the peer > client just TCP to that IP and deliver RCPT TO:<[EMAIL PROTECTED]> ? Hmm... My logs show the gateway delivering to server1 as primary MX [EMAIL PROTECTED], primary MX VRFYs to server2, resends to gateway as [EMAIL PROTECTED], gateway delivers to server2 for [EMAIL PROTECTED] This could work just as well if I had aliases or virtual user setup on my gateway. > >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). Per above, I don't believe peering is necessary, based on my tests it appears as though Imail will attempt to deliver the email to the gateway anyway, even without peering. In this case email is delivered as [EMAIL PROTECTED] > ah, ok. I'll have to see how to configure postfix to accept addresses of > [EMAIL PROTECTED] Should be a simple rewrite. All in all, looks like it can be done either way. If your gateway has the capability of aliases, why bother with peering at all (except for the case that you want near real-time VRFY address resolution). > so I'm the other peer and I see the incoming msg form servera1 addressed to > [EMAIL PROTECTED] and I have 200 Imail domains, only ten of which are > peered, so I do I know which of the ten domains [EMAIL PROTECTED] is in? Not exactly... the To field doesn't get touched, it's the X-RCPT-TO field that gets modified. > I supposed we can but as with IMail, IMGate prefers strongly to keep VRFY > off. If IMGate VRFY was on, and IMGate had the global list of users, then > IMGate would VRFY. But can all the Imail peers be told to VRFY at IMGate > as the only peer? The IMail peer list just tells it which server to inquire with VRFY. There's no reason why any other server couldn't respond to that request > mx3# postconf | grep vrfy > disable_vrfy_command = yes Which leads back to a virtual IP to handle all local / trusted hosts. Sounds more complicated than what it's worth. Again, with peering disabled, an IMail server will still try and forward a message for a non-local user in the same local domain to the gateway, removing VRFY completely. Sorry to waste everyone's time exploring the possibilities of IMail peering. -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/
