--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Recently Changed Pages:

View All Pages

View All Tags


WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.

Pages with comments

View All Comments


Sendmail Security Quick Fixes

As one of the most enduring Unix applications and one of the most ubiquitous, sendmail has been the target of numerous attacks over the years – from buffer overflows to denials of service. And, even with constantly improved security, sendmail can be prodded into a state of improved security through a number of quick fixes that any sysadmin can make to reduce the vulnerability of their sendmail servers.

Less Identification

One way to reduce the exposure of a sendmail server is to remove any evidence of the particular release of sendmail that you are running from the sendmail greeting. While this obviously doesn't change anything about the security of the software you are running, it makes it less likely that anyone wishing to exploit a release-specific attack from targeting your system.

To remove the version information from the sendmail greeting, all you need to do is remove the “$v/$Z” string from this line in your /etc/mail/ file:

# SMTP initial login message (old $e macro)

O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

In fact, you might consider removing the word “sendmail” as well, making the greeting even more non-descript:

# SMTP initial login message (old $e macro)

O SmtpGreetingMessage=$j mailserver; $b

When you make this change and restart sendmail, your greeting, which might have previously looked like this:

220 ESMTP Sendmail 8.13.3/8.13.3; Thu, 3 Mar 2005 15:52:37 -0500 (EST)

will look like this instead:

220 ESMTP mailserver; Thu, 3 Mar 2005 15:52:37 -0500 (EST)

More Limits

You can also reduce your vulnerability to spammers and certain denial of service attacks by putting upper bounds on the size of messages you are willing to process and the number of recipients for any particular piece of email.

You can set a maximum message size by both uncommenting and setting an upper limit on the MaxMessageSize parameter. These lines in your file:

# maximum message size

#O MaxMessageSize=0

would be changed to look like those shown below. Be sure to consider attachments and select a limit which is appropriate to your site. The MaxMessageSize parameter is expressed in bytes.

# maximum message size

O MaxMessageSize=500000

Similarly, the MaxRecipientsPerMessage parameter can be set in these lines:

# maximum number of recipients per SMTP envelope

#O MaxRecipientsPerMessage=0

The modified lines might look like these:

# maximum number of recipients per SMTP envelope

O MaxRecipientsPerMessage=10

Better Privacy

Other easy changes involve the privacy options that sendmail uses. If you don't want anyone probing your mail server to be able to obtain information about your mail recipients, you can change your settings from the default:

# privacy flags

O PrivacyOptions=authwarnings

to the more restrictive settings:

# privacy flags

O PrivacyOptions=goaway,restrictmailq,restrictqrun

The “goaway” setting expands to “authwarnings, noexpn, novrfy, needmailhelo, needexpnhelo, needvrfyhelo”. That's a lot of settings for one 6-letter word. Some don't actually enhance privacy, but simply require that clients issue the HELO command before issuing other commands or add extra headers to guard against spoofing.

The goaway setting essentially disallows SMTP status queries. In particular, it denies use of the VRFY and EXPN commands. Here is a brief explanation of each of these privacy settings:

  • authwarnings
    • Put X-Authentication-Warning headers in messages
  • needmailhelo
    • Insist on HELO or EHLO command before MAIL
  • needexpnhelo
    • Insist on HELO or EHLO command before EXPN
  • noexpn
    • Disallow EXPN entirely
  • needvrfyhelo
    • Insist on HELO or EHLO command before VRFY
  • novrfy
    • Disallow VRFY entirely

The needmailhelo setting, for example, will not allow a client to begin the exchange of message data without first issuing the HELO command:

# telnet localhost 25
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.
220 ESMTP mailserver; Thu, 3 Mar 2005 11:13:45 -0500 (EST)
mail from:
503 5.0.0 Polite people say HELO first

The vrfy command causes sendmail to verify whether it will accept the presented email address. The expn command is similar, but will also expose the list of members if the address is a mutiple-user alias. The novrfy and noexpn options squelch these commands, preventing anyone from communicating with your mail servers to determine the identities of your users.

When noexpn is used, for example, an expn request will result in a response like that shown below:

expn henrystocker

502 5.7.0 Sorry, we do not allow this operation

The two additional privacy options included in the privacy flags suggested above (this particular set is often selected as shown) further limit the information that sendmail is willing to divulge:

restrictmailq Restrict mailq command

restrictqrun Restrict -q command line flag


The changes described above are all easy fixes because you don't have to rebuild sendmail in order to use them. Simply edit your file and then restart sendmail. There are many other ways in which sendmail security can be enhanced and its resistance to spam greatly improved.

You could leave a comment if you were logged in.
sendmailsecurity.txt · Last modified: 2021/09/24 00:25 (external edit)