You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Messages composed with alot may be rejected by some mail servers if headers contain non-ASCII characters.
linux-kernel@vger.kernel.org
host vger.kernel.org [209.132.180.67]
SMTP error from remote mail server after end of data:
550 5.7.1 Content-Policy reject msg: Message headers can not have 8-bit non-ASCII characters in it; Use MIME encodings if such are needed!
Describe the solution you'd like
The user should be warned before sending such message and be offered the possibility to have those headers automatically transcoded. An option to do that automatically could also be added.
Describe alternatives you've considered
Normalising those characters to ASCII manually. I always forget to do that before it's too late.
Additional context
#1 was supposed to handle this encoding issue, which still seems to exist in alot 0.8.
The text was updated successfully, but these errors were encountered:
wow, you've found #1 :D
These things are actually handled by pythons email module, so I doubt that the messages are not RFC compliant. But I'd be open to adding some config setting to enforce more strict encodings than what is considered default in 2019, by tweaking the calls to the email module where appropriate.
Migrating to Python 3.6's email.message.EmailMessage (issue #1409) will probably solve this as a nice side effect:
email.header: Internationalized headers
[…] In the current API encoding and decoding of headers is handled transparently by the dictionary-like API of the EmailMessage class. […]
Is your feature request related to a problem? Please describe.
Messages composed with alot may be rejected by some mail servers if headers contain non-ASCII characters.
Describe the solution you'd like
The user should be warned before sending such message and be offered the possibility to have those headers automatically transcoded. An option to do that automatically could also be added.
Describe alternatives you've considered
Normalising those characters to ASCII manually. I always forget to do that before it's too late.
Additional context
#1 was supposed to handle this encoding issue, which still seems to exist in alot 0.8.
The text was updated successfully, but these errors were encountered: