What this RFC defines
RFC 2231 extends MIME parameter handling to support non-ASCII characters and long values in Content-Type and Content-Disposition parameter fields. It defines a character set and language tagging syntax for parameter values, solving the problem of how to include accented or non-Latin characters in an attachment filename header.
Where you see it in practice
When you receive an email attachment with a filename containing non-ASCII characters (like accented letters or CJK characters) and your email client displays it correctly, RFC 2231 encoding is what made that possible. A correctly encoded Content-Disposition header for a French filename looks like: Content-Disposition: attachment; filename*=UTF-8”R%C3%A9sum%C3%A9.pdf. Email clients that do not implement RFC 2231 may display garbled filenames for international attachments.
How it connects to other RFCs
RFC 2231 obsoletes RFC 2184 and extends RFC 2045 (MIME framework) and RFC 2183 (Content-Disposition). It complements RFC 2047, which handles non-ASCII in message headers but does not cover parameter values. Together they provide complete non-ASCII support for MIME messages.
Current status
RFC 2231 is a current standard, published November 1997. Its encoding for non-ASCII filenames is supported by most modern email clients, though interoperability issues still occur with older implementations that do not recognise the filename* parameter syntax.
Parameter continuation and encoding
RFC 2231 addressed two limitations of the original MIME headers. First, MIME parameters (like Content-Type filename or Content-Disposition filename) could not exceed line length limits, which made long filenames impossible. RFC 2231 introduced parameter continuation using an asterisk-numbered syntax: filename*0=”part1″; filename*1=”part2″. Second, parameter values were limited to ASCII, which prevented filenames in non-English languages. RFC 2231 added a charset-language-value syntax: filename*=UTF-8”Caf%C3%A9.pdf, where the value is percent-encoded UTF-8.
Common interoperability issues
RFC 2231 is famously inconsistently implemented. Outlook historically preferred an older encoding style (RFC 2047 encoded-words in Content-Disposition, which is technically incorrect but widespread). Gmail generally generates correct RFC 2231. Some servers strip continuation numbers, breaking long filenames. Some clients only support the continuation OR the charset syntax but not both. If you have ever received an attachment with a garbled filename (mojibake, question marks, or the raw =?UTF-8?B?…?= string visible), RFC 2231 non-conformance is the likely cause.
Testing and best practice
Best practice for outbound mail is to generate both RFC 2231 continuation-and-charset syntax AND an RFC 2047 encoded-word for maximum client compatibility. Most modern libraries (Python email, Ruby Mail, Node.js Nodemailer) do this by default when a filename contains non-ASCII characters or exceeds line length. Testing across Outlook, Gmail, Apple Mail, and Thunderbird is the standard conformance check; if any of these renders the filename incorrectly, adjust the encoding strategy. For CLI utilities and legacy code, the RFC 2231 handling is often where filename bugs originate.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
