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).