On 22/09/2022 10:24, Kai Bojens via Exim-users wrote:
Hello there,
I have a new server which now has SMTPUTF8 enabled. I'm not sure why but since
then at least one Outlook client decided to stop using the IDN form
(xn--dmin-moa0i.example) and now tries to authenticate with the UTF-8 domain.
Researching this problem has led me to some questions:
1. How does exim handle UTF-8 in authentication data?
SMTPUTF8 applies to domains used in envelope addresses. It says nothing
about authentication, as far as I know.
Exim per se. doesn't tie auth data to a mail address, and just
handles 'strings". I'd not be surprised if all-zero bytes are
an issue, strings being NUL-terminated - but UTF-8 carefully avoids
those being used as part of multibyte UTF-8 chars (as you can tell,
I'm not sure what the official term is).
Your config could, of course, tie authentication data to a mail address.
2. How does exim handle the logging of such information? I searched the logfile
and noticed that the authentication information is logged with UTF-8 in octal:
(set_id=xyz@XXX\303\266nX\303\244XXX.xyz)
Many bits of logged info are escaped, to sequences like "\n" "\t".
The non-printable bytes not specifically handled get, as you found, \nnn octal.
The main-config option "print_topbitchars" affects that decision.
I doubt there's been a recent code-sweep checking that this escaping is
consistently applied. It would be a useful project to enforce it
for any data coming from an untrusted source (using the taint-tracking
that is already done), even though that's not sufficient.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
