Exporting Matched Email to EML or Text Files for Other Processes to Pick Up

Webhooks and REST APIs (see event-driven email workflows and the REST API guide) are the right tool when the downstream system can speak HTTP. Plenty of real integrations cannot: a legacy line-of-business application that only knows how to read files from a directory, a batch job that runs on a schedule and scans a folder, a document-processing or OCR pipeline built around watching a directory, or a script someone wrote years ago that still works and nobody wants to rewrite.

For exactly this case, matching email can be written straight to disk as an individual file — either the full original message (MIME/.eml) or a plain text extraction — in a folder that any process on the same machine or network share can poll or watch, on Windows or Linux, with no email protocol knowledge required on the receiving end at all.

The Developer module now supports this directly as an action on its own rule engine, alongside webhooks — the same rule that could fire an HTTP callback can instead (or additionally) write the matching message to a file on disk. That means a single rule set can drive a webhook for one system, a file drop for another, and normal delivery to a mailbox, all from one match, without needing the POP3 Reader or Archiver modules just to get a file onto disk.

Exporting every message that ever arrives to disk is rarely what you want — it is usually a specific subset that some other process cares about. The same rule engine used for routing and tagging (see automatic email tagging) decides what qualifies for export, using the same conditions:

• Sender or recipient — export only mail to or from specific addresses, e.g. an orders@ address that feeds a warehouse system.
• Subject or content phrases, including wildcards — export mail matching a known pattern, such as a purchase order number format or a specific document type.
• Attachment presence or type — export only messages carrying attachments a downstream process actually needs (invoices, scanned documents), leaving plain correspondence alone.
• Sending IP, MIME headers, size, date/time — the same fine-grained conditions available for routing apply equally here, so exporting can be as narrow or broad as the receiving process needs.

Exporting can run alongside normal delivery — the message still reaches its mailbox as usual, and a copy also lands on disk — rather than being an either/or choice.

Which format to write depends entirely on what the receiving process expects:

• MIME / .eml preserves the message exactly as received — headers, HTML/plain-text body parts, and attachments all in one file. Use this when the downstream process needs the full message (attachments included), needs to prove what was actually sent/received, or itself understands MIME parsing (many document-processing and email-archival tools accept .eml directly).
• Plain text extracts just the readable content — useful when the receiving process is a simple script, a log analyser, or a legacy system that has no MIME parser and just wants to grep or index the text body.
• Attachments as separate files can be exported alongside the message body, which matters for pipelines built around processing the attachment itself (an invoice PDF, a scanned form) rather than the email wrapper around it.

If you are not sure which the receiving system wants, export MIME — a .eml file can always be reduced to plain text or have attachments pulled out of it later; a plain-text export cannot be turned back into the original message.

The folder side of this pattern is simple, but a few details avoid common failure modes:

• One file per message, uniquely named. Include a timestamp or message ID in the filename so two messages never collide and so the receiving process can process files in arrival order if that matters.
• Write, then rename, rather than writing in place. If the exporting process writes directly to the final filename, a watcher polling the folder can pick up a half-written file. Writing to a temporary name and renaming once complete (or having the watcher ignore partial extensions) avoids reading a truncated message.
• Decide who deletes the file. Either the receiving process moves/deletes files once processed (the usual "hot folder" pattern), or a separate cleanup job removes files older than a retention window — without one of these, the folder grows forever.
• Use a network share carefully. Writing to a folder shared between a Windows mail server and a Linux processing script (or vice versa) works fine over SMB/NFS, but confirm both sides handle file locking and permissions the same way, especially under load.
• Monitor the folder itself. If the receiving process stops running, files pile up silently — an alert on folder size or oldest-file-age catches this before it becomes a backlog nobody noticed.

How the other end notices a new file depends on the platform and how quickly it needs to react:

• Linux — inotifywait (from inotify-tools) or a language-level filesystem-watch library gives near-instant notification of new files; a simple cron job polling the directory every minute is often good enough when instant pickup is not required.
• Windows — a FileSystemWatcher in .NET or PowerShell gives the equivalent instant notification; a Scheduled Task polling the folder is the low-effort alternative.
• Cross-platform / simplest option — a polling script in Python, Node.js or similar checking the folder every N seconds works identically on both operating systems and is usually the easiest to get right first, with instant-notification watchers as a later optimisation once the basic pipeline is proven.

Whichever mechanism you choose, process files defensively — skip anything still being written, handle a file that fails to parse without crashing the whole watcher, and log what was picked up so a missing file is traceable later.

All three integration styles solve the same underlying problem — get matching email out to another system — with different trade-offs:

• File export needs no networking or authentication on the receiving side, works with legacy or offline systems, and is trivial to debug (open the file). It is push-with-delay by nature — the receiving process has to notice the file rather than being told immediately.
• Webhooks (see event-driven email workflows) notify a system the moment a match occurs, but require that system to expose an HTTP endpoint.
• The REST API (see the REST API guide) is best when your own application needs to pull data or push configuration on demand, rather than being told about individual messages as they arrive.

Because file export now lives on the same rule engine as webhooks inside the Developer module, this is less of an either/or choice than it used to be: one rule can write a file for the legacy system that only reads a directory and fire a webhook for the modern service that accepts an HTTP callback, from a single match, configured in one place rather than stitched together across separate modules.

The Developer module (in Hexamail Nexus, Hexamail Guard and Hexamail Server) now supports file export as an action on its own rule engine alongside webhooks, so a single rule can write matching email to disk as MIME or plain text — with attachments as separate files — without needing a separate module just for that. Where the older, module-specific options still apply: the POP3 Reader module can export matching email to files as part of collecting from external accounts, and Hexamail Vault's Archiver module offers the archive-side equivalent — automated export of email matching complex criteria to directories or zip files, for litigation, audit, or feeding a separate document pipeline. All of these write plain files to a folder on Windows or Linux — no API client or webhook receiver required on the other end.