SpiderMail
← Back to Blog From MIME to YAML: How SpiderMail Structures Email for Agents

From MIME to YAML: How SpiderMail Structures Email for Agents

Daniel Korshak Daniel Korshak 3 min read
Copied!

The average marketing email contains 847 lines of HTML. An LLM sees every single one of them.

That's not just wasteful — it's a design failure. When 90% of your context window is consumed by <table> tags and tracking scripts, there's no room left for reasoning.

We built SpiderMail to solve this. Here's how we convert raw MIME into clean, typed YAML that any AI agent can consume.

The Problem with Raw MIME

A typical email arrives as a MIME multipart message with content boundaries, nested HTML tables, inline CSS, tracking pixels, and base64-encoded attachments. The actual information content might be just seven words buried in hundreds of lines of markup.

The SpiderMail Pipeline

Our processing pipeline has four stages:

Stage 1: MIME Parsing

We decode the MIME structure and extract all parts. Multipart messages are unwound, character encodings are normalized, and each part is classified:

  • text/plain → Primary content

  • text/html → Secondary (stripped to text)

  • application/* → Attachment reference

  • image/* (inline, < 10px) → Tracking pixel (discarded)

Stage 2: HTML Sanitization

The HTML part goes through our security pipeline:

  1. Parse DOM tree

  2. Remove all <style>, <script>, <link> tags

  3. Remove hidden elements (display:none, zero-size, off-screen)

  4. Strip tracking pixels and beacon images

  5. Extract visible text content only

  6. Run prompt injection detection

Stage 3: Metadata Extraction

We parse email headers into typed fields. Addresses are decomposed into name/email objects. Dates are normalized to ISO 8601. Threading fields are preserved for conversation reconstruction. Authentication headers (SPF, DKIM, DMARC) are summarized into a trust score.

Stage 4: YAML Output

The final output is a clean, typed YAML document:

message_id: "<abc123@mail.vendor.com>"
thread_id: "thread_9f8e7d6c"
from:
  name: "Vendor Billing"
  email: "vendor@example.com"
subject: "Invoice #4521 - Payment Due"
date: "2026-04-15T14:30:00Z"
body_plain: |
  Your invoice is attached.
attachments:
  - filename: "invoice-4521.pdf"
    content_type: "application/pdf"
    size_bytes: 89432
security:
  spf: "pass"
  dkim: "pass"
  trust_score: 0.95
  injections_detected: 0
  tracking_pixels_removed: 1
tokens_saved: 1847

From 847 lines of HTML to 28 lines of structured data. That's a 97% reduction in token usage.

Why YAML?

We chose YAML over JSON for three reasons:

  1. Readability — YAML is more natural for LLMs to parse, with less syntactic noise

  2. Multiline strings — The | block scalar cleanly handles email body text without escaping

  3. Comments — We can annotate security findings inline

Integration

SpiderMail delivers YAML payloads via webhook, API polling, or direct MCP tool integration:

npx -y @spideriq/mcp-mail@latest

Your agent gets an MCP tool that returns clean, typed email payloads — ready for reasoning, not parsing.

The best token is the one you never spend. Stop burning context on HTML tables. Start processing clean payloads.

← Back to Blog