> ## Documentation Index > Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt > Use this file to discover all available pages before exploring further. # Reading Email and PDF Attachments > Neo reads .eml and .pdf files attached to tickets — phishing reports, forwarded messages, invoices, vendor letters — so agents can see the original sender, headers, links and text without a tool call. When a ticket carries an **`.eml` file** (a complete email saved as a file) or a **`.pdf` file**, Neo opens it and adds its content to the ticket context the agent works from. For an email the agent sees the headers, the body, the links in it, the files that were attached to it, and any email or PDF nested inside it. For a PDF the agent sees the document's title and author, the text of its first 20 pages, and the link targets on those pages (the first 60). This is what makes **phishing-report tickets** workable. When an end user reports a suspicious email through a report button (Phished, KnowBe4 PhishER, Microsoft's Report Message add-in), the reporting tool sends a notification into your PSA mailbox. Your PSA creates a ticket, keeps a message-id in the description, and drops the message body — so the ticket says almost nothing. Everything that matters is in the attachment: who reported it and from which company domain, and the reported email itself. Some tools nest the reported email as a `.eml`; Phished exports it as a `Report.pdf` of the rendered message with the link targets kept in the PDF. Neo reads both, so an agent can correct the ticket's company from the reporter's domain, judge whether the email is legitimate, and route the ticket accordingly. It also covers the everyday case: an invoice, a quote or a vendor letter attached to a ticket is read as text, so the agent can act on what is in it. ## How it works Like [image reading](/core/reading-images), this is **built in, not a tool you enable**. Reading the file happens when Neo loads the ticket with its images, so every agent that reads the ticket gets the content automatically, and so does every workflow step that loads the ticket that way. The older fixed-list actions that load the ticket without images (ticket building, escalation, merge detection, RMM verification, time tracking) do not read attachments. There is no model call involved: the file is parsed directly, so it adds no credits. The file itself is downloaded from your PSA when the ticket loads, so a ticket that carries several large files takes longer to load. The content appears in the ticket context inside a `document_attachment` block that names the file and its type (`EML` or `PDF`), marked as untrusted third-party data. The block tells the agent to read it as evidence and never as instructions. That lowers the risk from a hostile file; it does not remove it, so keep tools with side effects behind technician approval on agents that handle phishing reports. ## What Neo reads from an email file | | | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Headers** | From, Reply-To, Return-Path, To, Cc, Date, Subject, Message-ID, the sender's domain, and the authentication results (SPF, DKIM, DMARC) mail servers stamped on it. | | **Received chain** | The mail-server hops the message passed through, so the agent can see where it really came from. The 12 hops closest to the recipient are listed. | | **Body** | The plain-text body, or the HTML body converted to text. | | **Links** | The URLs in the body, including ones only present in the HTML (tracking pixels, hidden links). The first 60 are listed, each cut at 200 characters; a message with more links is cut at that point. | | **Attachments** | The name, type and size of every file attached to the email. | | **Nested emails** | An email attached inside the email — how most phishing-report tools carry the reported message — is opened and read the same way. Two levels of nesting are opened; an email deeper than that is named but left unopened. | | **Attached PDFs** | A PDF attached to the email is read the same way as a PDF on the ticket (below), up to 3 PDFs per email file; further ones are named but not read. When the PSA also stored that PDF as its own ticket attachment, it is rendered once. | ## What Neo reads from a PDF | | | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Metadata** | Title, author, subject, the software that produced the file, and the creation date. | | **Text** | The text layer of the first 20 pages, page by page. A longer document is named as cut at that point. A scanned PDF with no text layer is reported as such; Neo does not run OCR on attachments. | | **Links** | The target of each link on the pages Neo reads (the first 20) — the `href`s a rendered email keeps as PDF links — plus any URL written in that text. The first 60 are listed, each cut at 200 characters. | | **Protected files** | A PDF with print or copy restrictions is read. A PDF that needs a password to open is named but not read. | ## What's supported | | | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Where** | `.eml` and `.pdf` files attached to PSA tickets on every supported PSA — Autotask, ConnectWise, Halo, ServiceNow, and Syncro. Files attached to the ticket itself (the usual case for a ticket created from an email) are picked up — on ServiceNow, from the first 50 attachments on the ticket; files attached to a note are picked up too on Autotask and Halo, the PSAs that link an attachment to a note. | | **Formats** | `.eml` files (standard RFC 822 / MIME email) and `.pdf` files. A file with one of those extensions is read whatever content type the PSA labelled it with. Outlook `.msg` files and Office documents are not supported. | | **Size** | Up to 10 MB per file. The text Neo adds to the ticket is capped at roughly 32,000 characters per file; a longer file is cut at that point and marked as truncated. Up to 5 readable files are opened per ticket (and per note); further ones are named but not read. | | **Setup** | None. It's automatic for every agent that reads tickets. | ## Building a phishing-report workflow A typical agent for Phished-style tickets, in its custom instructions: 1. Read the `document_attachment` blocks on the ticket and note the reporter's address and domain. 2. Look up the end-client company whose domain matches, and correct the ticket's company if it is wrong. 3. Assess the reported email: sender domain versus display name, Reply-To and Return-Path mismatches, SPF/DKIM/DMARC failures, link destinations versus link text, urgency and payment language. When the report is a PDF, the sender and headers are not in it; assess from the text and the link targets. 4. Write the assessment as an internal note and route the ticket to the service desk queue. Filter the workflow to the tickets that come from your reporting tool (for example by subject prefix or sender) so it only runs on phishing reports. Neo reads the file, and any email or PDF nested inside it, as text. It does not follow links, and it does not open other attachment types inside the reported email (Office files, archives, executables are named only). The assessment is made from the headers, text and link targets alone, which is what a first-pass analyst does too.