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.
No, can't turn off peering. How will Imail send out a msg from a @domain.com box to [EMAIL PROTECTED] on another box? Peering is the only way Imail will not reject [EMAIL PROTECTED] as unknown user.
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]
but how? if Imail hosting domain.com receives a msg for [EMAIL PROTECTED], how will a non-peered Imail NOT reject the msg as unknown user?
> 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
it does, and much more.
, why bother with peering at all (except for the case that you want near real-time VRFY address resolution).
A dial-up user relaying outbound to Imail for a [EMAIL PROTECTED]
> 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.
What would be presented by IMail peer to IMgate as the envelope recipient? [EMAIL PROTECTED] (fine for IMGate) or [EMAIL PROTECTED] ?
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
ok, good, then all the Imail peers could be told their only peer is the IP of IMGate.
> mx3# postconf | grep vrfy > disable_vrfy_command = yes
more complicated than what it's worth.
The discussion is complicated, but the final config could be simple.
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,
how? If IMail thinks it is the only destination for @domain.com, how will it not reject RCTP TO: [EMAIL PROTECTED] as unknown.
Sorry to waste everyone's time exploring the possibilities of IMail peering.
It's not a waste. Imail peering's traffic penalty could be comletely removed by IMGate, if we can pin down the details.
Len
_____________________________________________________________________ http://MenAndMice.com/DNS-training: New York; Seattle; Chicago IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free
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/
