I have a machine which is multi-homed on 2 different IP addresses. I
would like sendmail to listen for connections on both interfaces, but
only send outgoing mail on the second interface.

Can someone tell me how I can configure sendmail's ip address for
outgoing mail to do this?

Michael Grant

In article <1177879522.581117.116290@e65g2000hsc.googlegroups .com>
"michael.grant@gmail.com" <michael.grant@gmail.com> writes:
>I have a machine which is multi-homed on 2 different IP addresses. I
>would like sendmail to listen for connections on both interfaces, but
>only send outgoing mail on the second interface.

If it's really multi-homed, i.e. it has interfaces on different
networks, that's something that your TCP/IP stack should take care of,
specifically the routing logic. You just need to make sure the route
used for "outgoing" mail (typically the default route) is through the
desired interface, and the stack will choose the corresponding IP
address as source address for connections using that route.

>Can someone tell me how I can configure sendmail's ip address for
>outgoing mail to do this?

You can hardwire it via CLIENT_OPTIONS, see cf/README and doc/op/op.* -
but then that address will be used for *all* connections originated by
sendmail, which is generally not appropriate for a truly multi-homed
system.

--Per Hedeland
per@hedeland.org

On Apr 30, 7:20 am, p...@hedeland.org (Per Hedeland) wrote:
> In article <1177879522.581117.116...@e65g2000hsc.googlegroups .com>
>
> "michael.gr...@gmail.com" <michael.gr...@gmail.com> writes:
> >I have a machine which is multi-homed on 2 different IP addresses. I
> >would like sendmail to listen for connections on both interfaces, but
> >only send outgoing mail on the second interface.
>
> If it's really multi-homed, i.e. it has interfaces on different
> networks, that's something that your TCP/IP stack should take care of,
> specifically the routing logic. You just need to make sure the route
> used for "outgoing" mail (typically the default route) is through the
> desired interface, and the stack will choose the corresponding IP
> address as source address for connections using that route.
>
> >Can someone tell me how I can configure sendmail's ip address for
> >outgoing mail to do this?
>
> You can hardwire it via CLIENT_OPTIONS, see cf/README and doc/op/op.* -
> but then that address will be used for *all* connections originated by
> sendmail, which is generally not appropriate for a truly multi-homed
> system.
>
> --Per Hedeland
> p...@hedeland.org

Perhaps you can experiment like suggested here

http://groups.google.com/group/comp....020c0cb?hl=en&

Per Hedeland wrote:
> You can hardwire it via CLIENT_OPTIONS, see cf/README and doc/op/op.*
> - but then that address will be used for *all* connections originated
> by sendmail, which is generally not appropriate for a truly
> multi-homed system.

I wonder if the option to instruct Sendmail to use the inbound interface
as the outbound interface would suffice the OP?



Grant. . . .

Grant Taylor wrote:
> Per Hedeland wrote:
> > You can hardwire it via CLIENT_OPTIONS, see cf/README and doc/op/op.*
> > - but then that address will be used for *all* connections originated
> > by sendmail, which is generally not appropriate for a truly
> > multi-homed system.
>
> I wonder if the option to instruct Sendmail to use the inbound interface
> as the outbound interface would suffice the OP?

Here it is: DAEMON_OPTIONS('... Modifier=b ') Seems to work for
me. However, I'm not certain that's what he wants to do. I use it so
that I can have a single sendmail process serve multiple virtual hosts
that each have their own IP address(es).

However, that brings me to a question about the feature - and perhaps
a bug or design oversight with this feature:

1) I've noticed that mail that comes in via the loopback interface
gets bound to it and therefore can never leave the host. 127.0.0.1
or ::1 should probably not be bound to the mail in any case.

2) I've also noticed that mail that comes in via an IPv6 address and
gets routed back out (due to forwarding or list expansion) still is
bound to the IPv6 address (as expected). However, should the new
destination be IPv4 only (i.e. not IPv6 capable), the mail then sits
in the queue for days then eventually expires. I'm surprised that "no
IPv6 route to destination" doesn't generate a bounce/error message
back to the sender or the local postmaster.

For case #2, has anyone written (or considered) a modification to
allow mail to be bound to a DOMAIN (host-)name? That way, virtual
hosting is preserved and an allowance for a change in address family
exists (e.g. the most common case will be for a name that has both
IPv4 and IPv6 addresses defined in DNS, but maybe other address family
combinations will be permitted in the future).