View user information (who am i):
# sendmail -d0 < /dev/null
View sendmail queue
# sendmail -bp
View comprehensive sendmail settings (current):
# sendmail -d < /dev/null
View MX record of DNS domain:
$ dig mydomain.com mx
Follow a mail message using:
$ sendmail -v
Process que (send mail in que)
# sendmail -qf
If sendmail delays when starting, it is most likely looking for your
fully qualified domain name. Make sure you have it placed in the
/etc/hosts file. The fully qualified domain name must come before the
host name.
#/etc/hosts:
w.x.y.z hostname1.domain.com hostname1
w.x.y.z hostname2.domain.com hostname2
Cw domain.net
The sendmail application is responsible for moving email on the system.
It is not designed for direct user interaction (use pine or mail for sending
email).
The most common administrative tasks with sendmail is setting up who can
and cannot use the system. There are also many levels of usage for different
domains. Once sendmail is configured or re-configured, itmust be restarted.
To restart sendmail, use the following command:
% sendmail restart
OR
% /etc/rc.d/init.d/sendmail restart
OR
% kill `head -1 /etc/sendmail.pid`
% sh -c "`tail -1 /etc/sendmail.pid`"
/etc/mail/access
The file /etc/mail/access is used to setup the permissions
for domains contacting the system. This file is then compiled into a
database for sendmail to reference.
Keys can be a fully or partly qualified host or domain name such as
host.subdomain.domain.com, subdomain.domain.com, or domain.com. The last
two forms match any host or subdomain under the specified domain. (If
FEATURE(relay_hosts_only) was set when you generated your sendmail.cf, only
the first form works.) Keys can also be a network address or subnetwork,
e.g., 205.199.2.250, 205.199.2, or 205.199. The latter two forms match any
host in the indicated subnetwork. Lastly, keys can be user@host.domain to
reject mail from a specific user.
The following permission rights are used to setup network access
parameters:
RELAY - Allow users from domain.com to relay mail.
OK - Allow users from domain.com to deliver mail on local machine.
REJECT - Refuse connections from host.
DISCARD - Accept message but silently discard it.
500 TEXT - Return error 500 with TEXT as the excuse.
Once the access file is configured properly, you need to convert it into
a the database file access.db. To convert the file, use the hash command:
% makemap hash /etc/mail/access < /etc/mail/access
The following is an example of the /etc/mail/access file:
/etc/mail/access:
yourdomain.com RELAY
otherdomain.com RELAY
domain.com RELAY
domain.com OK
spam.com 500 No Spamming
With newer versions of Sendmail, instead of having to convert the
access file using makemap hash, you can just type the command
"make".
/etc/mail/aliases
You should have a normal user account that you're going to use (never log
in as root! Always use su or sudo). Administrative email should be forwarded
to you; if your normal username is zippy edit /etc/mail/aliases and make sure
you make the appropriate lines look like this:
#/etc/mail/aliases:
# Well-known aliases -- these should be filled in!
root: zippy
manager: zippy
dumper: zippy
/etc/mail/relay-domains
One thing you should consider is being an email handler for friends. My DSL
service goes down too often -- every few months. This is too unreliable for
my tastes. What I do is collaborate with friends to accept and queue email
for them, and they do the same for me. For my domain foo.com the primary
mail exchanger is gateway.foo.com, the OpenBSD firewall/gateway. But a
secondary mail exchanger (which someone out there on the network will use
if my DSL is down) will be gateway.bar.com, and email will wait on that site
until my machine is back on the network. I want to perform the same service
for my friend - if gateway.bar.com is down, I want people to be able to send
my machine the email destined for bar.com.
#/etc/mail/relay-domains (syntax):
.dm.com # Allow relaying for/to any host in dm.com
a.dm.com # Allow relaying for/to a.dm.com and hosts in a.dm.com
10.2 # Allow relaying from all hosts in the IP net 10.2.*.*
#/etc/mail/relay-domains:
bar.com
fubar.org
Now the machine will accept email for bar.com and fubar.org as well as for
itself and then forward the messages on. If the machine it's trying to
forward to is down, it will put them in the queue and keep re-trying for a
while.
Sendmail Protection
The Sendmail application can be configured not allow certain commands within
the SMTP protocol. The HELP command is often disabled along with a few others
which will provide more security.
#/etc/sendmail.cf
# To disable domain and version greeting:
SmtpGreetingMessage=
# To state system requirements and protections:
PrivacyOptions=authwarnings noexpn novrfy needmailhelo noetrn
# To disable the HELP command:
HelpFile=
Sendmail Files
/etc/sendmail.cf
/etc/sendmail.cw
/etc/mail/relay-domains
/etc/mail/relay_allow
# Relay email to these domains:
netzero.net
dyndns.org
mail.com
mailcity.com
/etc/aliases
webmaster: root
sysadmin: root
root: spc
/etc/mail/aliases:
#person to rx root's mail
root: xor@netzero.net
# to update aliases.db:
# % newaliases
Sendmail As The Network Mail Server
The following information is from RedHat linux. It describes the basic
setup procedures for sendmail within a network.
A default sendmail.cf file will be installed in /etc. The default configuration
should work for most SMTP-only sites. It will not work for UUCP sites; you will
need to generate a new sendmail.cf if you need to use UUCP mail transfers. To
generate a new sendmail.cf, you will need to install m4 and the sendmail source
package. Read the README file in the sendmail sources for more details on creating
sendmail configuration files.
One common sendmail configuration is to have a single machine act as a mail
gateway for all the machines on your network. For instance, at Red Hat, Inc.
we have a machine mail.redhat.com that does all our mail. On that machine we
simply need to add the names of machines for which mail.redhat.com will handle
mail to /etc/sendmail.cw. Here is an example:
# sendmail.cw - include all aliases for your machine here.
torgo.redhat.com
poodle.redhat.com
devel.redhat.com
Then on the other machines, torgo, poodle, and devel, we need to edit
/etc/sendmail.cf to ``masquerade'' as mail.redhat.com when sending mail,
and to forward any local mail processing to redhat.com. Find the DH and DM
lines in /etc/sendmail.cf and edit them thusly:
# who I send unqualified names to (null means deliver locally)
DRmail.redhat.com
# who gets all local email traffic
DHmail.redhat.com
# who I masquerade as (null for no masquerading)
DMredhat.com
With this type of configuration, all mail sent will appear as if it were sent
from redhat.com, and any mail sent to torgo.redhat.com or the other hosts will
be delivered to mail.redhat.com.
Please be aware that if you configure your system to masquerade as another any
email sent from your system to your system will be sent to the machine you are
masquerading as. For example, in the above illustration, log files that are
periodically sent to by the cron daemon would be sent to.