with the recent addition of smtputf8 support for the rulesystem setups
explicitly disabling smtputf8 in postfix got broken.
This is mostly noticeable for the spamreports (the receivers are taken
from the database and potentially decoded from utf-8, which sets the
'is_utf8' flag, and then tries to use the smtputf8 extension when
reinjecting the mail, which fails (since smtputf8 is disabled)
Instead of checking for the internal flag, we check for occurence of
characters which are not ascii printable (everything excluding
controlcharacters - '[\x20-\x7E]') in the envelope-addresses and
headers (there also for [\r\n\t], due to searching all headers and
folding). - see
https://perldoc.perl.org/perlunifaq#What-is-%22the-UTF8-flag%22? and
https://perldoc.perl.org/perlrecharclass#POSIX-Character-Classes
The only diversion from the requirements in the smptutf8 rfc
https://www.rfc-editor.org/rfc/rfc6531
is that we do not check the headers of all parts of a multipart
message (think suggested filename for an attachment), but I assume
that this should not be an issue in mail-transit
the addresses now always get encoded as UTF-8, as this is robust for
aascii-only addresses.
reported in our community forum:
https://forum.proxmox.com/threads/.119387/
issue is reproducible by setting
`smtputf8_enable = no` in postfix main.cf
and sending a spamreport using `pmgqm`
regular mailflow should not be affected in those setups (as no utf-8
addresses would come into the system)