Simple, huh?
Pah!
The default sendmail configuration that comes with CentOS is pretty good. But whilst the FireWall on the server would allow SMTP out the FireWall controlling the DMZ would only allow that SMTP traffic back throught the internal facing FireWall to a specific internal SMTP server. Also since the server is out in the DMZ, not only must the company FireWall "whitelist" every allowed port on each server, but each server must also only whitelist the bare minimum of required ports to function properly. So this server is only listening on http, https, SMTP and SSH.
With all that in mind, I sent a test email:
# echo "Hello, World" | mailx -s "Test" me@company.com
And that worked.
However
# echo "Is there anybody out there?" | mailx -s "Test" me@gmail.com
didn't work.
Although, I wasn't allowing DNS through the FireWall, /etc/resolv.conf contained
search emea.company.com
server 10.10.10.10
(All domain names and IPs are fictitious.)
Changing the resolv.conf file for an empty file will cause the email to me@company.com to fail to relay. It will simply be queued locally. Sendmail is trying to use DNS to look up the MX records of the email recipients. As this server is in the DMZ and we employ a split horizon DNS, this situation can't be resolved by just openning up port 53 on the server FireWall to talk to the external facing DNS server. This server isn't allowed to send email directly to the internet, and it wouldn't be able to relay email to the companies main SMTP servers as they are in a different DMZ and the network routing between the two DMZ is internal.
The DNS lookup needs to be turned off. Reading the documentation, you might think that just defining a SMART_HOST in the sendmail.mc, regenerating sendmail.cf and restarting the sendmail service would be sufficient. But it is not. DNS would still rear its ugly head.
In addition to adding
define(`SMART_HOST',`mailhost.emea.company.com') dnl
to sendmail.mc (and adding an entry for mailhost into /etc/hosts) it is also necessary to add
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`nocanonify')dnl
These two directives tells sendmail to accept email for domains that it cannot resolve and to not to canonify provided email addresses.
Command to generate the sendmail.cf file
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Command to restart Linux Sendmail service
service sendmail restart
Debugging
It is very useful to increase the log level temporarily for debugging purposes. This can be changed in sendmail.mc by changing the value of the following definition
define(`confLOG_LEVEL', `15')The default value is 9. The documentation lists 15 as the maximum for administration with the values of 16 up to 99 being of interest only to developers.
The logfile location is /var/log/maillog
Masquerading
There was an additional problem. An upstream SMTP server at our Data centre provider was performing a reserve lookup up on the originating relay server. Our SLA with the external company only allowed us to utilize specific sub-domains, and emea.company.com wasn't one of them. It was necessary to configure masquerading, too.
The following settings were added to sendmail.mc:
FEATURE(always_add_domain)dnl
MASQUERADE_AS(`company.com')dnl
MASQUERADE_DOMAIN(`company.com')dnl
FEATURE(masquerade_envelope)dnl
FEATURE(masquerade_entire_domain)dnl
FEATURE(`allmasquerade')dnl
The following feature was also commented out.
dnl EXPOSED_USER(`root')dnl
I was logged in as root when testing! D'Oh!
Resources
The following link provides a good description of sendmail on CentOS 5, but you really have to know a little bit about what you are doing first, otherwise it is confusing: linuxtopia
Another closely related link.
sendmail.org is also a good source of detail, especially on what all those options/FEATURES in the sendmail.mc file are for, and for Masquerading & Relaying.
An excellent HP website on how Sendmail works.
No comments:
Post a Comment