Is there any risk of injection in PHP's mail() function?

I am wondering if there is any potential security risk from the following code. I use this on my blog whenever a user submits a comment, it will send me a text message:

mail('cellnumber@messaging.sprintpcs.com', '',
     "Comment posted by $name: $comment",
     "From: comments@example.com");

Where $name and $comment are user-entered values that haven't really been sanitized in any way. Is开发者_开发问答 there any possibility that a user could do anything malicious here? The mail() documentation doesn't say anything about this, but it just feels wrong to stick user-entered values directly into a string. Is there any real risk or am I just being paranoid?

As long as all user-stuff i's kept in the mail body, then there is no risk of injection.

However, as soon as a user can affect mail headers, then they can inject extra headers and do things like use it to spam arbitrary e-mail addresses or include a completely different message - including attachments.

If you check for newlines in the parts that affect the headers, and reject if it appears, then that should be enough. The SMTP standard uses CRLF to separate the header lines, but AFAIK, many Unix-based servers want you to only use LF (because that's the native line separator on those systems). The mail relayer then converts it when sending it further upstream.

Be aware of the newline character inside the name. Two consequent (erm.. pardon my English, two newlines one after another) newlines mean "end of headers" in SMTP.

Also, the sequence `\n.\n' (empty line with only a period) means "end of message".

EDIT: Yes, there is a risk of spammers! What if the $name actually contains:

 someonesName
 CC: spamsubject@domain.com; anotherspamsubject@domain.com

(i.e. something to inject more headers)?

EDIT2: didn't notice that "name" and "comment" were both in the body part of the message. Then my idea about spammers is not valid.

PHP is full of unsafe stuff, but I'm not sure there's a lot of risk here.

Certainly a too-long comment could overflow whatever limit you might have on message size. That probably won't hurt you.

PHP's $XXX syntax expands the string, but doesn't do any further evaluation of the XXX does it? If $XXX worked like some kind of eval(), you'd be in for a world of remote code execution, but I don't think that's the case.

If this is inwardly doing SMTP, then a . on one line followed by a blank line would signal the end of a mail, and theoretically an attacker could follow that up with more text in successive lines to hijack your mailer to mail some other message to someone else. That's if PHP doesn't recognize and escape such a string in the first place. This is something I'd look into.