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.
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 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.
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.
[We Have No Product] [The Swindle
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
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
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.
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.
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...
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>