sendmail masquerading question

[Ben Scott]

  After an off-list conversation with Steven Orr <steveo>, I have a
better idea of what he's after.

SYMPTOMS

  Steven has hosts SATURN and PLUTO, and a registered domain name
<syslang.net>.  He wants SATURN to be responsible for most mail
delivery.  The MX records in the public DNS effectively tell the world
to deliver mail to SATURN, and that works fine.  From SATURN, he can
send mail to the outside world, and that works fine.  On PLUTO, he can
send mail to the outside world, and PLUTO relays the mail though
SATURN, as he wants it to.  On SATURN, he can send mail to addresses
<@syslang.net>, and that works fine.

  The problem arises when he sends mail on PLUTO to addresses
<@syslang.net>.  He wants PLUTO to hand off such mail to SATURN.
Instead, PLUTO is (attempting to) deliver the mail locally, to
mailboxes on PLUTO.

COMPLICATIONS

  The term "domain" gets interchangeably used (by everybody) to mean
"a particular entry in DNS" or "all hosts with the given name as a
parent domain".  In other words, saying "the syslang.net domain" might
mean "anything ending in *.syslang.net", or it might mean whatever
records I get when I ask my DNS resolver about <syslang.net.>, and not
the various hosts within.  I have tried to keep my terminology clear
by context in this discussion, but this is still something to remain
conscious of.

  There are multiple Sendmail configurations involved in this
environment: The Sendmail on PLUTO and the Sendmail on SATURN.  There
is also "Sendmail in the general case".  Because Steven wants
different behavior on different hosts, we will have the Sendmail
configurations on each host behaving differently.  It is thus
essential to maintain awareness of *which* Sendmail is being discussed
at any given point.

  As a result of these complications, this discussion is rather
verbose, even by my standards.  Bear with me, folks.

CAUSE

  This is almost certainly being caused by the presence (on PLUTO) of
<syslang.net> in Sendmail's list of local host names (in terms of
Sendmail internals, the {w} class).  Any Sendmail will consider itself
the destination host for any such name.  If the list contains
<microsoft.com>, Sendmail will consider itself responsible for that
domain, and will attempt local delivery for <billg at microsoft.com>.

  Typically, the local name list contains the system's canonical name
(usually the same as the output of "hostname -f"), along with any
names listed in a "sendmail.cw" or "local-host-names" file (the exact
name and location of the file depends on Sendmail version, distro
config, and local config, but they typically exist under /etc/ or
/etc/mail/).

  SMART_HOST won't affect the local name list, since a smart host is
only used for mail *not* destined for the local system.  Since that
list means "I am the destination host for these names", Sendmail
thinks no further relaying is necessary, and SMART_HOST never gets
involved.

CORRECTION

  Steven tells me Sendmail on PLUTO is configured with
MASQUERADE_AS(`syslang.net').  During the off-list conversation, I had
stated that I suspected doing so put <syslang.net> in the local name
list.  I now believe I was mistaken on that point.  The docs don't say
it does, and the more I think about it, the less that makes sense.

RESOLUTION

  So I now suspect <syslang.net> may be listed in one off the files
mentioned above ("sendmail.cw" or "local-host-names").  Or it may be
that the OS on PLUTO thinks it's fully-qualified host name is
<syslang.net> ("hostname -f" command).  I would advise Steven to check
those.

FURTHER SUGGESTIONS

  Moving on to more general advice toward what the "best" solution is
for Steven.  I suspect masquerading on PLUTO isn't really the "right"
solution for him.

NULL CLIENT

  My first thought is that a null client configuration might be what
Steven really wants.  Configuring Sendmail as a null client causes
Sendmail to just hand *all* mail off to a (specified) host.  That
would be SATURN, in this case.  The advantage would be that Steven
would only have to worry about mail administration on SATURN.  Mail on
PLUTO becomes uninteresting.

  However, Steven also tells me that he would like root's mail on
PLUTO to deliver locally.  Because a null client is such a minimal
configuration, you cannot make exceptions.  Sendmail doesn't do any
interpretation at all; it just passes everything on to the specified
host.  So the null client idea is out.

LOCAL RELAY

  My next idea is that, since Steven wants *almost* all mail routed
though SATURN, is that on PLUTO, he should define SMART_HOST and
LOCAL_RELAY (both targeting SATURN), omit the masquerading directives
on PLUTO entirely, and define LOCAL_USER(`root').  That should result
in just about all mail being relayed though SATURN.  Mail to root
would still deliver locally.  Any mail explicitly addressed to
<somebody at pluto> would also deliver locally, but presumably that's
intended, since it was asked for.

  (I believe one can additionally override that last behavior by
setting FEATURE(`stickyhost') and defining MAIL_HUB to be SATURN as
well.  But I'm not positive LOCAL_USER overrides MAIL_HUB in that
case.  Testing would be needed.)

  Then, on SATURN, define MASQUERADE_AS(`syslang.net') and
FEATURE(`masquerade_entire_domain').  That will cause SATURN to do
"From" address rewriting for mail passing through it from Steven's
domain, including mail from PLUTO.  This simplifies things and reduces
confusion by doing all the address rewriting on a single host.

  Steven may also need MASQUERADE_DOMAIN(`pluto') or similar on
SATURN, if PLUTO is not identified on Steven's local network as being
a child of the <syslang.net> domain.  In other words, if PLUTO
identifies as simply <pluto> or <pluto.localdomain> or whatever.
Otherwise, Sendmail on SATURN would not see mail from PLUTO as being
in the "entire domain".

  Steven will likely also need FEATURE(`masquerade_envelope') on
SATURN.  By default, Sendmail only masquerades the address in the
"From:" header of the message payload.  The SMTP protocol (the "MAIL
FROM" verb) would still use the from address from Steven's private
network.

AFTERWORD

  *phew*  Hopefully that makes things clearer.  Feel free to post with
additional questions.  And if anyone can clarify further, please do!
:-)

-- Ben