---
title: "parse message · RUAL Documentation"
description: "Parses a raw RFC 822 / RFC 5322 message into addresses, subject, bodies, attachments and headers. Feed it the raw body of an inbound-mail webhook : http…"
canonical: https://docs.rual.nl/block-types/mail/mail_parse
language: en
---

[Cluster](https://docs.rual.nl/cluster)

[Blocks](https://docs.rual.nl/block-types)

[Interfaces](https://docs.rual.nl/interfaces)

[Blueprints](https://docs.rual.nl/blueprints)

[Blueprint Language](https://docs.rual.nl/engine)

[Tutorials](https://docs.rual.nl/tutorials)

[Home automation](https://docs.rual.nl/home-automation)

[Examples](https://docs.rual.nl/examples)

[Reference](https://docs.rual.nl/reference)

[Architecture](https://docs.rual.nl/architecture)

[Troubleshooting](https://docs.rual.nl/troubleshooting)

Other

# parse message

This block is part of the [`mail`](https://docs.rual.nl/block-types/mail) group and was last modified in core [`v15.0.1`](https://docs.rual.nl/core-versions/150001).

Parses a raw RFC 822 / RFC 5322 message into addresses, subject, bodies, attachments and headers. Feed it the raw body of an inbound-mail webhook : `http connection get raw body` : or a stored `.eml` file.

- flow `flow`

- raw `value` The raw message, headers and body, exactly as received.

- file `file` Read the raw message from a stored file instead of the `raw` pin. Ignored when `raw` is filled.

- max attachment bytes `number` Per-part ceiling on decoded attachment content. A larger part keeps its metadata and is reported with `truncated: true` instead of its bytes.

Default `26214400`

- include content `condition` On (the default) attachments carry `content_base64`. Off gives name, type and size only : use it when you only need to list what came in.

Default `true`

- trusted authentication results `value` The `Authentication-Results` value your own MTA produced, handed to the flow SEPARATELY from the message (for the mssgs mail pair: the `X-Authentication-Results` header on the `mail/inbound` call, expanded from Exim's `$authresults`). When set it is the only source of `authentication` and no header inside the message is read, so a header a sender wrote cannot be mistaken for the verifier's. Reported with `source: trusted`.

- authserv-id filter `value` When nothing came in through `authentication_results`, only an in-message `Authentication-Results` header whose authserv-id (its first token, e.g. `mx1.mssgsmail.com`) matches this is read, and `Received-SPF` is not consulted. This is a FILTER, not authentication: a message header says nothing about who wrote it, so it is only as good as an ingress that always prepends its own header and strips inbound ones claiming its id (RFC 8601 §5). Such verdicts are reported with `source: message`; a flow that needs certainty passes the verdict out of band instead.

- flow `flow`

- success `condition`

- error `value`

- message `object`

Pure parser: reads one raw email and outputs a structured message object. No network, no store writes. message = { from {name,email}, to[], cc[], bcc[], reply_to[], subject, date (epoch ms, null when missing or unparseable), message_id (angle brackets stripped, null when absent), in_reply_to, references[], text, html, attachments[{name,content_type,size,content_base64,inline,cid}], headers (lowercased name -> string, or an array of strings for a header that repeats), size, spam_score, authentication {dkim,spf,dmarc} }. authentication is reported, not verified: with authserv_id set only the Authentication-Results header written by that verifier is believed and Received-SPF is ignored; empty believes the first header. text is derived from the HTML when the message carries no text/plain part; html is null for a text-only message. Handles nested multipart, base64 and quoted-printable, RFC 2047 encoded words, RFC 2231 filenames, and UTF-8 / ISO-8859-1 / ISO-8859-15 / windows-1252 charsets. A message/rfc822 sub-part is kept whole as one attachment. Garbage in never panics: a truncated or binary body parses as far as it can and reports success=false with a message on error rather than failing the flow.

| `email` |
| --- |
| `rfc822` |
| `eml` |
| `mime` |
| `inbound` |

A typical wiring for [parse message](https://docs.rual.nl/block-types/mail/mail_parse): a [function trigger](https://docs.rual.nl/block-types/globals/trigger_custom_function) starts the flow; the `flow` out pin feeds [debug](https://docs.rual.nl/block-types/state%2520ui/state_debug).

[![Studio canvas example for the parse message block: typical wiring for parse message.](https://docs.rual.nl/canvas-examples/mail_parse.png)](https://docs.rual.nl/canvas-examples/mail_parse.png?v=3)

## Version history

Introduced in [`v15.0.1`](https://docs.rual.nl/core-versions/150001).

- [Back to `mail`](https://docs.rual.nl/block-types/mail): Return to the main group to view all sub-groups

- [Back to `mail`](https://docs.rual.nl/block-types/mail?group=mail): Return to the group to view all blocks within this group

Was this page helpful? [Tell us what to improve](https://docs.rual.nl/support) · RUAL Docs is an integral component of the [RUAL ecosystem](https://rual.nl)