lettre: Attachment filename with utf-8 chars is broken

Describe the bug When updating from lettre 0.10.0-alpha.4 to 0.10.0-rc.2, the Content-Disposition header handling was replaced with an own implementation in #601.

When setting an attachment filename with the new attachment API containing an umlaut like “Töööst.pdf”, it will also encode the filename= part of the header. Example output:

Content-Disposition: attachment; =?utf-8?b?ZmlsZW5hbWU9IlTDtnN0?=.pdf

My email client no longer shows any filename for the attachment 😃

This is how I handled an utf-8 based filename for attachments in lettre 0.10.0-alpha.4:

parts = parts.singlepart(
    SinglePart::base64()
        .header(header::ContentType(
            "application/pdf".parse().unwrap(),
        ))
        .header(lettre::message::header::ContentDisposition {
            disposition: DispositionType::Attachment,
            parameters: vec![DispositionParam::Filename(
                Charset::Ext("utf-8".into()),
                None,
                pdf.filename.as_bytes().to_vec(),
            )],
        })
        .body(raw_pdf),
);

This resulted in this header:

Content-Disposition: attachment; filename="Töst.pdf"

Also not ideal since it does not specify the character encoding, the mail client assumed utf-8 though.

I’m unsure how the attachment API for non utf-8 filenames is best exposed in lettre.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 22 (11 by maintainers)

Commits related to this issue

Bump lettr to 10.0.0-rc.5 pulls in fix for https://github.com/lettre/lettre/issues/626 Signed-off-by: Robert Günzler <r@gnzler.io> — committed to robertgzr/himalaya by robertgzr 2 years ago

Most upvoted comments

I started looking into this and I’m working on a solution that would solve both this issue and #672

paolobarbolini on Sep 19, 2021

f you’d like to take a stab at this I’d be more than happy to review your PR

sounds like a good plan, I’ll start working on it on the side. Thanks for your feedback.

thomasjfox on May 31, 2021

I’ve opened #685 with the fix to this issue

paolobarbolini on Oct 21, 2021

Interesting side note: Microsoft Outlook 2019 doesn’t seem to support “RFC2231: 3. Parameter Value Continuations”: https://techcommunity.microsoft.com/t5/office-insider/the-file-name-of-the-attachment-received-in-outlook-2019-is/m-p/1762750

The post is from October 2020, so it’s probably still valid. Writing it down here in case someone reports this in the future as “lettre bug”.

thomasjfox on May 20, 2021

@paolobarbolini Super thanks for the work you are putting in! I understand those things take time, and I’m not at all trying to beat the drum here, but if there is an existing solution to this issue, then maybe there is a small tiny chance that I could have a peek at some of the code? that way I could try some ugly duct tape hack to get it handled for my own little project. You know, at least maybe a temporary fix until it’s done and proper. =) I’d be forever grateful.

Actually there might be an hacky solution to this 😃. The correct filename encoder has already been implemented, what’s slowing everything down are questions about crate naming (since it has been implemented in a separate unpublished crate) and changes to the header API. I may however have a temporary hacky way to implement it just for the Content-Disposition header. I’ll try putting something up.

paolobarbolini on Oct 15, 2021

I already implemented RFC 2047 and RFC 2231 encoding. We decided to put the implementation in a separate repository, in order to avoid bloating the main lettre crate with too much stuff, which will be published as a separate crate that lettre will use internally.

The repository is currently private but we will publish it as soon as possible, the main remaining question is probably crate naming. Do we want to make a crate which only implements encoding? For example an RFC 2047 decoder crate already exists.

paolobarbolini on Sep 29, 2021

Any news on this one?

jmingov on Jul 20, 2021