The Mail Services field-set controls the mail features Yioop offers to signed-in users. The top dropdown chooses one of four overall modes; the sub-options below it are only meaningful when MailSite is selected. Defaults for new installs disable all mail features entirely.

Mode

• Mail Disabled: the Mail button does not appear in the account navigation and no mail subsystem runs. This is the default for a fresh install. Choose this when Yioop's mail features are not needed; the rest of Yioop continues to send outbound registration and notification emails through the Account Registration field-set above.

• MailSite: Yioop hosts mail for its own users. Each user gets an inbox stored locally and accessible through the Mail activity in the Yioop web interface. Standard SMTP and IMAP listeners can be exposed for desktop and mobile mail clients when the appropriate ports are open. MailSite also acts as a peer mail server: it accepts mail from other servers on the internet addressed to your local users, and it delivers outbound mail directly to each recipient's mail servers. This mode is most useful for installations that want a self-contained search + community + mail stack without depending on an external mail provider.

• External Mail Accounts: Yioop does not host mail of its own but lets each user register one or more existing mail accounts (Gmail, Fastmail, a corporate mail server, and so on) and both read them through IMAP and send messages through SMTP from inside the Mail activity. Credentials are encrypted before being stored; only the server-side key (kept in the private database) can decrypt them. This mode turns Yioop into a thin webmail client for accounts hosted elsewhere.

• MailSite and External Mail Accounts: both of the above. Users whose mail is hosted by Yioop see their MailSite inbox by default and can additionally add external mail accounts that appear as separate folders.

MailSite Sub-Options

These sub-options only apply when the mode is MailSite or MailSite and External Mail Accounts. They are hidden from the form otherwise.

Storage Engine

How MailSite persists message bodies on disk. Files on Disk (the default, also known as FileMailStorage) keeps each message as an individual file under the work directory; it is simple, transparent, and easy to back up with ordinary filesystem tools. Database and Dedupped Files (SqlMailStorage) stores message metadata (flags, IMAP UID, folder membership) in the Yioop SQL database while keeping the raw message bytes as content-addressed dedupped blobs on disk; this saves space when the same attachment lands in many mailboxes and makes flag updates faster on large mailboxes, at the cost of a more involved backup story.

Mail Domains

Comma-separated list of domains MailSite accepts local mail for. Leave blank to default to localhost only, which is appropriate for testing or single-machine deployments not meant to be reachable by other mail servers. For a public deployment, list every domain whose MX records point at this Yioop instance ("example.org, mail.example.org"). The domains listed here are also the ones the Suggested DNS Records panel (below) generates records for.

SMTP Port

TCP port MailSite listens on for incoming SMTP deliveries from other mail servers. The standard value is 25, and 25 is the correct default because peer mail servers always deliver to port 25. When STARTTLS is enabled, this same port 25 listener greets in cleartext and then upgrades to TLS on request, which is how mail reception with opportunistic encryption works. Some networks and hosting providers block outbound port 25; that affects sending, not the port you listen on (see Outbound Delivery below).

SMTPS Port

TCP port MailSite listens on for implicit-TLS SMTP submissions (mail clients sending mail through MailSite). The standard value is 465. Used by desktop and mobile mail clients configured for "SSL" or "TLS" outbound.

IMAP Port

TCP port MailSite listens on for cleartext or STARTTLS IMAP. The standard value is 143. Cleartext should only be exposed on a trusted local network; STARTTLS upgrades the connection to TLS after the initial banner and is appropriate over the public internet when the listener has a valid certificate.

IMAPS Port

TCP port MailSite listens on for implicit-TLS IMAP. The standard value is 993. This is the preferred port for IMAP clients connecting from outside the local network.

Use Default Ports

A convenience link that fills the four port fields with their standard values for the current mode. Under STARTTLS it sets the secure SMTP port to 25 (peer reception with STARTTLS upgrade); under implicit TLS it uses 465.

Use STARTTLS

When checked, the secure SMTP and IMAP ports negotiate TLS by upgrading a connection that begins in cleartext (the STARTTLS command), rather than requiring TLS from the first byte (implicit TLS). STARTTLS on port 25 is how peer mail servers expect to encrypt delivery to you. This option only appears when a certificate is configured.

Expose Mail Externally

When checked, the IMAP and IMAPS listeners bind to the public network interface, making MailSite reachable by desktop and mobile mail clients. When unchecked (the default), the listeners bind only to the loopback interface, so users can only access their mail through the Yioop web interface. Leave this unchecked when MailSite is intended as a webmail-only service; check it when users need to use external mail clients with their Yioop-hosted accounts.

