Mailbox — reading and sending email | ATX AnalyticsTable Handbook

Mailbox — reading and sending emailSix providers, two pipeline steps, and an alert that knows it already told you. A mailbox is two things to a reporting tool, and ATX AnalyticsTable treats them as two: it is a place results go, and it is a place data comes from. Sending turns a pipeline into a delivery mechanism — the morning pack, the exception list, the alert that fires only when a number crosses a line. Reading turns an inbox into a table: a daily delivery note, a supplier's attachment, a stream of subjects worth counting. Both run through a mail profile, which is stored exactly like a database connection — the address and the user name live in a file you can read, the password lives in the encrypted vault — and both are available as pipeline steps, so they schedule and run unattended like everything else.

What it does

Four ways to send: SMTP to any relay, Microsoft Graph, MailerSend and Azure Communication Services — all cross-platform
Three ways to read: IMAP and Microsoft Graph anywhere, plus the Outlook desktop client on Windows, which reaches whatever the signed-in user can already see, including shared and group mailboxes, with no separate credential
A hand-rolled SMTP client covering STARTTLS and implicit TLS, PLAIN, LOGIN and CRAM-MD5, with certificate verification on by default and authentication over an unencrypted socket refused unless explicitly allowed
A read step that returns a fixed twenty-column table — received time, sender, subject, recipients, body preview and body, attachment names, folder, mailbox, flags and identifiers — so downstream steps can rely on the column names
Mailbox filters: folder, date range, unread only, sender, subject and body contains, has attachments, and a hard message limit that is always sent
Templated subjects and bodies with project parameters and run tokens — pipeline name, run time, row count, a named column, an aggregate such as SUM over a column, and the table itself as HTML or text
Attachments built in the product: the result table as CSV, Excel or HTML, plus files from disk, checked against a per-profile size ceiling
Recipient guardrails: a maximum per message, an allow-list of recipient domains, and a refusal to send when the table is empty
Alerts with conditions — row count, an aggregate crossing a value, any single row breaching, data arriving for a new period, or the data simply changing — with cooldown, send-once-per-change suppression, a daily maximum and an optional recovery message
Standalone alert rules that watch a pipeline, a saved query, a connection query or a grid range on their own schedule, without a pipeline around them — see chapter 22, Alerts
Ask Greg can propose an alert rule, and says before you place it whether it would fire today — recipients limited to addresses you typed, your own, or existing alert recipients

How it works

A mail profile is created in Settings under Email. You choose a type once — it cannot be changed afterwards — and the fields change to match it: host, port, encryption and authentication for SMTP; host, port and default folder for IMAP; a mailbox mode for Outlook; tenant, client and mailbox for Graph; an endpoint and a verified sender for MailerSend and Azure.
Test connects, authenticates and disconnects. It never sends a message, because "the relay rejected my password" and "the relay accepted me but refuses to relay to that domain" are different problems and deserve different buttons — a separate Send a test message covers the second.
Reading is an ordinary step: it does its work when the pipeline runs and writes the messages into the bound table, either replacing it or appending, with column names in the first row if you ask for them.
Marking messages as read is off by default, and it is the only setting on the step that changes the mailbox rather than reading it. IMAP opens the folder read-only unless you turn it on, so a preview cannot quietly mark a person's mail as seen.
Sending is an effect, not an ordinary step. Stepping through a recipe previews each step, and a preview that emails forty people is not a preview — so the send step evaluates its condition and renders its message during the walkthrough but the message itself is only dispatched by a real run.
The message carries a snapshot of the rows as they were at that point in the recipe, so a recipe that reads, filters, sends, aggregates and sends again mails two different datasets rather than the same one twice.
Alert state is remembered between runs — the last period seen, the last fingerprint of the data, whether the condition was met last time, when it last fired and how many times today — so "only when it changes", a cooldown and a daily cap all mean what they say across runs and across restarts.
A send that some recipients accept and others reject is reported as a partial success with the rejected addresses named. It is a warning, not a failure: a relay refusing the fourth address should not discard three delivered messages.

Practices that keep it reliable

Leave mark-as-read off unless the recipe genuinely owns the mailbox — nothing undoes it
Set an allow-list of recipient domains on any profile a scheduled pipeline can reach; it is the cheapest protection against a templated recipient going somewhere unintended
Turn on "only when it changes" and a cooldown before the first alert goes live, not after the first morning of forty identical messages
Preview the message in the step dialog — an unrecognised token is left exactly as written, which is visible in a preview and embarrassing in an inbox
Prefer Graph or IMAP for anything scheduled; the Outlook route needs the desktop client running as that user on that Windows machine

In a regulated environment

Credentials live in the same encrypted vault as database passwords, under their own namespace, and there is no endpoint anywhere that returns one — a stored password can be replaced but never read back.
The mail configuration file is an allow-list of public fields, so a password posted into it cannot land in plaintext beside the host name.
The Outlook route never builds a script from user input: PowerShell is invoked with a fixed, constant command and the query travels in an environment variable, so a subject line can never become a command.
Nothing sensitive reaches a log. Authentication exchanges are redacted, the message body between DATA and its terminator is omitted entirely, and the audit line records the profile, host, transport, recipient counts, accepted and rejected totals, size, provider message id and duration — with only the first recipient, masked.
Certificate verification is on by default, with an explicit certificate-authority path for the usual corporate private root. Turning verification off is a deliberate, visible, per-profile choice, and authenticating over an unencrypted socket is refused outright unless separately allowed.
Sending, mailbox reading and alerts are three separate licence components with a daily message limit, so an installation can be entitled to alerts without being entitled to bulk delivery. Profile management and testing are deliberately not gated, so a mailbox can be configured before it is licensed.
Send and read endpoints are rate-limited per minute, and a daily send ledger keeps today and yesterday only — enough to enforce a cap, not enough to become a record of who was emailed.

Screens

Settings, Email — a mail profile stored like a database connection: the address in a file you can read, the password in the vault.
Read email — a mailbox as a data source, with filters, a hard message limit, and mark-as-read off by default.
Send email — when to send, who receives it, the templated message, and the table attached as CSV, Excel or HTML.
Alert rules — a condition watching a pipeline, a query or a grid range on its own schedule, with cooldown and recovery.

Related guides

Automated Excel & scheduled reports

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.