Sendmail configuration (email configuration in general in fact), is certainly a minefield. It may look like an easy field to cross, but if you're unlucky enough to step off the path, things can get complicated pretty fast.
One area where things can get a little sticky is where you have no DNS in your environment, so your servers cannot lookup where to send mail to. This is actually very easy to work around. One server still needs to be able to send email - sensibly you'd place this beyond a firewall in a DMZ, if that's appropriate - and the other servers need to be configured to send mail here. This can be done by locating the line in sendmail.cf "DS" and adding the name of the mail hub after it - e.g. "DSmy.mail.hub". Reload sendmail and you're away. Obviously, with DNS not present in the environment, you prevent your system from doing DNS lookups. However, there's another situation which is a little more complex.
I was recently asked to look at a production environment where mail had suddenly stopped being sent. This environment had been configured as above, and previously was sending mail without problem. However, an internal DNS service had just been implemented. This DNS service had no knowledge of the outside world. This did not prevent sendmail from attempting to do DNS lookups of any mail recipient it was asked to send to. It didn't attempt to use the mail hub and simply queued the messages until such time that DNS would be able to tell it how to send the mail. (Probably there is a way to configure DNS to always return an MX record of the mail hub, but that's not what I'm going to do to fix this here)The internet has quite a few answers for how to configure sendmail for this, but all are based on using m4 to compile a new sendmail.cf (using m4 is described here). If you're wary of using m4, the following sendmail.cf can be dropped in place (the V configuration level at the top can be modified for your own vendor, and you may be able to reduce the sendmail version number from 10 down to V8.6 / V8.1 or even lower, but I can't promise it'll work).
V10/Sun
# custom sendmail.cf
# Philip Harries
#
# This sendmail.cf will send all emails to the mail hub without a dns lookup
#
# Defined macros
D{REMOTE}<your mail hub here> # the name used for the mail hub
# Delivery agent definition to forward mail to hub
Mhub, P=[IPC], S=0, R=0, F=mDFMuXa, T=DNS/RFC822/SMTP, A=TCP $h
Mlocal, P=/usr/lib/mail.local, F=lsDFM5qPSXmnz9, S=0, R=0, T=DNS/RFC822/SMTP, A=mail.local -l
S0
R$+ $#hub $@${REMOTE} $:$1 forward to hub
S1 # Generic sender rewrite (defined but unused)
S3 # preprocessing for all rule sets
R$* <> $* $n handle <> error address
R$* < $* < $* > $* > $* $2<$3>$4 de-nest brackets
R$* < $* > $* $2 basic RFC822 parsing
O QueueDirectory=/var/spool/mqueue
Finally, you should copy this as your submit.cf as well (or link it):
mv submit.cf old.submit.cf
ln -s sendmail.cf submit.cf
One area where things can get a little sticky is where you have no DNS in your environment, so your servers cannot lookup where to send mail to. This is actually very easy to work around. One server still needs to be able to send email - sensibly you'd place this beyond a firewall in a DMZ, if that's appropriate - and the other servers need to be configured to send mail here. This can be done by locating the line in sendmail.cf "DS" and adding the name of the mail hub after it - e.g. "DSmy.mail.hub". Reload sendmail and you're away. Obviously, with DNS not present in the environment, you prevent your system from doing DNS lookups. However, there's another situation which is a little more complex.
I was recently asked to look at a production environment where mail had suddenly stopped being sent. This environment had been configured as above, and previously was sending mail without problem. However, an internal DNS service had just been implemented. This DNS service had no knowledge of the outside world. This did not prevent sendmail from attempting to do DNS lookups of any mail recipient it was asked to send to. It didn't attempt to use the mail hub and simply queued the messages until such time that DNS would be able to tell it how to send the mail. (Probably there is a way to configure DNS to always return an MX record of the mail hub, but that's not what I'm going to do to fix this here)The internet has quite a few answers for how to configure sendmail for this, but all are based on using m4 to compile a new sendmail.cf (using m4 is described here). If you're wary of using m4, the following sendmail.cf can be dropped in place (the V configuration level at the top can be modified for your own vendor, and you may be able to reduce the sendmail version number from 10 down to V8.6 / V8.1 or even lower, but I can't promise it'll work).
V10/Sun
# custom sendmail.cf
# Philip Harries
#
# This sendmail.cf will send all emails to the mail hub without a dns lookup
#
# Defined macros
D{REMOTE}<your mail hub here> # the name used for the mail hub
# Delivery agent definition to forward mail to hub
Mhub, P=[IPC], S=0, R=0, F=mDFMuXa, T=DNS/RFC822/SMTP, A=TCP $h
Mlocal, P=/usr/lib/mail.local, F=lsDFM5qPSXmnz9, S=0, R=0, T=DNS/RFC822/SMTP, A=mail.local -l
S0
R$+ $#hub $@${REMOTE} $:$1 forward to hub
S1 # Generic sender rewrite (defined but unused)
S3 # preprocessing for all rule sets
R$* <> $* $n handle <> error address
R$* < $* < $* > $* > $* $2<$3>$4 de-nest brackets
R$* < $* > $* $2 basic RFC822 parsing
O QueueDirectory=/var/spool/mqueue
Finally, you should copy this as your submit.cf as well (or link it):
mv submit.cf old.submit.cf
ln -s sendmail.cf submit.cf
No comments:
Post a Comment