Skip to content

Conversation

@GREsau
Copy link
Contributor

@GREsau GREsau commented Jun 4, 2017

I just found a couple of changes from last year that I never got around to submitting PRs for, so here's the first one!

For emails with attachments, the filename for an attachment should be specified in the filename parameter of the Content-Disposition header. But in practice, some email attachments will only have the filename in the name parameter of the Content-Type header. In my particular case, we're sending an email from .NET code using System.Net.Mail, which annoyingly only sets the filename in the Content-Type header.

While it doesn't really conform to any standard AFAIK, this behaviour is widespread enough that real email clients will generally handle it. However, currently when downloading one of these attachments using MailHog, the download does not have any set filename (e.g. in chrome it's just called "download") - I'm assuming this is because web browsers just don't bother handling this quirk that only really applies to emails.

This PR will, when downloading an email part, try to extract the filename from Content-Type header, then set this as the filename in the response's Content-Disposition header (unless the Content-Disposition already has a filename set). It will fall back to using {message_id}-part-{part_index} as the filename if it can't be found in either header.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant