the good news is that, for this particular problem at least, it was self inflicted and other users of the package should not be affected, except as I noted that it may be exploitable through similar variables. Your solution in general is a good one and is roughly what I will be doing but working from a better base - that is when the tuits are available.

I really am no expert, but if you work on the principle that what a spammer wants to inject into your email headers is essentially a long list of email addresses, if you set up a few small lines of code to remove “to:”, and “cc:” from your email body variable then i would have thought you make it a no win situation for them (removing “cc:” would leave only “b” from “bcc:” of course - thats not gonna send their message to a long list of email addresses!)

For example, if your email is built by adding attribute=value pairs to a variable called $subject, before you fire off the email to yourself at the end of the script, do something like
$subject = eregi_replace(”cc:”,”",$subject) //case insensitive replace to change “cc:” to nothing in the variable $subject

Maybe add the same line, but next time replacing “to:” with nothing - I may be wrong but I have a memory that you can have as many “to’s” in an email as you like. Well, even, you could replace the @ with something arbitrary like =A=, then for a genuine person sending you a single email you would know what to do to reply to them - whereas a spammers list is going to fall over if its sent to people=A=somehost.com

Like I said, I aren’t an expert but in my simplistic way of looking at it, whatever other rubbish they can inject into your headers, at the very least only you will be getting the email.