PHWinfo - Afficher un message - redundancy on multi-homed hosts for outgoing mail

11/03/2008, 16h32

On 03/11/08 05:29, Michael Grant wrote:
> No I disagree. I don't think this is a routing issue. I might be
> using the term multi-homed incorrectly. The two interfaces have
> different IP addresses on them. I cannot shove packets out one
> interface with the ip address of the other. The machine is not a
> router and there's no routing exchange between my machine and the
> network to get those packets back to me if I do.

I don't know if it is a routing issue or not. However here are some
things to consider:
- Linux (I'm not sure what kernel you are running) will use the first
(lowest order?) IP address or network interface (I'm not sure which) to
communicate if multiple addresses are on the same subnet.
- With out modification, once the kernel chooses a route, that route
will be cached. Routes are usually chosen per destination.

If you bind (I use the term loosely) messages to the Daemon Port that
they came in on, they have to go out the same Daemon Port.

> What I'm looking for is a way to tell sendmail to first try with one
> source address and if that fails, try with a different one. This
> way, if one network is down, mail still goes out.

I don't know if Sendmail its self has this ability or not. What you may
want to consider is seeing if you can't run two instances of Sendmail in
parallel (or at least two config sets under the same daemon) with each
having its own queue(s). That way if one Sendmail is unable to connect,
it could move the message to the other Sendmail's queue and have it try
to deliver on it's next queue cycle. I'm not quite sure how to go about
doing this, but at least it sounds good to me.

IPA <-> DaemonA <->
QueueA and IPB <-> DaemonB <-> QueueB.

> Up to now, when this happens, I have been flipping things over
> manually. Fortunately this doesn't occur often, though it would be
> best if it were automatic.

Another idea would be to run two separate instances of Sendmail and have
them use each other as a FallBack MX. I *think* this will provide what
you are after.

One thing that you will have to keep in mind with either approach is how
many Received: headers it takes to trigger loop detection. Seeing as
how you will likely have more dequeuing attempts, you will probably want
to raise the loop detection. Hopefully someone else who has a better
understanding of how this works will be able to with this too.

Grant. . . .

11/03/2008, 16h32	#5
Grant Taylor Messages: n/a Hébergeur:	Re: redundancy on multi-homed hosts for outgoing mail On 03/11/08 05:29, Michael Grant wrote: > No I disagree. I don't think this is a routing issue. I might be > using the term multi-homed incorrectly. The two interfaces have > different IP addresses on them. I cannot shove packets out one > interface with the ip address of the other. The machine is not a > router and there's no routing exchange between my machine and the > network to get those packets back to me if I do. I don't know if it is a routing issue or not. However here are some things to consider: - Linux (I'm not sure what kernel you are running) will use the first (lowest order?) IP address or network interface (I'm not sure which) to communicate if multiple addresses are on the same subnet. - With out modification, once the kernel chooses a route, that route will be cached. Routes are usually chosen per destination. If you bind (I use the term loosely) messages to the Daemon Port that they came in on, they have to go out the same Daemon Port. > What I'm looking for is a way to tell sendmail to first try with one > source address and if that fails, try with a different one. This > way, if one network is down, mail still goes out. I don't know if Sendmail its self has this ability or not. What you may want to consider is seeing if you can't run two instances of Sendmail in parallel (or at least two config sets under the same daemon) with each having its own queue(s). That way if one Sendmail is unable to connect, it could move the message to the other Sendmail's queue and have it try to deliver on it's next queue cycle. I'm not quite sure how to go about doing this, but at least it sounds good to me. IPA <-> DaemonA <-> QueueA and IPB <-> DaemonB <-> QueueB. > Up to now, when this happens, I have been flipping things over > manually. Fortunately this doesn't occur often, though it would be > best if it were automatic. Another idea would be to run two separate instances of Sendmail and have them use each other as a FallBack MX. I think this will provide what you are after. One thing that you will have to keep in mind with either approach is how many Received: headers it takes to trigger loop detection. Seeing as how you will likely have more dequeuing attempts, you will probably want to raise the loop detection. Hopefully someone else who has a better understanding of how this works will be able to with this too. Grant. . . .