Do You Permit SMTP Verify?

John Murdoch asks: "If you're administering a mail server, you are probably familiar with the SMTP VRFY command. I'm very curious to hear from Slashdot readers who are: 1) using mail servers that do not support VRFY (it technically is not mandatory under RFC 821); or 2) use mail servers that support VRFY, but have disabled it. I'd also love to hear from anyone that knows of mail servers that do ugly things if VRFY commands are sent (Microsoft Exchange 5.0, for example, hangs the Internet Mail Service if you send a VRFY for a valid address)." Do folks think that enabling VRFY is a good idea or a potential invasion of their privacy? (Read on..)

"[With the] SMTP VRFY command--you can verify the address of a user on your mail server. For example, if you sent 'VRFY CmdrTaco' to the SMTP server at SlashDot.org you'd get back "250 OK"; if you sent "VRFY CmdrChalupa" you'd probably get back "550 User is a little dog in a fast food commercial for somebody else" or something similar.

Or you would--IF your mail server will respond to VRFY messages.

Why do I want to know? I'm developing an e-commerce registration application for a major vendor to the semiconductor industry. The client produces some extremely dangerous materials, and wants to establish a rigorous authentication process for some systems. (You'd be surprised at how deadly some of the materials your chips are made of really are....) One small part of this is ensuring that the potential customer has a valid e-mail address.

