-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
UTF8 in attachment filename is not encoded #75
Comments
It is hard to find some RFC for such situation. So, to find some working solution, I use Thunderbird. So I sent attachment named
|
And this is via. GMail web interface:
|
Milo, can you try to send files named |
Third char sould be
Correctly seen as |
And how encoded by GMail webface:
|
When sending
GMail
|
Thanks! |
Just to be sure, can you check also |
Thunderbird
|
And long ones (160 chars): in Thunderbird:
via GMail webface
|
Thanks! Now it should work correctly |
Version: 3.1.4
Bug Description
If the attachment file name contains UTF8 characters, the header is not RFC 2047 encoded, which causes email to rely on support of SMTPUTF8 extension, making the email undeliverable to destinations servers that don't support it (gmail supports it, but e.g. email.cz does not).
Steps To Reproduce
See resulting Content-Disposition header:
Expected Behavior
Possible Solution
This worked in the previous version, the bug was introduced with this change 6f33373 which fixed #24, in this change, call to
encodeHeader()
has been removed. This call should be probably returned, but I'm not sure how exactly in order to not introduce back the issue #24.I know a workaround is not to use utf8 in attachment file name with e.g.
Strings::toAscii($filename)
, but as long as the encoding works well with other headers like Subject or From, I don't see a reason for this header to be an exception.The text was updated successfully, but these errors were encountered: