On Mon, 3 May 2021, admin--- via Exim-dev wrote:
> https://bugs.exim.org/show_bug.cgi?id=2724
>
> Graeme Fowler <graeme@???> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |graeme@???
>
> --- Comment #2 from Graeme Fowler <graeme@???> ---
>> From the PDF:
>
> "Exim is a widely used open source mail server that provides an MSA and MTA. We
> installed it on a test host and configured it with several EAI addresses in IDN
> domains. Exim provides both Phase 1 and Phase 2 EAI support and passed most
> tests.
>
> Exim???s developers consider an EAI message to be one with UTF-8 envelope
> addresses and an ASCII message to be one without UTF-8 envelope addresses, even
> if the message???s headers include UTF-8. While we disagree with their
> interpretation, we think it is unlikely to cause problems in practice since
> messages with ASCII envelopes and UTF-8 headers are uncommon.
>
> Exim does not provide a POP or IMAP server. It is typically used with the
> Dovecot or Cyrus IMAP/POP servers neither of which currently has EAI support."
That text (or similar) appears in both attachment 1379 "Exim.pdf" and the
linked document "UASG030-en-digital.pdf". While UASG030-en-digital.pdf has
little detail, the attachment does at least list the tests that failed:
MSA Tests Failed
1. EAI messages sent to non-SMTPUTF8 server are rejected or transformed
MTA Tests Failed
1. Trace information includes domain in U-label form
2. Trace information indicates SMTPUTF8 protocol
3. EAI reverse path values are transmitted to SMTPUTF8 server
4. EAI messages sent to non-SMTPUTF8 server are rejected
These tests are described in UASG021B-en-digital-EAI-Pilot-Test-Cases.xlsx
I am not convinced that rejecting or transforming mail is better
than relaying it to a non-SMTPUTF8 server.
I see that John Levine contributed the EAI test software
https://github.com/jrlevine/eaitesttools
and mentioned exim in the equivalent fetchmail bug
https://gitlab.com/fetchmail/fetchmail/-/issues/14
> I do tend toward's Jeremy's viewpoint however: if the bug report is not itself
> clear, and requires extra legwork on behalf of the small maint and dev team,
> this is not an optimal way to report a bug.
>
> There is nothing technical in the PDF report to work with, simply the above
> statement that interpretations differ.
>
> If you'd like to offer more technical detail, please feel free otherwise this
> is likely to be closed as INVALID.
--
Andrew C. Aitchison Kendal, UK
andrew@???
