API Reference sovite v#0.2.0

Copy Markdown View Source

Modules

Sovite, a Mail Transfer Agent written in Elixir/OTP.

Counts failures per key (for example failed logins per client address) and bans a key for a while after too many of them.

Keeps an ACME certificate ([tls.acme]) issued and renewed.

The bounce service: tells senders about failed and delayed delivery.

The sovitectl command line.

Loads, validates, and stores the Sovite configuration file.

A single configuration problem.

Delivers one job (a message to a group of recipients with the same destination). Runs in a task started by Sovite.Core.QueueManager.

Configures logging from the [log] config section.

:logger handler that writes to rotating log files, in the style of pino-roll.

:logger formatter that writes one JSON object per line.

The interface routing uses to read Sovite's database tables (Sovite.Core.Repo.Tables.*): a key goes in, a string value or nothing comes out.

Schedules queued messages for delivery, like Postfix's qmgr.

Recipient expansion and validation.

Sovite's database, through Ecto.

An access rule for the restriction chains (Sovite.Core.Restrictions): when the client address, EHLO name, sender, or recipient (kind) matches pattern, take action (ACCEPT, CONTINUE, REJECT, DEFER, DISCARD, HOLD, WARN, or a 4NN/5NN reply code) with optional text.

An address rewrite: addresses matching pattern (a full address, @domain, or a local part) become replacement (a full address, @domain to change only the domain, or a local part to change only the local part). kind says which addresses: :sender, :recipient, or :both.

An alias: mail for address goes to its destinations instead. address is a full address, @domain (every address of the domain that has no alias of its own), or a bare local part (for local domains).

One address an alias delivers to.

A BCC rule: messages whose sender (kind: :sender) or one of whose recipients (kind: :recipient) matches pattern (a full address, or @domain) are also sent to address.

A domain this server handles, and its class (see Sovite.Core.Routing): :local, :aliased, :hosted, or :relay.

A mailbox in a virtual mailbox domain: address, or @domain to accept every address of the domain.

A user who moved: mail for address is rejected with 5.1.6 and new_location (usually the new address).

A sender address a user may use in MAIL FROM: a full address (sales@example.com), every address at a domain (@example.com), or any address (*).

How mail from sender (an address, or @domain) leaves: through relayhost, from source_address, logging in with username and password. Each part is optional.

A transport map entry: mail for pattern (an address, a domain, .domain for its subdomains, or *) goes through transport, a Sovite.Core.Transport specification.

A user who can authenticate (SMTP AUTH), with the sender addresses they may use.

Access rules for the restriction chains, stored in Sovite's database and managed with sovitectl access.

Address rewrites stored in Sovite's database, managed with sovitectl rewrite (see Sovite.Core.Rewrite).

Aliases stored in Sovite's database, managed with sovitectl alias.

BCC rules stored in Sovite's database, managed with sovitectl bcc (see Sovite.Core.Recipients.bcc/3).

Keeps the domains of Sovite.Core.Repo.Tables.Domains in :persistent_term, so every recipient check can read them without a database query.

Domains stored in Sovite's database, managed with sovitectl domain. They add to the domains in the [domains] config section; a domain in the config file wins over the same domain in the database.

Mailboxes of virtual mailbox domains, stored in Sovite's database and managed with sovitectl mailbox.

Users who moved, stored in Sovite's database and managed with sovitectl moved. Mail for them is rejected with 5.1.6 and their new location.

Sender-dependent relaying, stored in Sovite's database and managed with sovitectl sender-relay: for a sender address or @domain, the relay host, the source address to connect from, and the credentials for the relay host.

Transports stored in Sovite's database, managed with sovitectl transport.

Users stored in Sovite's database (Sovite.Core.Repo), and a Sovite.SASL.Backend that authenticates against them.

Restriction chains ([restrictions]): lists of checks run at each stage of an SMTP session.

Address rewriting.

Decides, at delivery time, where each recipient's mail goes.

The routing configuration ([domains], [routing], and the next-hop settings of [delivery]) together with Sovite's routing tables in the database, and the address helpers shared by rewriting (Sovite.Core.Rewrite), recipient expansion (Sovite.Core.Recipients), and next-hop selection (Sovite.Core.Router).

The MTA's Sovite.SMTP.Server.Handler: relay control, restrictions, authentication, recipient checks and expansion, and durable spooling.

Sender login maps: which MAIL FROM addresses an authenticated user may use.

Root supervisor of the Sovite MTA.

The catalog of :telemetry events emitted by Sovite, and the default handler that turns them into log lines.

Transport specifications: transport:nexthop.

DNS lookups through a pluggable Sovite.DNS.Resolver.

Default Sovite.DNS.Resolver, built on OTP's :inet_res.

