Thanks to everyone who has responded, your suggestions do exactly what we
want. To concisely summarize...

(1) Use the proxy_interfaces directive in Postfix 2. Using the example
configuration I posted, add "proxy_interfaces = mxqueue.easystreet.com".
This is what we'll be doing.

... OR ...

(2) Configure a virtual interface on each host as mxqueue.easystreet.com.
Associate it with the loopback interface. This worked for me under
Solaris...

    ifconfig lo0:1 plumb
    ifconfig lo0:1 206.26.36.1 netmask 255.255.255.255 broadcast
206.26.36.255 up

For those who are interested, we're using redundant Foundry ServerIrons as
the load balancers and Sun Fire V100s running Solaris 2.8 as the hosts.

Extra special thanks to the Postfix development team for producing such a
fine piece of software. I'll be in therapy for years to heal the scars
from all the time I've spent poring over Sendmail .cf files :).

                                        - Ken -

Let the record reflect Kenneth Maupin <maupineasystreet.com>'s comments on
Thu, 2 Jan 2003 12:18:30 -0800:

> Hi,
>
> We're designing a new mail system which sits behind a load balancer.
> One component of this system is a set of hosts dedicated to queuing
> mail for domains to which we offer secondary MX. Our intent is to use
> the load balancer to present a single routable IP address to the
> outside world regardless of how many hosts reside behind it. The
> queuing hosts are configured with non-routable IP addresses visible to
> the load balancer only. Domains for which we offer secondary MX will
> refer to the routable address in their MX records. When the primary
> MX host is down, mail will wait on our queuing hosts until the primary
> comes back up.
>
> We'd like to use the load balancer front end instead of round-robin MX
> records because concealing the queuing hosts behind the load balancer
> allows us to remove hosts from service and add new hosts without
> modifying DNS. This also simplifies DNS considerably, as we'll have a
> single secondary MX record for all domains instead of one for every
> queuing host. We currently provide secondary MX for over 1,000
> domains, so this is a significant savings.
>
> The network diagram, example DNS records, and an abbreviated Postfix
> configuration for this system are as follows...
>
>
> ________________________________________
> NETWORK DIAGRAM
>
>
> Internet
> |
> 206.26.36.1 (mxqueue.easystreet.com)
> |
> +---------------+ ROUTABLE NETWORK
> - - - -| Load balancer |- - - - - - - - - - - - - - - - - - - - - - -
> +---------------+ NON-ROUTABLE NETWORK
> |
> +-----------------+
> | |
> 192.168.0.1 192.168.0.2 (mxqueue01. and
> mxqueue02.easystreet.com)
> | |
> +-----------+ +-----------+
> | mxqueue01 | | mxqueue02 |
> +-----------+ +-----------+
>
>
> ________________________________________
> EXAMPLE DNS RECORDS
>
> domain.com. 86400 IN MX 20 smtp.domain.com.
> domain.com. 86400 IN MX 80
> mxqueue.easystreet.com
> mxqueue.easystreet.com. 86400 IN A 206.26.36.1
>
>
> ________________________________________
> ABBREVIATED POSTFIX MAIN.CF CONFIGURATION
>
> myhostname = mxqueue01.easystreet.com
> mydestination = $myhostname, mxqueue.easystreet.com
> inet_interfaces = $myhostname
> relay_domains = hash:$config_directory/relay_domains
> alias_maps = hash:$config_directory/aliases
> alias_database = $alias_maps
>
>
> We're trying to determine the correct Postfix configuration for this
> network design. In our experiments, mail sent to domain.com arrives
> on one of the MX queuing hosts as expected if smtp.domain.com is down,
> but Postfix immediately tries to redeliver it to
> mxqueue.easystreet.com because it doesn't realize that it is acting as
> mxqueue.easystreet.com. The result is a mail loop.
>
> Our question is this: can Postfix be configured into thinking it
> should queue mail as if it is mxqueue.easystreet.com despite the host
> having no network interfaces configured with this name? Adding
> mxqueue.easystreet.com to $mydestination has no apparent effect.
>
> Any advice would be greatly appreciated. Thanks!
>
>
> - - - - - -*- - - - - -
>
>
> - Kenneth Maupin EasyStreet Online Services,
> Inc. -
> - Senior Systems Engineer Beaverton,
> Oregon -
> - maupineasystreet.com
> http://easystreet.com/ -
> - - - - - -*- - - - - -
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]