UNIX System Administration Handbook - Evi Nemeth [359]
cskwam.mil.pl" (checking ip) [show] cskwam.mil.pl not 148.81.119.2,
discarded as fake.
"nslookup sun1.cskwam.mil.pl" (checking ip) [show] ip = 148.81.119.2
Taking name from IP...
"nslookup 148.81.119.2" (getting name) [show] 148.81.119.2 =
sun1.cskwam.mil.pl
"nslookup sun1.cskwam.mil.pl" (checking ip) [show] ip = 148.81.119.2
"nslookup 2.119.81.148.rbl.maps.vix.com." (checking ip) [show] not found
"nslookup 2.119.81.148.relays.orbs.org." (checking ip) [show] ip = 127.0.0.2
blocked by ORBS
Chain test:mail1.es.net =? mail1.es.net
Chain verified mail1.es.net = mail1.es.net
148.81.119.2 has already been sent to ORBS
Received line accepted
Each of the [show] words are links on SpamCop’s web page. They show you the actual command that was executed and its output.
19.11 SECURITY AND SENDMAIL
With the explosive growth of the Internet, programs such as sendmail that accept arbitrary user-supplied input and deliver it to local users, files, or shells have frequently provided an avenue of attack for hackers. sendmail, along with DNS and even IP, is flirting with authentication and encryption as a built-in solution to some of these fundamental security issues.
Recent softening of the export laws of the United States regarding encryption has allowed sendmail to be shipped with built-in hooks for encryption. Versions 8.11 and later support both SMTP authentication and encryption with SSL, the Secure Socket Layer, which is also called TLS for Transport Layer Security. sendmail uses the term TLS in this context and has implemented it as an extension, STARTTLS, to the SMTP protocol. TLS brought with it six new configuration options for certificate files and key files. New actions for access database matches can require that authentication must have succeeded.
In this section, we describe the evolution of sendmail’s permissions model, ownerships, and privacy protection. We then briefly discuss SASL, the Simple Authentication and Security Layer, and its use with sendmail.
sendmail has gradually tightened up its security over time, and it is now very picky about file permissions before it believes the contents of, say, a .forward or aliases file. Although this tightening of security has generally been welcome, it’s sometimes necessary to relax the tough new policies. To this end, sendmail has introduced the DontBlameSendmail option, so named in hopes that the name will suggest to sysadmins that what they are doing is considered unsafe.
This option has many possible values. The default is safe. For a complete list of values, see sendmail/conf.c; they are not listed in the second edition of the O’Reilly sendmail book, but will surely be in the third. Or, just leave the option set to safe.
Ownerships
Three user accounts are important in the sendmail universe: the DefaultUser, the TrustedUser, and the RunAsUser.
By default, all of sendmail’s mailers run as the DefaultUser unless the mailer’s flags specify otherwise. If a user “mailnull” or “sendmail” exists in the /etc/passwd file, DefaultUser will be that. Otherwise, it defaults to UID 1 and GID 1, which is usually “daemon”. We recommend the use of the “mailnull” account. Add it to /etc/passwd with a star as the password, no valid shell, no home directory, and a default group of “nogroup”. The mailnull account should not own any files.
sendmail’s TrustedUser can own maps and alias files. The TrustedUser is allowed to start the daemon or rebuild the aliases file. The TrustedUser is different from the sendmail class called TRUSTED_USERS, which determines who can rewrite the From line of messages.24
The RunAsUser is the UID that sendmail runs under after opening its socket connection to port 25. Ports numbered less than 1,024 can only be opened by the superuser; therefore, sendmail must initially run as root. However, after performing this operation, sendmail can switch to a different UID. Such a switch reduces the risk of damage or access if sendmail is tricked into doing something bad.
By default, sendmail