Architecture
Four principles#
Never store the mail. The hosted relay is an SMTP proxy without a queue: a message lives in memory for one SMTP transaction and nowhere else. If you want even that avoided, the same signing engine runs on your own server as a milter next to your Postfix.
Never break or lose the mail. Signing fails open per message. Any error, timeout, unknown
structure or oversized message passes through unmodified. On Postfix,
milter_default_action = accept means Postfix itself guarantees this even when the milter is
gone.
Render when something changes, not when mail is sent. Signatures are compiled per user when directory data, templates, rules or campaigns change. On the mail path there is only a lookup and an insertion; no database query and no rendering sits between a user and their outgoing mail.
Standalone first, ecosystem-native second. Every ScaiLabs product you add (ScaiKey, ScaiSend, ScaiVault, ScaiLog, ScaiDNS, ScaiControl) makes ScaiLine better; the mail-flow components do not depend on them at send time.
Components#
| Component | Role | Where it runs |
|---|---|---|
scailine-stamp |
The signing engine: analyses the message structure, decides whether to skip, inserts the HTML and text signature, and changes nothing else. The only code that ever modifies a message. | Inside every mail-flow component below |
scailine-milter |
Milter for Postfix, with a signed local copy of the organisation's signatures. | Next to your Postfix |
scailine-relay |
Hosted SMTP proxy for Microsoft 365. No queue, in memory only. | ScaiLabs relay tier, EU |
| ScaiSend stage | The same engine inside ScaiSend's delivery worker. | ScaiSend |
scailine-api |
Control plane: organisations, domains, directory sources, templates, rules, campaigns, legal entities, roles, mail-flow connections. | ScaiLabs, EU |
scailine-worker |
Directory sync, compilation, publishing, relay certificates, Microsoft 365 address ranges, statistics. | ScaiLabs, EU |
| Console | Administration, template designer with preview, My signature. | Browser |
scailine-outlook-addin |
Signature in the Outlook compose window, so Sent Items show it too. | Outlook (in development) |
The mail path#
- Guard. A size cap (25 MB) and a per-message deadline (1.5 s). Exceeding either means the message passes unmodified.
- Scan. A map of the message's parts is built without decoding any content.
- Skip. Signed or encrypted mail (S/MIME, PGP, Microsoft Purview), TNEF, calendar
traffic, automatic replies and delivery reports, messages already carrying a valid
X-ScaiLineheader, unknown senders and tenant skip rules are deliberately left alone. - Locate. The plain-text and HTML body parts are found in the usual structures. Anything unrecognised means pass-through; attached messages are never entered.
- Classify. New message or reply, and internal or external recipients.
- Select. The matching compiled variant:
external.new,external.reply,internal.neworinternal.reply. If the Outlook add-in already inserted the signature, only the remaining parts (legal footer, banner) are applied. - Insert. The HTML is inserted at the right position, above the quoted text in replies, without re-writing the rest of the HTML. Only the modified parts are re-encoded; every other byte, attachments included, stays identical.
- Images. Images the template marks as inside the message are added as related parts next to the HTML, so they display without the recipient allowing downloads (Templates).
- Header. One
X-ScaiLineheader records what happened (reference).
The markers that identify quoted text per mail client are data inside the compiled signatures, so a new client quirk is fixed by publishing new data, not by upgrading servers.
Getting compiled signatures to the mail path#
The worker compiles a signature per user and publishes it. The hosted relay keeps an in-memory cache and keeps serving from it if its store is briefly unreachable. The milter pulls a signed snapshot of the organisation (Ed25519) over HTTPS, verifies it and keeps the last good one on disk, so it keeps signing mail through control-plane outages for as long as they last.
Microsoft 365 attribution#
On the hosted relay a message is attributed to an organisation only when all three hold:
- it arrives over TLS from Microsoft's mail servers (Exchange Online Protection), whose address ranges ScaiLine takes from Microsoft's published list and refreshes daily;
- the sender's domain is verified for that organisation;
- the
X-MS-Exchange-CrossTenant-Idheader matches the organisation's registered Microsoft 365 tenant.
A failure is rejected with a 5xx and never passed through. This is the one deliberate exception to failing open: nobody else's Microsoft 365 tenant may route mail through your signature configuration. Signed mail goes back to your tenant over a connection that presents a certificate unique to your organisation, as Microsoft requires. See Microsoft 365.
Shadow mode (hosted relay)#
For a Microsoft 365 connection, shadow mode runs the full pipeline and records outcome and variant (metadata only) while the original message is delivered. Pilots start there. The milter has no shadow mode; pilot it by limiting a rule to a small group (Rules).