Wez Furlong
466a59df44
What a mess! RFC 2047 defines an encoded-word as a way to indicate that some text has 8-bit content and a specific charset, allowing for inline transfer encoding to be applied to it. It expressly says: An 'encoded-word' MUST NOT appear within a 'quoted-string'. An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. Today we encountered this header: `Content-Disposition: attachment; filename="=?UTF-8?B?5pel5pys6Kqe44Gu5re75LuY?="` which violates both of those restrictions. RFC 2231 is a different RFC that specifies how to encode these sorts of headers correctly. Hunting around a bit on the internet, it appears that someone started to use the bogus form, perhaps as a transitional workaround, or perhaps by mistake, and it has become something of a de-facto accepted standard to the point that gmail and fastmail both will generate this header construction when attaching messages. So we need to be able to parse these out. This commit introduces a special case for this as the last step in the MimeParameters::get method that will try to decode the retrieved value as an encoded-word, and if successful, return that decoded value.
KumoMTA
KumoMTA is an open-source Message Transfer Agent (MTA) designed for high-performance outbound email functionality, similar to commercial enterprise MTAs such as Momentum, PowerMTA, and Halon.
The KumoMTA project was founded by a group of email industry veterans with decades of experience building and managing high-performance On-Prem MTAs and is supported by a community of some of the largest senders in the world.
Because it is designed for high-performance sending environments, KumoMTA is for experienced email operations professionals who are accustomed to high-performance sending environments and familiar with DevOps practices.
Learn more in our FAQ and at https://kumomta.com/.
Documentation
You can learn more about KumoMTA from the Documentation.
Community
Real-time discussion is available on Our Discord.
Developers
If you are interested in contributing/extending KumoMTA, take a look at DEVELOPERS.md. The #devel channel on Our Discord is for contributors to discuss KumoMTA development.
Reporting Bugs
See How to Report Bugs.
Getting Help
See How to Get Help. Issues are for features and bugs only, any help requests posted to Issues will be closed. For paid support see https://kumomta.com/support.
Getting Updates
You can subscribe to updates at https://kumomta.com/subscribe, we send updates periodically and will never sell nor share your information.
Talk to Us
We're available to talk about the project, book us at https://cal.com/team/kumomta/talk-with-kumomta.