What this RFC defines
RFC 2183 defines the Content-Disposition header field for MIME messages. It specifies two primary disposition types: inline (the content should be displayed as part of the message) and attachment (the content should be offered as a downloadable file). It also defines parameters like filename and creation-date for attachments.
Where you see it in practice
The Content-Disposition: attachment; filename=”report.pdf” header that controls whether your email client downloads a file rather than displaying it inline is defined by this RFC. When an email displays an embedded image directly in the body versus as a downloadable attachment, the choice is controlled by Content-Disposition: inline versus Content-Disposition: attachment. Spam filters also inspect Content-Disposition headers for suspicious attachment names.
How it connects to other RFCs
RFC 2183 obsoletes RFC 1806 and extends RFC 2045 (MIME framework). RFC 2231 extends RFC 2183 with support for non-ASCII filenames. Content-Disposition is distinct from Content-Type (RFC 2046): Content-Type defines what the content is, whereas Content-Disposition defines how it should be presented to the user.
Current status
RFC 2183 is a current standard, published August 1997. The Content-Disposition header it defines is universally supported by email clients, web browsers, and HTTP servers and has not been superseded.
The Content-Disposition header
RFC 2183 defined the Content-Disposition header for MIME messages, giving each body part a “disposition” of either inline (should be displayed as part of the message) or attachment (should be presented as a separate file for download). The header also carries the filename parameter used when saving attachments and metadata like creation-date, modification-date, and size. Every attachment in every email has a Content-Disposition; without it, the client has to guess.
Inline versus attachment nuance
The choice of inline versus attachment is a hint, not a command. Modern mail clients often decide independently: they might display inline images even if marked attachment (if referenced from HTML body via cid: URLs) or move to attachment area even if marked inline (if the content type is unrecognized). The Content-ID header links HTML img tags to specific MIME parts, and if this linkage is broken, images that would be inline appear as attachments instead.
Filename handling and internationalization
Content-Disposition filename parameters follow RFC 2231 encoding for non-ASCII filenames. Historical implementations sometimes generated RFC 2047 encoded-words instead (which is technically incorrect but widely tolerated). If a downloaded attachment shows garbled filenames (mojibake, question marks, or encoded prefixes visible), the sender likely produced non-conformant encoding. Modern libraries generate both RFC 2231 and RFC 2047 forms for maximum client compatibility; older or minimalist tools may produce only one form.
RFC 2183 (August 1997) defines the Content-Disposition header: how a MIME part should be presented (inline in the message body vs as a separate attachment) and what filename to use. Two dispositions: inline (render in place, typical for message body and embedded images) and attachment (offer as file to download). Includes filename parameter with support for non-ASCII names via RFC 2231 encoding. Companion to Content-Type; every attachment-carrying email uses Content-Disposition.
RFC 2183 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Declare how a MIME part should be presented and its filename |
| Header | Content-Disposition |
| Values | inline or attachment |
| Key parameter | filename (RFC 2231 for non-ASCII) |
| Other parameters | creation-date, modification-date, read-date, size |
| Published | August 1997 |
Disposition values
| Value | Meaning | Typical use |
|---|---|---|
inline | Render in place; part of message body | Message body parts, embedded images referenced by cid: |
attachment | Offer as separate file for user to save or open | PDF invoices, spreadsheets, image files not embedded |
Content-Disposition examples
Common Content-Disposition mistakes
filename*=UTF-8''percent-encoded) or RFC 2047 encoded-word form for compatibility. Modern generators emit both.filename="C:/Users/alice/invoice.pdf"). Path components confuse receivers and may cause security issues on save (path traversal risks). Emit only the filename, no directory components.Related standards and further reading
- Content-Type and MIME Structure: parent header discussion
Frequently asked questions
Should I use inline or attachment for embedded images?
Inline. Embedded images referenced by HTML body via cid: URLs must have Content-Disposition: inline and a matching Content-ID header. Attachment for the same image makes the HTML broken (image not displayed) and adds a duplicate download link. Use inline for embedded; attachment only for standalone downloadable files.
How do I emit a non-ASCII filename?
Use RFC 2231 form: filename*=UTF-8''percent-encoded-utf8. This is the modern standard. For maximum compatibility with older clients, emit both RFC 2231 and RFC 2047 encoded-word forms; receivers use whichever they parse. Modern email libraries (Python email module, JavaMail, Nodemailer) handle this automatically.
What is the difference between Content-Type name= and Content-Disposition filename=?
Content-Type’s name parameter and Content-Disposition’s filename parameter both suggest a filename. Content-Type’s name is legacy from RFC 2046; Content-Disposition’s filename is the modern authoritative source. Emit both for compatibility (some legacy clients only check name=); prefer filename= as the semantically correct location.
Can Content-Disposition contain a full file path?
No. filename= should be a bare filename, no directory components. Emitting paths (filename="C:/Users/alice/document.pdf") violates the RFC and creates security risks: receivers who blindly use the path for save destination can be tricked into overwriting arbitrary files. Modern parsers strip directory components; generators should not emit them.
Are creation-date, modification-date, read-date, and size parameters commonly used?
Rarely. These parameters are legal but few generators emit them and few receivers act on them. filename is the practically important parameter. If your application needs to convey timestamps or size, prefer application-level metadata inside the file content rather than relying on Content-Disposition parameters.
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.
