Although SMTP probes can be legitimate uses of the network, they can also pose potential risks. They are sometimes used to see whether a bug remains unfixed. Sometimes they are used to try to gather user login names or to feed a program unexpected input in such a way that it breaks and gives away root privilege.
An "unfixed bug" probe can use the SMTP 
debug
 and 
showq
 commands. The SMTP 
debug
 command allows the local 
sendmail
 to be placed into debugging mode (as with the 
-d
 command-line switch; see 
Section 37.1, "The Syntax of -d"
) from any other machine anywhere on the network. The SMTP 
showq
 command allows outsiders to view the contents of the mail queue.
If SMTPDEBUG (see Section 18.8.42, SMTPDEBUG ) is defined when sendmail is compiled, the SMTP debug and showq commands are allowed to work; otherwise, they are disabled. SMTPDEBUG should be defined only when modifying the sendmail code and testing a new version. It should never be defined in an official release of sendmail . To see whether it has been defined at your site, run the following command:
%telnet localhost 25Trying 123.45.6.7 ... Connected to localhost. Escape character is '^]'. 220 localhost sendmail 8.8.4 ready at Fri, 13 Dec 1996 06:36:12 -0800debug500 Command unrecognizedquit221 localhost.us.edu closing connection Connection closed by foreign host. %
When connected, enter the command 
debug
. If you get the answer 
500 Command unrecognized
, you know that SMTPDEBUG is not enabled. If, on the other hand, you get the answer 
200 Debug set
, SMTPDEBUG is defined on your system, and you should immediately take steps to correct the situation. Either contact your vendor and request a new version of 
sendmail
, or get the 
sendmail
 source and compile it with SMTPDEBUG undefined.
When SMTPDEBUG is undefined and an outsider connects to the local machine and attempts to execute the 
debug
 or  
showq
 commands, 
sendmail
 will 
syslog
(3) a message like the following:
Jul 22 07:09:00 here.domain sendmail[192]: "debug" command from there.domain (123.45.67.89)
This message shows the name of the machine that attempts the probe, or  (
there.domain
), and the IP address of that machine. Note that this message is logged only if the 
LogLevel
 (
L
) option (see 
Section 34.8.33, LogLevel (L)
) is nonzero.
You may be dismayed to learn that the login names of ordinary users can be used to break into a system. It is not, for example, all that unusual for a user to select a password that is simply a copy of his or her login name, first name, last name, or some combination of initials.  A risk of attack can arise from outsiders guessing login names. Any that they find can be used to try to break in, and the SMTP 
vrfy
 gives an attacker the means to discover login names.
The SMTP 
vrfy
 command causes 
sendmail
 to verify that it will accept an address for delivery. If a user's login name is given, the full name and login name are printed:
vrfy george250 George Washington <[email protected]>
Here, the 250 SMTP reply code (see RFC821) means a successful verification. [7] If the user is unknown, however, sendmail says so:
[7] See the
F=qflag ( Section 30.8.36, F=q ) for a way and reason to change this SMTP reply code to 252.
vrfy foo550 foo... User unknown
The SMTP 
expn
 command is similar to the 
vrfy
 command, except that in the case of a mailing list, it will show all the members of that list. The SMTP 
expn
 command causes 
sendmail
 to expand (show all the recipients) of an address. To illustrate the risk, consider that many sites have aliases that include all or a large segment of users. Such aliases often have easily guessed names, such as 
all
, 
everyone
, or 
staff
. A probe of 
all
, for example, might produce something like the following:
expn all250-George Washington <[email protected]> 250-Thomas Jefferson <[email protected]> 250-Ben Franklin <[email protected]> 250-Betsy Ross <[email protected]> 250 John Q. Public <[email protected]>
With well-designed passwords these full and login names can safely be given to the world at large. But if one user (say 
jqp
) has a poorly designed password (such as 
jqpublic
), your site's security can easily be compromised. [8] Note that not all uses of 
vrfy
 or 
expn
 represent probes. Some MUAs, [9] for example,  routinely 
vrfy
 each recipient before sending a message.
[8] The fingerd (8) utility can also reveal login IDs.
[9] The GNU fingerd (8) daemon also uses
vrfyto provide mailbox information.
SMTP 
vrfy
 and 
expn
 commands are individually logged in a form like one of the following:
Sep 22 11:40:43 yourhost sendmail[pid]: other.host: vrfy all Sep 22 11:40:43 yourhost sendmail[pid]: [222.33.44.55]: vrfy all Sep 22 11:40:43 yourhost sendmail[pid]: other.host: expn all Sep 22 11:40:43 yourhost sendmail[pid]: [222.33.44.55]: expn all
This shows that someone from the outside (
other.host
 in the first and third examples) attempted to probe for usernames in the mailing list named 
all
. In the second and last examples the probing hostname could not be found, so the IP address is printed instead (in the square brackets). Note that this form of logging is enabled only if the 
LogLevel
 (
L
) option (see 
Section 34.8.33
) is greater than 5.
Pre-V8 versions of 
sendmail
 do not report SMTP 
vrfy
 or 
expn
 attempts at all. Some versions of 
sendmail
 (such as the HP_UX version) appear to verify but really only echo the address stated.
V8 
sendmail
 allows 
vrfy
 and 
expn
 services to be selectively accepted or rejected on the basis of the setting of the  
PrivacyOptions
 (
p
) option (see 
Section 34.8.47, PrivacyOptions (p)
). For best security we recommend this setting:
O PrivacyOptions=goaway