Slashdot Mirror
Do You Permit SMTP Verify?
"[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)."
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
I like qmail's handling of VRFY:
VRFY user@hostname.com
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
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.
-Ed Felix qui potuit rerum cognoscere causas.
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: me@mydomain.com
250 me@mydomain.com... Sender ok
RCPT TO: user@example.com
250 user@example.com... Recipient ok
RCPT TO: PddVQ9XB87bq8VH6YfFQ@example.com
550 PddVQ9XB87bq8VH6YfFQ@example.com... 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.
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
I have turned off VRFY and EXPN on all my SMTP servers. Our SMTP proxy (smtpd 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.
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 ima.badguy@terrorist.org 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
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
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.
/cj
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.
--
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.
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).
.|` Clouds cross the black moonlight,
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
--
~Tim
--
Rushing on down to the circle of the turn
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: bob@bob.bob
250 is syntactically correct
RCPT TO: whatever@bob.bob
250 is syntactically correct
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.
Integrity is what you are when nobody is looking.