How do I pass form data between pages and have it email me the results?

There's a number of issues here and I'm not going to address them all but just to start with I suggest you look at http://php.net/manual/en/function.mail.php. Make use of the examples shown at the bottom of the page to write yourself a very simply PHP script which sends an email to you. See if you receive it. This will provide you with some of the skills you need for your entire project and also ensure that your current hoster allows you to send emails. I'm sure others will chime in with other information

Hmmm, after reviewing that (and only understanding some of it) would I be correct that the method of how I utilize PHP to actually send the email is highly dependent on what MTA available on my hosting account? Please bear in mind that I have only an extremely basic understanding of what an MTA is and how it relates to this. FWIW I have a standard Dreamhost shared hosting account.

Are you doing this for work? If you have never done this before then get someone in to do it, it'll be cheaper and they will deal with xss and validation for you.

You should read up on http://php.net/manual/en/function.session-start.php. As for sending mail, its fairly trivial, you just need the appropriate mail server details.

Thanks for the links so far guys, this is great reading material. A couple things... @syzygy I figured it required use of GET and POST, thanks for the link. I had no idea this PHP Manual covered everything in such detail--this is fantastic. @devnull I am doing this for a new business website of mine I am launching and while I know it would probably be inexpensive and quicker to outsource it, I have been wanting to learn more PHP and I figure this is a good next step for doing so. Again, I want to "learn to fish" so to speak. @wongcorgi Are sessions required to do what I want to do? Or is it just a way to pass the data through while not requiring it to be passed in the forwarding URL like it would be with GET and POST?

I don't yet have an understanding of how to implement global GET and POST commands (which I have a hunch is what is involved in passing the data between pages according to the initial research I've done). Sorta kinda. GET and POST are two different approaches for handling form data: GET stuffs it into the URL for the next page, while POST handles the form data separately from the rest of the page. yes I am wildly oversimplifying this but it is ok do not panic. The advantage of GET is that you can access the data on the clientside using javascript if need be, strictly speaking don't have to have any serverside code, and if a user bookmarks a page in the middle of the process, state will be maintained (since it's all in the URL.) The advantage of POST is that the data doesn't have to be stuffed into the URL, which has a limited length. In practice, GET is really only useful if you have only one or two form fields to cope with; most of the time you want to be using POST. So: your page one contains a form using a POST method, a select box with your industry selection, and a hidden input into which you will put the page referrer URL (using javascript). This form points to PHP script one, which will read those two pieces of form data, generate HTML for page two, which contains another POST form pointing to PHP script number two. Any fields you want to maintain into further steps, which is so far all of them, the PHP script should stuff into hidden inputs in that form. Repeat as needed, until your last form points to a final PHP script which actually sends the mail. You don't need to do any serverside state maintenance or have any sort of database, since all the data you're passing along from previous steps is contained in hidden inputs to be passed on to the next step. There are, of course, far more elegant approaches than what I've described here -- PHP sessions actually do most of this work for you, in fact -- but this is easy to conceptualize and will work; for your first time out and as a learning experience it may be the way to go. One warning about that last step, though: for any script which sends email, it is very very easy to screw up in ways that will let the bad guys use your script as a gateway for spamming people. For that final step you are almost certainly better off using a prebuilt script that will have been tested for this, rather than coding from scratch, even if it's still a black box to you. Alternatively, you could have your script save the data on the server rather than emailing it -- this could be a flat-text log file if you don't want to deal with a database.

For your point number 2 about capturing the original referer: you can access that in php via $_SERVER['HTTP_REFERER'] which you could then encode in a hidden form variable so that it gets propagated to the next steps. However, this technique leaves you vulnerable to user tampering because you have no way of validating that what you receive in the posted form data was not changed in some way. There are countless ways a user can do this, e.g. editing the page source through Firebug or simply posting directly with something like curl. In this case you may not care about the integrity of this data, but in other cases you do, and the way to fix it is to use php's session feature. Instead of propagating the value itself, you store the value server-side in the session store and instead propagate a session ID. The user can still send any session ID they want but the chances of them being able to pick a valid one at random are remote. (Sometimes you have to augment this logic further because you don't want malicious users from tampering with other users sessions if they learn their session ID, such as what can happen if you maintain the session ID in a GET parameter and the user publicly posts a link that contains their session id.)

And I have to mention that the issue of validating the referer data is rather benign as referer data is user-supplied; a malicious user could fake it at the first step anyway. But in general I just want to make sure that it's understood that propagating things through hidden form fields should not be relied on for anything for which user tampering could be ruinous. Also, there's a very significant problem that you have to be aware of any time you take user data from a POST or GET and then use that to generate HTML, such as what you'd do at step 2 having received the industry type from the previous step. You have to make sure that you don't allow any cross-site scripting exploits. For example, if you blindly trust that the user picked one of the values in the drop-down, a malicious user could POST a form with a bogus selection of "<script>document.write('your page is owned');Heavy Mining". If you then turn around and use that value to generate HTML for your next step, you've just embedded a script tag from the user in your page, which is all kinds of dangerous.

Thanks for the great additional info ook and Rhomboid. Good points on the potential security holes with the referrer string and the POST/GET commands. I am expecting primarily business folk on this site as it is a company website offering business services, so I guess I'm less concerned about them spoofing their referrer info on a lead-capture form (if they go to the trouble to do this I probably don't want them as a customer anyway), but I definitely still see the concern with the cross-site scripting exploit. Is there an easy way to prevent that sort of exploit? Is that the sort of thing that is prevented by using sessions as ook mentioned?