[GSoC 2024]: Email service with internationalisation and MJML-based markup

I encourage you not to let Rust’s default UTF8 string encoding make you complacent. The big obstacles to globally inclusive address support is generally not the shipping around of non-ASCII data.

The number one obstacle is usually some misguided validation step in the interaction which collects an email address from the user. Many apps attempt to use syntax checks, such as a regular expression, to decide if an address is valid. Syntax checks beyond the most basic are a doomed exercise: they will likely rule out valid globally-inclusive addresses, while letting through actually invalid addresses. The inclusive way to validate a user-supplied email address is to send a test message to it, and have the user click a link in the message. So a task for this globally-inclusive goal is to look at the email address collection workflow.

The number two obstacle is usually the sending server chain. That will involve examining the configuration of our SMTP server, and sending test messages to see if they get through.

The number three obstacle is often the display of email addresses. The important issue here is to treat the address like user free text, which could be in any language or script. Avoid punycode for domain names when displaying to the user: it is meaningless to them. Be sure that there are fonts available to cover a wide range of scripts.

Anyway, all of this is out of scope until you decide to add this goal. I just encourage you not to be complacent about it. There are reasons why globally inclusive email address support is rare, in a world where UTF-8 usage is common.

[Edited to improve the wording.]

2 Likes