> Duped messages is a not feature of peering. What was causing your dupes?
Sorry... rephrase.... message received by server1. Relayed to server 2. Traffic for the transmission of the message is duplicated via relay, the actual message isn't duplicated. In terms of network utilization, the message hits the network twice. Or worse if... Internet -> Gateway -> Server1 -> Gateway -> Server 2 > So Imail SMTP "send all outbound through gateway" routing does override > peering routing? 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. Peering just rewrites the IP destination for where the message should be sent and re-submits it to the gateway for delivery to the specific IP. So... 1) Message from internet sent to [EMAIL PROTECTED] is sent to the gateway. 2) The gateway sends the message to the default MX or specific host for domain.com, or Server1. 3) Server1 doesn't see local user, checks via VRFY to other peers, finds it and resends message to [EMAIL PROTECTED]'sIP.x.x.x] but if configured to send through gateway, delivers to gateway with newly addressed email of [EMAIL PROTECTED] 4) Gateway then sends the email directly to the IP of the second box, delivery is accepted for local user by server2. > Well, yes, less mailboxes, less mailbox reading, but peering increases the > "burden" on mailbox readers since each mailbox reader must connect to the > specific peer holding his mailbox. Burden is on those who have to configure the workstation and manage where the boxes are located. The client config should be a one-time deal unless their mailbox gets shuffled around. If you're lucky your users are intelligent enough to do this, otherwise your support staff has to touch the workstations (hopefully via remote desktop software). (I still think there is a huge need for front-end servers that treat the backend servers as one virtual server so all clients can have the same settings regardless of where their mailbox is, connecting to any one of n load-balanced front-end web, pop, or imap servers) > Let's say x = 6 peers. 1/6 of the MX traffic will arrive at a peer, but > only 1/6 of that will be for that peer's mailboxes. 1/6 * 1/6 => 2.7%, or > 97% of the traffic goes to the wrong box. oops! Doesn't quite sound right, it would depend on your MX records. This would only be the case if all peered servers were listed as equal preferenced MX records. You would normally set MX records so that one server receives all email as the primary, then does a series of VRFY on peers (straight down the list) to determine who to relay the message to. (anyone know if user location is cached, or is the lookup done each time?) Anyway, it would mean that of 6 servers, only 1/6th of the email will be delivered to that local host (if the accounts are distributed evenly across the servers). In any case, 5/6ths of the email (84 in 100) will be sent to a non-local host and for each message a series of VRFY inquiries will be used to determine the intended recipient. Granted, we're only talking about short transactions of very few bytes (x number of peers it has to check before resolving the target), but this can add up over a WAN. 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. If caching is built in to the peering, the number of VRFYs could be significantly reduced. So... that's the nature of it. In a high-volume environment where you're using peering on the same LAN segment to offer multiple servers, worst case you could easily add NICs and VLAN the peered IPs. However, this is a different story if your servers are all sitting across a slow or expensive WAN link. If 90% of your email traffic is destined for the same site it originates from then very few VRFY lookups, you'd want the peer that receives the most number of emails / day to be connected directly to the internet to reduce the number of VRFYs over the WAN. If you have a very low volume of traffic, don't worry about it... most likely it'll be fine. -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/
