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.