Ok, I got around it. This appeared with the latest release because it is using now htmlentities to protect against code injection which is great. The side effect however is for people using special characters in their language, everything gets … funny to say the least.
Using htmlentities is fine but then, the email has to be send not in play text but in html to make it readable.
And htmlentities is applied twice which make things even worst.
So here is my patch:
Line 114, has to specify UTF-8 encoding. So replace
$_POST['scf_message'] = htmlentities(stripslashes(trim($_POST['scf_message'])));
with
$_POST['scf_message'] = htmlentities(stripslashes(trim($_POST['scf_message'])), ENT_QUOTES, 'UTF-8');
line 216, send email in html so replace
$headers .= "Content-Type: text/plain; charset=\"" . get_option('blog_charset') . "\"";
with
$headers .= "Content-Type: text/html; charset=\"" . get_option('blog_charset') . "\"";
line 218, htmlentities should no be done twice so replace
$message = htmlentities($_POST['scf_message']);
with
$message = $_POST['scf_message'];
line 240, because the email in now in html, has to convert cr into br so replace
$fullmsg = stripslashes(strip_tags(trim($fullmsg)));
with
$fullmsg = nl2br(stripslashes(strip_tags(trim($fullmsg))));
A last note, I’m nothing like an expert in security so I think this code is ok but no garantie. I’ll send this patch to the author and see what he says.