If practically everybody permits (and supports) SMTP VRFY then we'll quietly check the user's address during registration. If a number of servers don't, then we'll resort to other, clunkier methods. (If you're wondering--there is a lot more authentication going on before we let you get anywhere near ordering nasty stuff. This is for a preliminary step in the process)."

No VRFY For Me

[waldoj]

On most of my servers, I've disabled VRFY and EXPN with:

define(`confPRIVACY_FLAGS',`novrfy,noexpn')dnl

(Sendmail, of course.)

It's just weird to permit that. It seems like a potential source of spam -- you know, they could go through a VRFY a few hundred names and build a database.

On the flipside, I've used VRFY to confirm e-mail addresses in forms. If VRFY works, then I flag the address as definitely being legit. I really wish that we had the sort of Internet where we could go on permitting VRFY and EXPN. In fact, if it weren't for spammers, I guess we could.

Oh, well.

-Waldo

qmail doesn't allow VRFY

[calvid]

I like qmail's handling of VRFY:

VRFY [e-mail]
252 send some mail, i'll try my best

I've been using qmail for quite a while with no problem. I wouldn't worry about disabling VRFY.

Dave

VRFY and EXPN

[Logic]

I disable VRFY and EXPN on all mail servers that I administer, although not because of any fear of increased spam. Sendmail's implementation will reveal whether that address is being forwarded elsewhere, and if so, where. This is unacceptable for many uses, as you might not generally want to make the "real" address well known. It's a pretty basic privacy concern.

Re:No VRFY For Me

[Anonymous Coward]

Add "goaway" to PrivacyOptions in sendmail.cf And in postfix main.cf disable_vrfy_command = yes I would also recommend smtpd_helo_required = yes j

Re:No VRFY For Me

[waldoj]

You're right -- I abbreviated my actual privacy flags to make them germane to the discussion. I actually have this:

define(`confPRIVACY_FLAGS',`authwarnings,needmai lhelo,novrfy,noexpn')dnl

-Waldo

VRFY not disabled, but doesn't work as expected

[adaking]

PMDF, a mail service for VMS (and Solaris I think), can be set up to use PH queries to resolve email addresses. That way, you have an easy way to do aliases - just change or add new queries for the server to perform in an attempt to resolve the address. It makes things a lot easier on the sysadmin (especially if that person isn't in charge of maintaining the PH database). These queries create one level of indirection from the actual delivery - the server routes messages between various channels that have been set up to deliver different message types (local, incoming, outgoing, etc), and this query will usually only occur at the final stage of delivery. That means that VRFY will always succeed in this setup, and any message sent to a fake address will only bounce at this final stage. So, don't always trust VRFY. False positives and negatives can result.

I don't know how prevalent such a setup is, but I know of at least one system like this.

RCPT TO: is more reliable, if used correctly.

[XNormal]

RCPT TO: is the most reliable way to verify the existence of an account. It
doesn't always work, but there is a method to verify if it does.

(connect to port 25)
220 mail.example.com ready.
HELO mydomain.com
250 pleased to meet you
MAIL FROM: [e-mail]
250 [e-mail]... Sender ok
RCPT TO: [e-mail]
250 [e-mail]... Recipient ok
RCPT TO: [e-mail]
550 [e-mail]... User unknown
QUIT
221 mail.example.com closing connection

Notes:
1. Always be polite and say HELO. Some servers are rude if you don't.
2. Use a valid domain for the MAIL FROM: line - some servers will look it up.
3. The second RCPT TO: is very important - it lets you find out whether the
server blindly accepts all mail to its domain or actually verifies the user.


----

Don't forget

[Anonymous Coward]

about expand (EXPN) too. EXPN is the VRFY equivalent for aliases. EXPN webmaster, on an (in)appropriately enabled machine will tell you the real address of the webmaster.

I have turned off VRFY and EXPN on all my SMTP servers. Our SMTP proxy (smtpd [obtuse.com] from obtuse.com) also doesn't support VRFY/EXPN.

I consider both commands to be potential security holes, allowing an external h4x0r to determine valid usernames of internal users, and to determine (via EXPN) the username for the webmaster, hostmaster, etc. I don't rely on a h4x0r NOT having that info (security through obscurity), but I don't want to publish the info if possible.

Re:RCPT TO: is more reliable, if used correctly.

[Anonymous Coward]

RCPT TO: is the most reliable way to verify the existence of an account. It doesn't always work

Hmm. A contradiction.

The only reliable way of verifying a user's email address is to send them email at that address, and have them reply to it (or follow a url/link in the email, enter a password, etc.)

Most SMTP proxy servers will accept RCPTs to the site's domain -- it isn't until the proxy server attempts to forward the mail to the internal SMTP server that a bounce message is generated.

identity of the potential customer

[evil_deceiver]

How are you going to determine what the potential customer's mailserver is? You can't just ask him for his e-mail address and then strip the "username@"; a lot of mail services (especially massive, quasi-anonymous ones like Hotmail or Netaddress) don't run SMTP on the machine whose name is after the @ in the address -- if a machine with that name even exists. Many use several mailservers, with each handling a certain category of usernames. Probably this leaves you asking the user what his mailserver is, and from working at a helpdesk I can tell you that most people won't even know what you mean by that. This is all before you even locate the mailserver to find out whether it accepts VRFY/EXPN or not. Sounds like too much trouble to me. IMHO, the best way to go is the time-honored method of mailing a password to the address the user provides and then asking him to log in with that password to continue. This isn't perfect, but is less likely to fail than using VRFY would be -- and more importantly, it's less likely to deny a user access unjustly.

Scare the shit out of us, why dont you :-)

[anticypher]

Put me in category 2 for all mail servers I influence
2) use mail servers that support VRFY, but have disabled it.
Its a good security policy, and many sites don't do VRFY or EXPN.

You even have a good reason to not DoS your potential customers who are clueless enough to be using a non-compliant MTA:
(Microsoft Exchange 5.0, for example, hangs the Internet Mail Service if you send a VRFY for a valid address)."

That should stop you right there.

But the scary part of your question is

The client produces some extremely dangerous materials, (You'd be surprised at how deadly some of the materials your chips are made of really are....)

You mean like silane, arsine and other dopants for silicon? Hydrazine for etching? Hydrofluoric acid for surface cleaning?

I've worked in silicon foundries before, and it was damn difficult to order, transport, store and use those chemicals. There were a ton of laws controlling every part of their existence(of course, there were a lot more patri^H^H^H^H^Hterrorists around where I was). Are you implying your client is now going to ignore the laws requiring them to establish a solid business relationship before ever transporting the chemicals off site? Sounds like a very irresponsible thing to do, probably illegal.

One small part of this is ensuring that the potential customer has a valid e-mail address.
I should hope you are establishing a solid business relationship with any potential customer before allowing them any access to the ordering process. This means face to face meetings, and an inspection of their facilities to meet federal hazmat guidelines. A check for a valid email address is pretty laughable, except for the fact that you might serve some prison time if anything bad ever happens because you shipped a tank of arsene to [e-mail] and it was opened in the air conditioning of the MPAA offices. Hey, do you smell garlic?

If you have to establish a real B2B electronic relationship with your customers, then get some kind of token generators at a minimum. Cryptocards could help to verify a customer trusted enough to fill in an order form. Or a PGP/RSA style signature to ensure the customer is who they say they are. Search the web, there are hacked versions of sendmail which will tack on a PGP signature to any email matching certain criteria.

Your answer lies elsewhere for e-commerce security, young grasshopper. Seek out the knowledgable old farts who have done this before.

the AC

Verify by reply

[Hew]

In my experience, you can not trust the receiving MTA's to tell you whether the account is valid or not. The only way to be *really* sure you have a valid e-mail address at the other end, is to send mail to that address, and get the receiving party to reply, and then you track the reply. Then at first you know there's a live address at the other end.

Re:identity of the potential customer

[Scott Wood]

How are you going to determine what the potential customer's mailserver is? You can't just ask him for his e-mail address and then strip the "username@"; a lot of mail services (especially massive, quasi-anonymous ones like Hotmail or Netaddress) don't run SMTP on the machine whose name is after the @ in the address -- if a machine with that name even exists

You can look up the MX record(s) for the domain after the @; this will give you the mail server(s). If you couldn't determine the mail server automatically from the address, the e-mail wouldn't be deliverable.

--

Re:No VRFY For Me

[lomion]

That is the main reason why i disable it on all servers i setup that are mail servers. That and to prevent snooping. It is a shame that that has to happen but that is the reality.

It's just prudent to reduce any potential avenues of trouble

I have vrfy turned off on all my systems

[draziw]

It's to easy for vrfy to be used as a tool for spamers, or those that want to hassle a user on my systems. I use the postfix setting

disable_vrfy_command = yes

On the 3 domains where I run mail services.

There's no substitute for actually sending email

[Chris Siebenmann]

This has been said before in comments, but there really, truly is no way around actually sending email to see if an email address is truly valid. You cannot reliably tell invalid addresses in any other way; however, you may be able to quickly tell that some addresses are invalid with VRFY or RCPT TO:.

The major fly in the ointment for all SMTP level verifications is the presence of backup MX entries. The machine you are able to deliver email to may have nothing to do with actually delivering the email to the end user, and as such is going to be completely unable to know what addresses are good and bad there. This is very common with less than reliable network links or less than reliable mailer software.

There are also many mailers that will accept any user name in a RCPT TO: command, and only bounce invalid usernames later. Often this is done as a performance enhancement, so you only have to do the necessary and perhaps complex lookups once.

Re:There's no substitute for actually sending emai

[PigleT]

The 'necessary and perhaps complex lookups' stem from a two-phase process, normally: there's an MTA which takes mails and asks "is the domain in this mail accepted locally? or do I relay it? or do I tell it to get lost?" and then passes it off to a local delivery agent which does the appropriate thing (either /var/spool/mail/$USER or ~USER/Maildir/ or something totally other).
Hence you're right, you can't rely on the MTA to tell you anything about the long-term fate of the email address, unless it's local (ie the domain matches), in which case you've let loose the username or other id of a valid user on your box, which is always regarded as a reduction in security.
~Tim
--
.|` Clouds cross the black moonlight,

Re:Scare the shit out of us, why dont you :-)

[bluGill]

. Are you implying your client is now going to ignore the laws requiring them to establish a solid business relationship before ever transporting the chemicals off site? Sounds like a very irresponsible thing to do, probably illegal.

I should hope you are establishing a solid business relationship with any potential customer before allowing them any access to the ordering process.

I think the point is that email is now a common means of communication. So he might get a message "I'm John Doe, an engineer with Acme computers. We need someone to produce a few custom chips. . ." This is the first contact, and he doesn't want to waste time setting up face to face meetings, possibaly flying someone to location only to discover that it was just a script kiddie.

Re:Scare the shit out of us, why dont you :-)

[fcw]

Any company that goes from 'unsolicted sales enquiry' to 'air tickets for salesman' without intervening steps such as phone calls, faxes and written credentials has other problems besides proper hazmat handling.

Re:Verify by reply

[fcw]

Actually, some senders are using a sneakier way of telling. They send HTML e-mail, and embed a reference to (say) a 1x1 invisible GIF, but serve it up through a URL that includes a unique identifier. That way (if your e-mail client renders HTML messages automatically, and you're
connected at the time) they know you opened the message even if you then just delete it, without either a reply or even a receipt being explicitly sent by you.

WTF?

[PlanetPhat]

Ok your asking how to verify the individual's or business' email and your wondering if you should do it by VRFY? Send them an email with a random string and have them reply to it. But if its a security issue as far as who you are selling these "potentialy dangerous chemicals" to. Its going to take far far more than just verifying that they have a valid email address to make sure that you're not selling to the wrong type of individual. Email? Random string, definatly. The rest? You need to do some more thinking.

Re:pointless

[Another MacHack]

Doing a RCPT TO doesn't mean much with some mailservers. Like exim:

220 localhost ESMTP Exim 2.04 #1 Thu, 1 Jun 2000 16:36:21 -0700
HELO localhost
250 localhost Hello user at localhost [127.0.0.1]
MAIL FROM: [e-mail]
250 is syntactically correct
RCPT TO: [e-mail]
250 is syntactically correct

Re:identity of the potential customer

[alexburke]

Ever heard of an MX record?

--
"Give him head?" ... "Be a beacon?"

"One World, one Web, one Program" - Microsoft Ad

Sounds like you need...

[MZoom]

A "crypto" type solution IMHO. If client verification over a medium prone to anonymity is really the way you wish to go, how about setting up a PGP/GnuPG method?

I mean surely your customers are known to you prior to any email being sent to you. If not I could simply send you an email and you wouldn't know me from Joe Blow the terrorist. So instead of trying to verify if someones email is valid. Why not control the exchanged information using encryption?

This approach is a quite a bit more secure IMHO. Why not use PGP or GnuPG? Emails can be signed, encrypted and sent securely. This way you and your clients can exchange Keys and not worry about who's server the email came from. As long as the key is valid and trusted, who cares what server sent it. If it's encypted and signed you'll know it's valid. Plus you get the added privicy from the encyption. Remember even if you can positivly verify the email address, a person with access to the mail server can read the message if not encrypted. Maybe not a terrorist, maybe not a coporate pirate. Possibly just a snooping sysadmin. But then again, maybe he is an opporitunist looking to make a buck at your expense.

Obviously security will be a little work. You would be a fool to think otherwise. Be wary of any solution that seems to easy or good to be true. It usually is!

A PGP/GnuPG key trusted by being exchanged in a secure manor is IMHO the best solution I think you'll find.

Re:Verify by reply

[Bryan Andersen]

The problem with this is you only know somebody opened that message causing that image file to be retreived, but then that's all the confidence you from a reply. You don't know if the person really did see it.

All I think that can be done is to do the standard initial contact via email. Then followup communications after the standard hazardous materials handling vetting process is completed.

SMTP VRFY: Access Denied

[UGNS]

define(`confPRIVACY_FLAGS',`goaway')dnl I find no real reason to use any other privacy flag setting... One of the big reasons to keep VRFY disabled is so spammers can't just run a script that goes and verifies hundreds of email addresses on your system for the purpose of compiling a list... If you want to use e-mail address for verification just have a multi-stage process like most sites do these days were the account doesn't get activated till you receive the e-mail and go to a URL or enter a code that is only displayed in the e-mail... if it bounces or they give a bogus address then the e-mail address is obviously not valided...

Plus dont forget firewalls

[dalewj]

I consultant on exchange/notes/ccmail (STOP LAUGHING PEOPLE - I make damn good money :) Internet conenctors and such and most everyone is behind a firewall (Where the firewall is replaying mail) and reverse lookup and name lookup to those firewalls will simply get you a blank stare. They have no idea about usersm they simply relay the mail inwards -DAle>