Additional remark.
After a while, I figured out they probably didn't insert the extra
receivers via the email message ($r) --although they tried that too, had
to sort out hundreds of log entries-- but through the from/email variable.
There was a problem with the validation of the from-address in the
script (used trim instead of a regex to replace all \n's, trim only
removes \n at the beginning and the end). So in that way, they could
insert additional headers.
But I did some tests with mail() and I still think it should be
considered as a bug that PHP mail() allows insertion of additional To:
headers through the 'additional_headers' variable. You don't even need
to insert the MIME boundary for that, just put 'From: [EMAIL PROTECTED]:
[EMAIL PROTECTED]' in the additional headers and mail() will send it to
an additional recipient...
As spam attempts through mailforms are rising, I guess it would be a
better idea to disallow any definition of mail receipients in the
additional headers and force the user to input receipients via a
to/cc/bcc variable in mail() call. (but I know that's a PHP issue and
won't bother you any further with this ;-)
Kind regards,
Luc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
