It sounds like you’re worrying about something you don’t need to. And it still sounds like you’re mixing up To: and From: – To: is the recipient and that’s the field you really need to protect.
Basically, if you couldn’t define those variables, the mail function would be useless.
Anything beyond the basics of it, would be up to you. You can block any addresses you want in your script and should make it as secure as possible.
On the other hand, someone else needs to use that exact same function for a contact form and they need to be able to accept email from anywhere.
Just look at when you place an order online. At some point, there’s a good chance the script is using mail() to send an order from you to the merchant–even though you’re not using their domain as an email address.
Basically, the capabilities of the function itself aren’t a security problem. The security problem comes from poorly implementing it… but that’s pretty much true with any programming.
Some hosts even disable it, which to me, pretty much makes PHP (and the host) useless.
Like I said before, though… if there was a way to stop fake info or headers, there wouldn’t be any spam. The internet would also have a lot less 80 pound nerds pretending to be tough guys.
I’d also just add that if this all relies on scripts doing the mailing, make sure you’re not breaking anything spam-related in the TOS. Especially since you mentioned an opt-in list. It’s better to make sure everything is being done right, then find out the hard way later that it wasn’t.
Maximum savings promo code: MaxSavingsAtDH