R. David Murray <rdmur...@bitdance.com> added the comment: You are indeed misunderstanding. The docs say:
If False, follow RFC 5322, supporting non-ASCII characters in headers by encoding them as “encoded words”. If True, follow RFC 6532 and use utf-8 encoding for headers. Messages formatted in this way may be passed to SMTP servers that support the SMTPUTF8 extension (RFC 6531). That is, when the flag is False, encoded words may be used, which is what the =?utf-8?q?....?= constructs are. If it is True, those are *not* used, but instead utf8 character encoding is used, which would look on your terminal like the international characters themselves, not encoded stuff. So, what you are seeing is the DKIM header getting re-encoded using encoded words in order to make it fit in the standard line length for email headers (78 characters max). The fact that that wasn't happening before was actually a bug in the folder that was fixed by the changeset you cite. You can get the behavior you want by setting the policy control 'refold_source' to 'none', or changing max_line_length to some value larger than you expect DKIM headers to be (or to None, which means don't fold). If the standard DKIM headers really are not respecting the standard default email header line length, that is a very sad thing. I think perhaps the default value of refold_source was a poor choice, and we should have gone with none. Changing that could be discussed, but since it changes behavior it may be controversial. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34277> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