Enforce DMARC

When checked, inbound mail is evaluated against the sender domain's published DMARC policy (see Mail Authentication below). Mail that fails DMARC is filed in the recipient's Junk folder when the sender's policy is quarantine, and refused outright when the policy is reject; mail from domains that publish no policy, or a policy of none, is delivered normally. Leave this unchecked to deliver all inbound mail regardless of DMARC.

Delivery Security

Sets the transport-security posture for MailSite, and is the single control behind the older "allow insecure" and "MTA-STS mode" settings. It has three values:

:* Allow Insecure: users may authenticate over cleartext, and inbound mail that arrives without TLS is delivered normally. No MTA-STS policy is published. Appropriate for testing or a trusted local network. :* Spam Insecure: cleartext authentication is not allowed, and inbound mail that arrives without TLS is filed in Junk unless its sender is on the recipient's trusted-sender list. An MTA-STS policy is published in testing mode so senders report (but do not yet enforce) TLS results. This is a good middle setting while you confirm everything works. :* Require Secure: cleartext authentication is not allowed and an enforce MTA-STS policy is published, asking senders to refuse cleartext delivery to you. Use this once you are confident your TLS setup is correct. :When no certificate is configured in SERVER_CONTEXT, the secure ports cannot bind, so the posture is forced to Allow Insecure and the secure-port fields, the STARTTLS checkbox, and the secure postures are hidden, with a warning shown in their place.

Log Mail

When checked, MailSite records the SMTP and IMAP protocol exchanges it handles to a log, which is useful when diagnosing delivery or authentication problems. The View log link beside this option opens that log through the Manage Machines activity. Leave it off for normal operation, since logging every exchange adds overhead and the log can grow quickly on a busy server.

Test Mail Mode

When checked, MailSite relaxes the rules it normally enforces so an automated test setup can exercise it on a loopback host. Address validation accepts single-label and IP-literal domains (for example user@localhost), which the strict production rule rejects, and the fully-qualified-domain checks on the envelope sender and recipient are skipped. Leave this off for any real deployment; it exists only so tests can compose to a MailSite account without the strict checks refusing the address.

Test Mode Fallback Port

The port a test setup falls back to when the standard mail port is unavailable (for example when an unprivileged test run cannot bind the privileged port 25). It only has an effect while Test Mail Mode is on and is ignored otherwise.

Notes

• These settings only record the operator's intent. The actual SMTP and IMAP listeners are started and stopped under the Manage Machines activity. Changing any value here has no effect on a running listener until the listener is restarted from Manage Machines.

• External mail accounts are added per-user through the Mail activity once this field-set has them enabled. Each user manages their own list of accounts; an admin can revoke a stored credential by deleting the row from the MAIL_ACCOUNT table.

Mail Authentication and Transport Security

For mail to be trusted by, and securely exchanged with, other servers (especially the large providers such as Gmail, Yahoo, and Outlook, which quietly discard or junk unauthenticated mail), MailSite-hosted domains should publish a small set of DNS records and serve an MTA-STS policy. Four mechanisms work together: the first three tell receivers whether a message claiming to be from your domain is genuine, and the fourth protects the connection itself. You need not deploy all four at once; a reasonable order is SPF, then DKIM, then DMARC in report-only mode, then MTA-STS once TLS is confirmed working.

Suggested DNS Records

When MailSite is enabled, the settings page shows a Suggested DNS Records panel that lists the records to publish in each mail domain's DNS zone. The panel adapts to the current Delivery Security posture and to whether a DKIM key has been generated. The values are starting points; adjust them to match your environment before publishing.

SPF

SPF (Sender Policy Framework) is a single DNS TXT record at your domain's apex naming the hosts allowed to send mail for the domain. Yioop suggests:

v=spf1 mx ~all

This authorizes the hosts named by your domain's own MX records (the mx mechanism) and asks receivers to soft-fail mail from anywhere else (~all), a conservative starting point. Once every legitimate sender is covered, tighten the trailing mechanism to -all (hard fail). MailSite also evaluates SPF on inbound mail, feeding the DMARC decision below.

