Configuring sendmail (8.11.3) for Smart Host without DNS.
Rick_Hoyle
configuration changes don't seem to be helping.
We need to configure a server running OpenServer 6.0 (mp4) so that it
will utilize an external Smart Host. The resulting sco.osr6.mc looks
like this:
divert(0)dnl
VERSIONID(`@(#)opensrc:src/sendmail/patches/cf/cf/sco.osr6.mc /main/
uw714mp/11')dnl
OSTYPE(sco.osr6)dnl
DOMAIN(generic)dnl
define(`confDONT_BLAME_SENDMAIL',`groupwritabledirpathsafe,linkedaliasfileinwritabledir')dnl
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`use_cw_file')dnl
define(`confDOMAIN_NAME',`mydomain.com')dnl
define(`SMART_HOST',`smart_host')dnl
FEATURE(`masquerade_envelope')dnl
MASQUERADE_AS(`mydomain.com')dnl
MAILER(local)dnl
MAILER(smtp)dnl
As instructed, I've created an /etc/service.switch file:
hosts files
I've modified these entries in the sendmail.cf file:
O ServiceSwitchFile=/etc/service.switch
O HostsFile=/etc/hosts
Symptoms: When I send an email to an external address
("y...@yourdomain.com") it gets placed in /var/spool/clientmqueue and
never moves.
Any help is appreciated. I'm sure there is more information I can
provide if somebody can point me in the right direction.
Thanks!
Nico Kadel-Garcia
> I've reviewed SCO TA # 127087 regarding this topic, but the
> configuration changes don't seem to be helping.
> We need to configure a server running OpenServer 6.0 (mp4) so that it
> will utilize an external Smart Host. The resulting sco.osr6.mc looks
> like this:
>
> divert(0)dnl
> VERSIONID(`@(#)opensrc:src/sendmail/patches/cf/cf/sco.osr6.mc /main/
> uw714mp/11')dnl
> OSTYPE(sco.osr6)dnl
> DOMAIN(generic)dnl
> FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
> FEATURE(`use_cw_file')dnl
> define(`confDOMAIN_NAME',`mydomain.com')dnl
> define(`SMART_HOST',`smart_host')dnl
> FEATURE(`masquerade_envelope')dnl
> MASQUERADE_AS(`mydomain.com')dnl
> MAILER(local)dnl
> MAILER(smtp)dnl
>
> As instructed, I've created an /etc/service.switch file:
> hosts files
>
> I've modified these entries in the sendmail.cf file:
> O ServiceSwitchFile=/etc/service.switch
> O HostsFile=/etc/hosts
>
> Symptoms: When I send an email to an external address
> ("y...@yourdomain.com") it gets placed in /var/spool/clientmqueue and
> never moves.
>
> Any help is appreciated. I'm sure there is more information I can
> provide if somebody can point me in the right direction.
>
> Thanks!
What is this about "without DNS"? Do you mean that your external
smarthost does not have a reiliable DNS name and you're tryiong to
send it to directly to an external IP address without using DNS in any
way? Please provide a little more detail.
Also, if you start muckinc directly with our sendmail.cf file, you are
quite likely to have it overwritten by directives in you senndmail.mc
file. In most sane sendmail setups, you use M4 macros to generate a
sendmail.cf or even a locked down sendmail.fc file from a more legible
sendmail.mc file. Editing sendmail.cf files directly is like editing
object files directly for C aficionados. It is not for the faint of
heart.
Scot Jenkins
I'll assume you replaced smart_host with the actual hostname of the
smart host, e.g.:
define(`SMART_HOST',`mail.example.com')dnl
If you are not using DNS, you would need to have an entry in /etc/hosts
for the smart host, e.g:
1.2.3.4 mail.example.com
Is there a reason you are using /etc/hosts over DNS?
I have a UnixWare system sending mail to a smart host and I never
touched /etc/service.switch. Everything in that file is commented out.
I'm using DNS and things work fine. Generally speaking, DNS is much
preferred over /etc/hosts as host files are a management nightmare.
> Symptoms: When I send an email to an external address
> ("y...@yourdomain.com") it gets placed in /var/spool/clientmqueue and
> never moves.
What happens if you try to flush the client queue manually?
# /usr/lib/sendmail -Ac -q -v
scot
Rick_Hoyle
>
> - Show quoted text -
Nico:
"Without DNS" in my case means that the SCO system doesn't try to
resolve domains itself, but needs to forward all non-local mail to the
"SMART-HOST" and assume it can be resolved and delivered. I don't know
at this point if the Client will need in-bound mail to be handled by
this server. The SMART-HOST is external. There is an entry in the SCO
system's /etc/hosts file for this server. Currently, it is just a
simple name, not a true FQDN:
123.45.67.123 smart_host
The only edits I did to the sendmail.cf were dictated by the above
mentioned TA. I didn't even edit the mc file directly, that is the
result of running "scoadmin sendmail".
Scot:
When I try to flush that directory using your command, I get an error
which basically states that the server is unable to resolve the
destination domain. That's what I'm trying to get around. Do I need to
have a nameserver defined in the /etc/resolv.conf file?
Thanks to both for taking the time to help.
Scot Jenkins
> The only edits I did to the sendmail.cf were dictated by the above
> mentioned TA. I didn't even edit the mc file directly, that is the
> result of running "scoadmin sendmail".
As Nico suggested, avoid editing the sendmail.cf file directly. It is
best to create/edit a sendmail.mc file, then use m4 to regenerate the
.cf file(s) [files: sendmail.cf, submit.cf]. There is usually a
provided Makefile in /etc/mail (just type "make" in that directory) that
will call m4 to generate the .cf files from the .mc files. The m4
syntax is easy to learn and once you have .mc file(s), sendmail upgrades
are much easier.
I would ignore the info in that SCO TA about editing sendmail.cf. Just
run "scoadmin sendmail" and let it build your config.
> When I try to flush that directory using your command, I get an error
> which basically states that the server is unable to resolve the
> destination domain. That's what I'm trying to get around. Do I need to
> have a nameserver defined in the /etc/resolv.conf file?
I would definitely put a DNS server or two in /etc/resolv.conf. Doing
so allows other things to work on your SCO system, for example NTP to
keep the host's clock in sync. SSH can be troublesome without working
DNS. You would also be able to use commands like nslookup for
troubleshooting. Working DNS is critical. You don't necessarily need
to run your own DNS server, you can just point to your ISP's nameservers
or whatever public nameservers the client's site is using. If the smart
host is resolvable via DNS, you won't have to add it to /etc/hosts either.
Because you specified a smart host in the sendmail config, sendmail will
forward all outbound mail to the smart host for delivery. You can
verify this by sending a test message from the SCO box to an external
address, then view the full message headers in your mail client once the
message has been received, e.g.:
scobox$ echo "test message" | mailx -s "SCO box test" y...@example.com
You should see "Received:" lines in the headers showing the message went
from the SCO box to the smart host and then on to it's final
destination. Read the headers from the bottom up to see where the
message is going.
scot
Nico Kadel-Garcia
> Rick_Hoyle wrote:
> > The only edits I did to the sendmail.cf were dictated by the above
> > mentioned TA. I didn't even edit the mc file directly, that is the
> > result of running "scoadmin sendmail".
>
> As Nico suggested, avoid editing the sendmail.cf file directly. It is
> best to create/edit a sendmail.mc file, then use m4 to regenerate the
> .cf file(s) [files: sendmail.cf, submit.cf]. There is usually a
> provided Makefile in /etc/mail (just type "make" in that directory) that
> will call m4 to generate the .cf files from the .mc files. The m4
> syntax is easy to learn and once you have .mc file(s), sendmail upgrades
> are much easier.
>
> I would ignore the info in that SCO TA about editing sendmail.cf. Just
> run "scoadmin sendmail" and let it build your config.
Amen. Editing sendmail.cf directly is only workable when you disable
sendmail.mc, or disable the m4 macro tools that come with sendmail.
I'm not saying that this particular SCO release hasn't done so, but if
it has, I'd like to slap the fingers of the engineer that did it.
> > When I try to flush that directory using your command, I get an error
> > which basically states that the server is unable to resolve the
> > destination domain. That's what I'm trying to get around. Do I need to
> > have a nameserver defined in the /etc/resolv.conf file?
>
> I would definitely put a DNS server or two in /etc/resolv.conf. Doing
> so allows other things to work on your SCO system, for example NTP to
> keep the host's clock in sync. SSH can be troublesome without working
> DNS. You would also be able to use commands like nslookup for
> troubleshooting. Working DNS is critical. You don't necessarily need
> to run your own DNS server, you can just point to your ISP's nameservers
> or whatever public nameservers the client's site is using. If the smart
> host is resolvable via DNS, you won't have to add it to /etc/hosts either.
Oh, gods, yes. Also, in many configurations, your "smarthost" record
in DNS is actually not an A recored, meaning a hostname tied to an IP
address, but rather is an MX record with multipls entries. That's a
special record just for email, that has rankings of different mail
servers for a hostname or domain, and says "try the one with the
lowest rank first, then the second, then the third, and only if you've
tried all of them do you start bouncing mails as undeliverable".
Unfortunately, in many situations, your upstream "smarthost" provider
refuses to publish such a record for your target. That's becasue they
sometimes want you, their client, to send mail to their internal mail
server, grant permission to do so, but don't want every spamming twit
in the outside world hammering it directly. This can be a real savior
for a business client with critical email. In such cases, they'll
point you directly to an allocated IP address or a hostname. But if
your DNS setup doesn't point to their internal DNS servers and get
internal DNS from them, you won't be able to look it up.
This is all classic mail configuration work. The O'Reilly book on
Sendmail covers it, and has considerable depth on the "smarthost"
configurations. If you're curious, perhaps you could borrow a copy.
> Because you specified a smart host in the sendmail config, sendmail will
> forward all outbound mail to the smart host for delivery. You can
> verify this by sending a test message from the SCO box to an external
> address, then view the full message headers in your mail client once the
> message has been received, e.g.:
*No, it won't*. This is a common misperception, one I've run into
headlong again and again. It will deliver mail to "user@hostname" to
the smarthost, but unless you've got .forward or aliases set up to
redirect local mail, mail to "user" will still get delivered to the
local host's mail spool. That's a long standing problem for people who
set up a cronjob or some little script that says "myprogram | mail
myusername -s 'Subject'". It winds up in the local spool. This is an
old, old issue with sendmail.
One solution is to make sure to monitor for files accumulating in /var/
spool/mail/ or the OpenServer configuration equivalent: those still
have to be split apart and resent when the problem is straightened
out, which is pesky. The more complete solution is to use Postfix,
which will forward everything but ignores local .forward or /etc/
aliases, or Exim, which can do all of it very nicely and of which I am
now very fond. (Haven't tried to port it to OpenServer, though.)
> scobox$ echo "test message" | mailx -s "SCO box test" y...@example.com
>
> You should see "Received:" lines in the headers showing the message went
> from the SCO box to the smart host and then on to it's final
> destination. Read the headers from the bottom up to see where the
> message is going.
>
> scot
And if you can manage or get permission to do so, please post your
headers or the failure messages here unedited. It's sometimes
difficult to unweave even the reports of a competent engineer or
admin, like yourself, from the obscuration they have to do to protect
their own sites.
Perhaps you can relace all the external IP addresses with
"192.168.x.y" addresses and external ones with "10.x.y.z" addresses,
and the hostnames with "example.com" and "example.tld" hostnames, just
to retain your privacy?
Nico Kadel-Garcia
> Nico:
> "Without DNS" in my case means that the SCO system doesn't try to
> resolve domains itself, but needs to forward all non-local mail to the
> "SMART-HOST" and assume it can be resolved and delivered. I don't know
> at this point if the Client will need in-bound mail to be handled by
> this server. The SMART-HOST is external. There is an entry in the SCO
> system's /etc/hosts file for this server. Currently, it is just a
> simple name, not a true FQDN:
> 123.45.67.123 smart_host
Never do this. Always, always, always put in the FQDN as the first
text entry, and use the FQDN in your sendmail.mc.
Sendmail is really picky about trying to resolve fully qualified
hostnames, for lots of reasons, and will assume that "smart_host" has
the domain of whatever your own host is. Similarly, you should take a
look at your own host's name in /etc/hosts, and ideally assure that
your own host's name is listed with its FQDN first
123.45.67.124 myhost.example.com myhost
There are occasionally legacy software or configuration reasons to
have your hostnames not be fully qualified in /etc/hosts, but they are
generally wrong, wrong, wrong, wrong. And did I mention wrong? I've
been slamming headlong into that one for almost 20 years as an
engineer.
> The only edits I did to the sendmail.cf were dictated by the above
> mentioned TA. I didn't even edit the mc file directly, that is the
> result of running "scoadmin sendmail".
Yeah, scoadmin is a fascinating tool that should be mostly avoided for
any sensitive configurations of third-party software such as sendmail
if you can do so. This is particularly true if you've built and
replaced sendmail yourself, which can be desirable for lots of reasons
(mostly if you're running a mailserver exposed to the Internet).
The problem here is that I don't personally have a box to try
manipulating scoadmin on for you. It may be that scoadmin is doing its
own replacements for sendmail's standard m4 macros, in which case all
bets are off.
> Scot:
> When I try to flush that directory using your command, I get an error
> which basically states that the server is unable to resolve the
> destination domain. That's what I'm trying to get around. Do I need to
> have a nameserver defined in the /etc/resolv.conf file?
>
> Thanks to both for taking the time to help.-
In general, you should *always* have *something* listed for valid DNS
in your /etc/resolv.colnf, unless you're setting up your hosts inside
a network clean room environment and don't want them to reach out for
anything. In that case, you want to think hard about letting them
reach out even to send email, but you say that's already in your
configuraiton plans, so that seems cool.
You could list the target smarthost's IP address directly, instead of
listing it by name. But some mailservers won't accept or, in this case
for a smarthost, relay email sent from outside directly to their IP
address. Or be sure to list your smarthost's fully qualified hostname
in both sendmail.mc and /etc/hosts. Sendmail is *really picky* about
this.
Rick_Hoyle
You guys are pretty awesome. I added a couple of generic DNS entries
in /etc/resolv.conf (and also changed my smart_host entry in /etc/
hosts and sendmail.cf to a FQDN). Restarted sendmail and it seems to
be working.
The reason we typically don't have a "working" resolv conf file is
that there was an issue in the past where the login process would hang
for nearly a minute because the SCO system was trying to validate the
incoming PC's IP/FQDN before presenting the login prompt. For local
PC's on the LAN, this meant we had to have entries for each in /etc/
hosts. But, if we just renamed "resolv.conf", the connections were
immediate. And, since most of our Client systems didn't need external
connectivty (no sendmail), this was a quick fix.
All is good for now. I might come back to this thread if a problem
crops up next week.
Happy New Year to all!
Nico Kadel-Garcia
Oh, dear lord. Is the the SSH reverse DNS problem, where it's logging
the reverse DNS of the IP address? That one's *easy*, though obscure,
and is a long-standing issue with SSH and OpenSSH. It can't be turned
off in sshd_config, but you can modify your SSH init script to use the
option '-u 0'. This sets the "maximum length of hostname in reverse
DNS lookups" to 0, and causes it to actually skip the reverse DNS
step. This is very useful in the sort of environment you describe.