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-Disposition header set to "attachment".
      • It is located in a multipart/mixed block (indicating it is separate from the body).
      • It is a file type that does not participate in the visual rendering of the HTML body.
  • 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/related MIME structure.
      • It possesses a Content-ID or Content-Location header.
      • The HTML body references this ID (e.g., <img src="cid:image001@domain.com">).
      • It typically has a Content-Disposition of "inline" (though not strictly required if other criteria are met).

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/related location and Content-ID tell Chilkat it is a Related Item (it's needed for the HTML). However, the header Content-Disposition: attachment explicitly 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:

  1. Check Content-ID: If an "attachment" has a Content-ID, it is likely a related item.
  2. Check Content-Disposition: If the disposition is "inline", it is likely intended to be viewed in the body, not saved as a file.
  3. Compare Collections: You can verify if the attachment's filename or size matches an entry in the "Related Items" collection to filter out duplicates.