DKIM

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held only by your server and publishes the matching public key in DNS, so a receiver can verify the message genuinely came from your domain and was not altered. The DKIM section of Server Settings manages the key pair; generating a key creates an RSA private key (kept in the work directory's security folder, never published) and the public-key record, published at:

<selector>._domainkey.<domain>

with a value of the form v=DKIM1; k=rsa; p=<base64 public key>. The selector is a short label that lets a domain rotate or run several keys. Because RSA-2048 keys are long, some DNS providers require splitting the value into several quoted strings, which they rejoin automatically.

MailSite signs with RSA-2048. RFC 8463 defines a newer, shorter Ed25519 signature, but as of 2026 the largest providers still do not reliably validate it, so RSA remains the choice trusted everywhere. Outgoing messages are also oversigned: each signed header is listed once more than it appears, so that if a relay later injects an extra copy of a header (a spoofing trick), the signature no longer verifies. MailSite verifies DKIM on inbound mail as well, feeding the DMARC decision.

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM to the visible From address and publishes, in DNS, what a receiver should do on failure. It is a TXT record at:

_dmarc.<domain>

Yioop suggests starting in report-only mode:

v=DMARC1; p=none; rua=mailto:<your report address>

p=none takes no action on failures but sends you aggregate reports (to the rua address). Watch those until all legitimate mail passes, then tighten to p=quarantine (failing mail goes to Junk at the receiver) and eventually p=reject. A message passes DMARC when either an SPF pass or a DKIM pass is for a domain that aligns with the From domain. Alignment in relaxed mode (the default) needs only the same organizational (registrable) domain, so mail.example.com aligns with example.com; strict mode requires an exact match.

When Enforce DMARC is checked (above), MailSite applies this same logic to inbound mail: it runs SPF, verifies DKIM, looks up the From domain's policy, and on failure files the message in Junk for a quarantine policy or refuses it for a reject policy. The organizational-domain calculation recognizes common multi-label public suffixes (such as co.uk and com.au); an unusual suffix falls back to the last two labels, erring toward applying policy.

MTA-STS

MTA-STS (SMTP MTA Strict Transport Security) protects the connection over which mail is delivered to you, closing the gap where an attacker strips the optional STARTTLS upgrade and downgrades to cleartext. It has two parts: a DNS TXT record at _mta-sts.<domain> of the form v=STSv1; id=<number> (the id changes whenever the policy changes so senders re-fetch it), and a policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. Yioop serves the policy file itself when clean URLs are enabled, and lists the _mta-sts TXT record and the mta-sts host record in the Suggested DNS Records panel. The mode follows Delivery Security: Spam Insecure publishes testing, Require Secure publishes enforce, Allow Insecure publishes no policy. Two deployment requirements: the mta-sts.<domain> host must resolve to this Yioop web server, and its TLS certificate must cover that host name (a wildcard or a subject-alternative name), since senders fetch the policy over HTTPS and validate the certificate.

Spam Insecure and Trusted Senders

The Spam Insecure posture is a pragmatic middle ground: rather than refusing cleartext mail outright (as Require Secure does), it treats mail that arrives without TLS as suspicious and files it in the recipient's Junk folder. Each user keeps a per-user trusted-sender list; mail from a trusted sender lands in the inbox even when it arrived insecurely, letting a user rescue a known correspondent whose mail server does not yet use TLS without weakening the posture for everyone else.

Outbound Delivery

MailSite delivers outbound mail directly to each recipient domain's mail servers (the hosts named by its MX records), acting as a peer mail server rather than relaying through a smarthost. Delivery uses opportunistic STARTTLS: it connects on port 25 and upgrades to TLS when the far side offers it. Because some networks block outbound port 25, MailSite falls back to port 587 when the port 25 connection cannot be established at the TCP layer. The fallback is deliberately narrow: it triggers only on a connection-level failure, never on an SMTP-level rejection, so a recipient server that simply refuses a message is not retried on a different port.

Security of Stored Credentials

Stored external-IMAP passwords are encrypted at rest using libsodium (sodium_crypto_secretbox) with a master key kept in the Yioop private database. An attacker who obtains only the public-database dump cannot read the stored credentials without also obtaining the private-database key. This raises the bar but does not protect against an attacker with read access to both databases or to the running process memory; for high-value accounts, prefer using an application-specific password (provider-supplied) rather than the account's main password.

Mail listeners exposed externally should always require TLS for both SMTP submission (SMTPS, or STARTTLS on the SMTP port) and IMAP access (IMAPS, or STARTTLS on the IMAP port). Cleartext credentials over an untrusted network are a non-starter for any deployment intending to be reachable from the public internet.