-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parse fails on non-ASCII Subject #82
Comments
There is an RFC (of course) - https://datatracker.ietf.org/doc/html/rfc6532. Implementing it properly would require significant API breakage. However, for just |
FWIW, I have also noticed this problem with the display name of an email address, such as:
I understand that might be more difficult to fix. |
Partial support for RFC 6532. For now, only unstructured headers (e.g. Subject) allow UTF-8. Fixes: #82
Partial support for RFC 6532. For now, only unstructured headers (e.g. Subject) allow UTF-8. Fixes: #82
This works great. In my little test corpus of 1,000 emails it parses 100%, including UTF-8 in both the subject line and the email display-name. |
Partial support for RFC 6532. For now, only unstructured headers (e.g. Subject) allow UTF-8. Fixes: #82
This parsing fails with the error "Failed reading: satisfy", I assume because the Subject contains non-ASCII characters.
While this might not be email-RFC-compliant, messages like this do make their way through my postfix -> sieve pipeline and arrive in my inbox. Ideally, I would like a way to process them using a lenient purebred-email parsing option.
The text was updated successfully, but these errors were encountered: