Inbound mail silently dropped when sender display name contains non-ASCII (e.g. "Søren") — UnicodeEncodeError in contact creation

[sorenmichaelsen]

Summary

When an inbound message's From display name contains non-ASCII characters (e.g. the Danish "Søren"), contact creation during the forward phase raises a UnicodeEncodeError and the message is dropped. No bounce is generated, so the mail is lost silently. Senders with the same address but an ASCII display name are forwarded correctly.

This is a serious real-world issue for any non-English user: display names with æ/ø/å/ü/é etc. are extremely common, and affected mail disappears without any error to sender or recipient.

Environment

• Image: jsonbored/simplelogin-aio:latest
• Digest: sha256:76313bcfddc5285ee3bda950371baac88da18222413868afa09942ca669c9ee9
• Likely release: v4.81.4-aio.1 (image built ~6 weeks before this report)
• Note: the org.opencontainers.image.version label reports "22.04", which is the Ubuntu base version, not the AIO release — appears mislabeled
• Host: Unraid

Steps to reproduce

1. Create an alias forwarding to a mailbox.
2. Send a message to the alias from an address whose From display name contains a non-ASCII character, e.g. From: Søren <sender@gmail.com>.
3. The message is not forwarded and no bounce is returned.
4. Send again from the same address with an ASCII-only display name — it forwards fine.

Actual

handle_forward() - Create or get contact for from_header:Søren <sender@gmail.com>
create_contact() - ... trying to create a new contact ... with email sender@gmail.com
handle_DATA() - email handling fail with error:'ascii' codec can't encode character '\xf8' in position 1: ordinal not in range(128)
  File "/code/email_handler.py", line 593, in handle_forward
  File "/code/app/contact_utils.py", line ...

The same alias, same sender address, with an ASCII display name succeeds:

Created contact <Contact ...> ... invalid_email=False
Finish ... return code '250 Message accepted for delivery'

Expected

Non-ASCII display names should be handled (encoded per RFC 2047 / stored as UTF-8), and in no case should a message be dropped without a bounce.

Suggested fix

Ensure the display name is decoded/encoded as UTF-8 rather than ASCII in the contact name path (contact_utils.create_contact / email_handler.handle_forward).