Email attachments
The MIME parser records each enclosure's name, declared media type and byte size against the canonical message, and that list is shown beside the body. The bytes themselves are not kept, so an enclosure cannot be opened from inside Connect and its contents do not ground a reply. Putting a document into the workspace is a separate, deliberate act.
What the parser records#
A MIME message is a tree of parts. The parser walks it, takes the first text/plain part as the body and the first text/html part as the rich body, and treats any part whose Content-Disposition says attachment as an enclosure. Three values are stored for each, and nothing else.
| Field | Where it comes from | What it is for |
|---|---|---|
filename | The part's own filename header, decoded. The literal word attachment where the sender supplied none. | The name shown beside the message. |
content_type | The media type the sender declared. | The label and the icon. A claim by the sender, not a verdict by Connect. |
size | The length of the decoded payload, measured while parsing. | So a reader can tell a signature logo from a forty-page proposal. |
That list travels with the canonical message, so the Owner's thread pane and a customer's conversation view show the same three columns out of the same row. On the IMAP path the enclosure parts are skipped entirely while the body is extracted, which is why a message whose whole content was a PDF shows an empty body and one named item.
What is not kept, and why this page says Foundation#
The bytes are not stored. No route downloads an enclosure from a message, nothing copies it into the workspace's own storage, and nothing indexes its contents. What runs in production is the record of what arrived. The capability a reader might assume from the word — open it, search it, answer out of it — is deliberately narrower than that, and calling this page Available would imply otherwise.
The line sits there on purpose rather than by omission. Keeping every document anyone emails a business means keeping everything anyone chooses to send it, including material the business never asked for and would rather not hold. A person deciding what belongs in the workspace is a better filter than a rule that keeps all of it.
When the enclosure was the message#
A draft is grounded in approved Knowledge, in memory about the person and in the text of the conversation — see How a reply is drafted. A message whose meaning lived in a PDF therefore reaches the drafting step with almost nothing to read, and what comes back is written from the covering note alone. Those are the threads worth checking before approving.
- Give the thread a one-line direction saying what the document contains — Giving guidance on a thread.
- Or save it out of the mailbox and add it through Files and data in Connect, the one service both audiences and the Assistant share.
- Link it to the person, deal or case it belongs to, so it appears on that record rather than only in a list.
- Then ask a question of it, or have a new version produced from it, through Connect Assistant.
Anything added that way is classified before it is stored: a format that cannot be read is refused with the reason, documents declaring external entities are refused rather than parsed carefully, and an archive that expands unreasonably stops expanding. A declared media type on a message gets none of those checks, because nothing is opened.
On the way out#
Connect does not enclose anything with the replies it writes. The guardrail that says so is on by default, and the drafting instructions never offer an enclosure as something a reply may carry. A reply that needs a document beside it is one for a person to send, or one where the document is a link to somewhere the recipient can already reach.
Cold outreach is stricter again: nothing enclosed, no tracking pixel, no invented Re: or Fwd: prefix, plain text within a fixed length. That restriction is about being read rather than about safety — see Outreach email versus a customer reply.
Questions#
Can I open a document from inside Connect?
Not from a message. The name, media type and size are shown; the bytes are not held, so there is nothing to open. Open it in the mailbox, and add it to the workspace if it should live there.
Does an image enclosure get proxied like a remote image?
It is not fetched at all, because nothing about it is retained beyond the three fields above. Proxying exists for images a message points at on someone else's server — see Remote images in email.
Why not simply keep everything that arrives?
Because that means holding whatever anyone chooses to send the business, indefinitely, including material it never asked for. The narrower behaviour is the deliberate one, and this page says so rather than describing a capability that is not there.