Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basic EAI support #8770

Closed
wants to merge 5 commits into from
Closed

Basic EAI support #8770

wants to merge 5 commits into from

Conversation

arnt
Copy link

@arnt arnt commented Jan 24, 2025

This adds basic EAI support for Thunderbird/Android, bringing it to roughly the same level of support as other versions of Thunderbird: Can display messages to/from/cc grå@grå.org, cannot use grå@grå.org as your own address.

It requires a bit of code in MIME4J that I haven't pushed yet. With the currently released MIME4J and this PR, Thunderbird displays most of an EAI messages, but... it's complicated:

  • all messages that could be displayed previously are still displayed
  • a few messages are displayed better (no more xn-- display)
  • some messages that could not be displayed at all are now displayed without addresses or with incomplete address lists (the upcoming MIME4J PR fixes this)

A later PR to tb will add a little more, but I wanted to get this out the door, because it's an improvement, and big enough that I was annoyed by the 8.2 version when I accidentally used it after getting used to this.

Waiting until all the functionality and dependencies are in place is of course an otion. That reminds me a little too much of RFC 1925 truth 5.

This doesn't break any unit tests, but two unit tests were failing already when I started this. I didn't investigate those.

arnt added 5 commits January 24, 2025 11:40
Thunderbird already supported the addresses substantively, since it uses
the String type for addresses. That class has no support for ASCII-only
strings, only for unicode strings. In effect, the programming language
prevented Thunderbird from being incompatible with unicode addresses.

RFC 6531 requires more than substantive compatibility though, it also
requires correct declaration of the addresses, and that's what this commit
adds.
An header such as
  From: info@xn--gr-zia.org
is syntax according to RFCs 822 and 5322, but should not be shown to users
because the "xn--gr-zia" is as user-unfriendly as it is phisher-friendly.
This commit makes Thunderbird morph addresses that used xn-- into the pure
unicode form on input.

This change is not strictly related to EAI. However, it depends on
SMTPUTF8 to keep the code simple: When a user replies to a message that
used punycode, the reply's syntax often depends on RFC 6532, and sending
the reply needs RFC 6531.
Once the server has sent ENABLED UTF8=ACCEPT, the server may send UTF8 in
any string. This is not a problem for Thunderbird now, it didn't need
changes to the parser. The purpose of these these two tests is to guard
against any possible future breakage.
@arnt arnt requested review from cketti and wmontwe as code owners January 24, 2025 11:17
@arnt
Copy link
Author

arnt commented Jan 24, 2025

I'll have a coffee break now, then polish the mime4j tests so I can push that code.

@cketti
Copy link
Member

cketti commented Jan 24, 2025

Hi Arnt, thanks for your pull request 👍

I think this should be split into multiple pull requests so we can focus on one aspect at a time. For example, adding support for UTF8=ACCEPT probably requires a few more changes. At the very least the code that deals with folder names needs to be updated to not apply the modified UTF-7 encoding.

My suggestion would be to start with a pull request just focusing on UTF8=ACCEPT and only move on to the next EAI puzzle piece once that pull request was merged. Would that work for you?

@arnt
Copy link
Author

arnt commented Jan 24, 2025

Hi,

we can do that, but I don't see any point. This stuff is a little intermingled. Just one moment and I'll push all 6855 needs...

@arnt
Copy link
Author

arnt commented Jan 26, 2025

Let's close this.

I have all the code locally. I pushed the IMAP-specific code, I can push SMTP+necessary once the IMAP code is merged, and then then perhaps the rest after SMTP.

@cketti cketti closed this Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants