Email Attachments vs. Related Items
The Chilkat CkEmail object distinguishes between attachments and related items based on their MIME structure, headers (specifically Content-Disposition and Content-ID), and their intended use in the email's presentation.
1. The Standard Distinction
- Attachments (
NumAttachments)- Purpose: Files intended to be saved or opened separately from the email body (e.g., PDF documents, Spreadsheets).
- Criteria: Chilkat typically identifies a part as an attachment if:
- It has a
Content-Dispositionheader set to"attachment". - It is located in a
multipart/mixedblock (indicating it is separate from the body). - It is a file type that does not participate in the visual rendering of the HTML body.
- It has a
- Related Items (
NumRelatedItems)- Purpose: Assets required to render the HTML body correctly, such as embedded images, stylesheets, or background textures.
- Criteria: Chilkat identifies a part as a related item if:
- It is located inside a
multipart/relatedMIME structure. - It possesses a
Content-IDorContent-Locationheader. - The HTML body references this ID (e.g.,
<img src="cid:image001@domain.com">). - It typically has a
Content-Dispositionof"inline"(though not strictly required if other criteria are met).
- It is located inside a
2. How a Part Can Be Both
A single email sub-part can appear in both the NumAttachments collection and the NumRelatedItems collection. This usually happens due to ambiguous or "hybrid" MIME structuring by the sending email client.
Scenario A: Content-Disposition: attachment inside multipart/related
Some email clients send an image that is used in the email body (embedded) but explicitly label it as an attachment.
- The Conflict: The
multipart/relatedlocation andContent-IDtell Chilkat it is a Related Item (it's needed for the HTML). However, the headerContent-Disposition: attachmentexplicitly tells Chilkat it is an Attachment. - Chilkat's Behavior: To ensure no data is lost and the programmer can access the file in whichever way they prefer, Chilkat counts it as both. You will find it in the list of attachments and the list of related items.
Scenario B: Inline Disposition but no HTML Reference
An item might have Content-Disposition: inline and reside in multipart/related, but the HTML body does not actually reference its Content-ID.
- The Conflict: Strictly speaking, it is structured as a related item. However, since it isn't visually rendered (because the HTML doesn't link to it), it behaves effectively like an attachment.
- Chilkat's Behavior: Chilkat may expose this as an attachment to ensure the user sees the file, while still retaining its status as a related item due to its MIME structure.
Summary Table
| Feature | Attachment | Related Item | Both (Overlap) |
|---|---|---|---|
| MIME Parent | multipart/mixed |
multipart/related |
multipart/related |
| Disposition | attachment |
inline |
attachment (usually) |
| Content-ID | Usually missing | Present | Present |
| HTML Usage | Not referenced | Referenced via cid: |
Referenced via cid: |
Practical Advice
If you are iterating through attachments and want to avoid saving embedded images (duplicate files), you can check if an attachment is also a related item:
- Check
Content-ID: If an "attachment" has a Content-ID, it is likely a related item. - Check
Content-Disposition: If the disposition is "inline", it is likely intended to be viewed in the body, not saved as a file. - Compare Collections: You can verify if the attachment's filename or size matches an entry in the "Related Items" collection to filter out duplicates.