Finds the hosts that accept mail for a domain (RFC 5321 §5.1).

Behaviour for DNS resolvers.

Builds delivery status notifications (RFC 3464), the messages that tell a sender their mail was not delivered (or not yet).

A small layer over OTP's :eldap: connecting with StartTLS or LDAPS, binding, searching, and running all of it in a process of its own.

Parses RFC 4515 LDAP search filters into :eldap filters, with placeholders filled in after parsing.

A TCP listener with an acceptor pool and connection limits.

Behaviour for the process that serves one accepted connection.

Delivers messages into Maildir folders (https://cr.yp.to/proto/maildir.html).

Rewrites the addresses in an RFC 5322 address list (the value of From:, To:, Cc:, and similar fields) and keeps every other byte: display names, comments, groups, and folding.

RFC 5322 §3.3 date-time formatting, as used in Date: and Received:.

The header section of a message (RFC 5322 §2.2), as a list of fields that keeps every byte of the original, so unchanged fields are passed through exactly (folding and all), which matters for signatures.

Builds Message-ID: values (RFC 5322 §3.6.4).

Builds Received: trace header fields (RFC 5321 §4.4).

Trace header fields and the loop checks that read them.

IP address and CIDR network helpers.

Runs an external command with a file as its standard input, for delivery to programs such as procmail, dovecot-lda, or a list manager.

Retry delays for deferred messages (RFC 5321 §4.5.4.1).

The delivery state of a queued message: its envelope, plus the Sovite.Queue.Records appended so far, replayed in order.

The envelope of a queued message: who sent it, to whom, and how it arrived.

Queue IDs: 14 characters from [0-9A-Za-z], safe in file names.

Delivery records, appended to a queue file after the message by Sovite.Queue.Spool.append/3.

Durable storage for queued messages.

SASL authentication (RFC 4422), server and client side.

Behaviour for credential backends used by Sovite.SASL.Server.

A Sovite.SASL.Backend for OAUTHBEARER: checks bearer tokens with OAuth 2.0 token introspection (RFC 7662) at the identity provider.

A Sovite.SASL.Backend that checks passwords by binding to an LDAP directory as the user.

A Sovite.SASL.Backend that reads users from a file, one per line

Hands SASL authentication to a Dovecot auth server, over its client protocol (version 1.2), like Postfix's smtpd_sasl_type = dovecot.

The LOGIN mechanism (draft-murchison-sasl-login): the server asks for Username: then Password:. Obsolete, but some clients (older Outlook versions) offer nothing else. Only safe over TLS.

The OAUTHBEARER mechanism (RFC 7628): the client sends an OAuth 2.0 bearer token (RFC 6750) instead of a password.

Stored password hashes: creating them and checking passwords against them.

The PLAIN mechanism (RFC 4616): [authzid] NUL authcid NUL password in one message. Only safe over TLS.

The SCRAM-SHA-256 mechanism (RFC 5802, RFC 7677).

Runs the server side of a SASL exchange against a Sovite.SASL.Backend.

SMTP (RFC 5321) building blocks.

An SMTP client (RFC 5321) for relaying messages to another server.

Parses SMTP command lines (RFC 5321 §4.1).

Streaming decoder for SMTP DATA content (RFC 5321 §4.1.1.4, §4.5.2).

Streaming encoder for SMTP DATA content, the inverse of Sovite.SMTP.DataDecoder.

An SMTP reply: a code, an optional enhanced status code (RFC 3463), and one or more text lines.

An SMTP server: a Sovite.Listener whose connections run Sovite.SMTP.Server.Session.

Runs a Sovite.SMTP.Server.Session on an accepted socket. Started by Sovite.Listener; see Sovite.SMTP.Server for the public API.

Behaviour for the application side of an SMTP server: policy decisions and what happens to received messages.

The SMTP server protocol as a state machine, without I/O.

TLS settings for mail servers and clients, following BCP 195 (RFC 9325).

An ACME client (RFC 8555) for getting certificates from a CA such as Let's Encrypt, with HTTP-01 challenges.

Builds PKCS #10 certificate signing requests (RFC 2986) for ACME: the first name as the subject's common name, and every name in a subjectAltName extension request.

Answers ACME HTTP-01 challenges (RFC 8555 §8.3): a Sovite.Listener handler that serves GET /.well-known/acme-challenge/<token> from an ETS table of {token, key_authorization} and answers everything else with 404.

Holds server certificates, picks one per connection by SNI (RFC 6066), and reloads them when their files change.

A certificate chain and its private key, loaded from PEM files.

DANE certificate verification for SMTP (RFC 6698, RFC 7671, RFC 7672).

Syntax validators for the identifiers that appear in SMTP envelopes.