It is most probably the receiving end which causes the trouble.

Emails can look different at different email clients or web clients.

I think I just found the solution
Changing the following in common_helper.php:

//if ($emailcharset!='utf-8')
if ($emailcharset!='iso-8859-15')
{
// $body=mb_convert_encoding($body,$emailcharset,'utf-8');
// $subject=mb_convert_encoding($subject,$emailcharset,'utf-8');
// $sitename=mb_convert_encoding($sitename,$emailcharset,'utf-8');
$body=mb_convert_encoding($body,$emailcharset,'iso-8859-15');
$subject=mb_convert_encoding($subject,$emailcharset,'iso-8859-15');
$sitename=mb_convert_encoding($sitename,$emailcharset,'iso-8859-15');
}

I have tried that in email.php and config.php with the parameter emailcharset
And it's possible that a change in some other file is better. But this seems to work.

/Kenneth

Does that also explain why confirmation emails are sent correctly (do thy use different code)?

Good question. I haven't gotten that far yet. But I can't find any other function in common_helper.php that points to that so I don't know!?
I will try to verify this on my "production system".

/Kenneth

Well, if that fixes your problem it means that your data is originally not saved in UTF-8. You will need to check all tables and each field in the tables again for the right collation.
Did you maybe restore the database previously from a backup using the wrong default collation?

This was a downloaded Ubuntu 14.0.4 virtual machine from bitnami with preinstalled Limesurve 141126.

However what I did was to import a *.lss. But I think it was UTF-8 coded.
Not quiet sure. I'm new to both Linux and php so bare with me

I will try to check the tables. From what I can tell in the database backup, default collation is utf8_unicode_ci

/Kenneth

So...this continues to haunt me.
After the holidays I have downloaded an updated virtual appliance (Ubuntu 14.04 from bitnami). Running it and it works.
Deploying it on an ESX server in DMZ. Browse to the application and bam... there it is the problem again WTF.
So I started thinking..what changed. I accessed the application remotely. Testing it on the newly downloaded virtual appliance and now I can replicate the error.

If I access limesurvey from within the virtual appliance the email is sent with the correct encoding. If I access limesurvey from the "outside" it's sent with the strange charachters instead of å, ä and ö.
Using Chrome from the outside and Firefox from with Linux if it could be of importance.

/Kenneth