turning sendmail VRFY off

 Mail, Security  Add comments
Aug 082000
 

turning sendmail VRFY off

A few days ago, I found the following entries in my mail logs.  The email addresses have been changed, because I can. 
sendmail[35274]: NOQUEUE:
sdsl-216-34-236-194.dsl.lax.megapath.net [216.34.236.194]: VRFY
<someuser@example.org>

sendmail[35275]: NOQUEUE:
sdsl-216-34-236-194.dsl.lax.megapath.net [216.34.236.194]: VRFY
IntentionallyInvalidUzer

This appears, at face value, to be someone running a script to see whether or not my mail server accepts the VRFY command.  This SMTP command verifies whether or not a particular email address is valid.  When the SMTP protocol was created, the Internet was quite a friendly place.  VRFY was a convenient method of verifying an email address.  Increasingly, people are taking the view that such information should not be given out as a matter of security.

My testing

I wanted to see what the above produced.  I did the following from a friend’s box.  Again, the domain names have been changed, because I can. 
$ telnet example.org 25
Trying aa.bb.cc.dd...
Connected to example.org.
Escape character is '^]'.
220 host.example.org ESMTP Sendmail 8.9.3/8.9.3; Sun, 
                          6 Aug 2000 17:43:58 +1200 (NZST)
VRFY <someuser@example.org>
250 <someuser@host.example.org>
VRFY IntentionallyInvalidUzer
550 IntentionallyInvalidUzer... User unknown
quit
221 host.example.org closing connection
Connection closed by foreign host.

As you can see, this person was trying to verify the existence of a particular email address.  That’s not something I prefer to allow.  These people are basically anonymous.  If they want to send me email, let them send me email.  I’ll have no guessing which addresses work and then testing them.

The changes

I talked to some people I know.  They suggested making a few changes to my /etc/mail/sendmail.cf file (I’m using FreeBSD 4.0-STABLE).  To make it blatantly obvious, I’ve put my additions in bold.

Before:

# privacy flags                              
O PrivacyOptions=authwarnings

After:

# privacy flags
O PrivacyOptions=authwarnings,goaway,restrictmailq,restrictqrun

Then I HUP’d sendmail to ensure it takes heed of the new configuration:

killall -hup sendmail

Here is a short description of these options, as stolen from p733 of the Sendmail book, 2nd Edition, from O’Reilly:

  • goaway – A shorthand way to set all of authwarnings, noexpn, novrfy, needmailhelo, needexpnhelo, needvrfyhelo.
  • noexpen – Disallows all EXPN commands.
  • novrfy – Disallows all VRFY commands.
  • needmailhelo – Ensure that sending site uses the HELO command first when sending mail.
  • needexpnhelo –  Ensure that sending site uses the HELO command first when using the EXPN command..
  • restrictmailq – prevent others from using the mailq command to view the contents.
  • restructqrun – stop others from processing the queue.

For more information on these options and the commands they affect, you should read the sendmail documentation.

Final testing

I then went back to my friends site and tried my tests again: 
$ telnet example.org 25
Trying aa.bb.cc.dd...
Connected to example.org.
Escape character is '^]'.
220 host.example.org ESMTP Sendmail 8.9.3/8.9.3; Sun, 
                          6 Aug 2000 17:43:58 +1200 (NZST)
VRFY <someuser@example.org>
252 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
VRFY IntentionallyInvalidUzer
252 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
quit
221 host.example.org closing connection
Connection closed by foreign host.

That seems to be working.

Something to consider

John Straiton wrote in to mention these items:

Just a quick note about your recent article on turning VRFY off in sendmail. I checked over the sendmail page (733) that you describe on the use of "goaway", and concurr that it seems that it only sets those directives you mention in the article, however it also seems to disable the ETRN command. This probably isn’t an issue to normal users but those of us who use FreeBSD in the ISP world may be providing that service to thier users because it allows the ISP to hold mail for the end user until they are available to recieve the message.

You can verify my findings by simply removing the goaway from the PrivacyOptions and replacing it with the individual directives, authwarnings, noexpn, novrfy, needmailhelo, needexpnhelo,& needvrfyhelo. Connecting to freebsddiary.org’s mailserver with a EHLO (as opposed to HELO) also shows the command is not in the 250 list as it would be if you connect to my server 209.198.22.7 In replacing goaway with the individual directives you retain the disabled VRFY but re-enable the ETRN functionality.