Apologies for going off-topic here… but what editor/theme are you using in this pic?
kdevelop with the Vim (dark) theme I think?
1 Like
Hi All, I’ve been playing around with this and have a little addition to remove the \r\n hack line.
The email policy fix with the wrapping of the headers, also allows you to specify the end of line, so it was a pretty simple fix as
from email.parser import Parser
from email.policy import EmailPolicy, SMTP as SMTP_policy
MSG_ID_HEADERS = {'message-id', 'in-reply-to', 'references', 'resent-msg-id'}
class MsgIdExemptPolicy(EmailPolicy):
def _fold(self, name, value, *args, **kwargs):
if (name.lower() in MSG_ID_HEADERS and
self.max_line_length < 998 and
self.max_line_length - len(name) - 2 < len(value)):
# RFC 5322, section 2.1.1: "Each line of characters MUST be no
# more than 998 characters, and SHOULD be no more than 78
# characters, excluding the CRLF.". To avoid msg-id tokens from being folded
# by means of RFC2047, fold identifier lines to the max length instead.
return self.clone(max_line_length=998)._fold(name, value, *args, **kwargs)
return super()._fold(name, value, *args, **kwargs)
our_policy = MsgIdExemptPolicy(linesep='\r\n') + SMTP_policy
2 Likes
There is also some double encoding that was also causing issues - please see pr fix: smtp rfc compliance and line endings for exchange 2016/RFC email servers. by cjpit · Pull Request #8708 · frappe/frappe · GitHub
If people could then also test to ensure working with different email systems - I am testing with exchange 2016 and postfix/dovecot
2 Likes
I think the default line ending for the email policy ‘SMTP’ is \r\n anyway - I only used the ‘replace(’\n’, ‘\r\n’)’ hack during testing. But nothing wrong with stating it explicitly anyway, and thanks for wrapping it up into a pull request 
1 Like
Will definitely provide feeback as soon as the pull request is merged. Sincere thanks.