Security Model & CSP

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• crates/mailiner-app/Dioxus.toml
• crates/mailiner-html/src/lib.rs
• crates/mailiner-app/src/formatter/html.rs
• crates/mailiner-app/src/formatter/sanitize.rs
• crates/mailiner-composer/src/export.rs
• crates/mailiner-composer/src/model/draft.rs
• crates/mailiner-mime/src/writer/mod.rs

Mailiner implements a multi-layered security model to protect user privacy and prevent malicious code execution. The system secures IMAP/SMTP communications via browser-side encryption and enforces strict Content-Security-Policy (CSP) baselines. It utilizes robust HTML and CSS sanitization to block tracking pixels, remote resource leaks, and Cross-Site Scripting (XSS).

The security architecture relies on local storage for secrets, ensuring that no server-side account exists. Communications are routed through a WebSocket-to-TCP proxy, but encryption remains end-to-end between the browser and the email server.
Sources: README.md:18-32, README.md:46-52

Content-Security-Policy (CSP)

Mailiner sets a baseline CSP via a document <meta> tag. This policy hardens the application against XSS by restricting the origins of scripts, styles, and connections. While the meta tag is injected after the WebAssembly (WASM) mounts, the project recommends deploying an equivalent HTTP response header for first-paint coverage.

CSP Directives and Rationale

Directive	Policy	Purpose
default-src	'self'	Denies unexpected origins by default.
script-src	'self' 'wasm-unsafe-eval'	Restricts to app WASM; allows WASM instantiation.
style-src	'self' 'unsafe-inline'	Permits Dioxus inline styles for layout and virtual lists.
img-src	'self' data: blob: http: https:	Allows local images and remote images (gated by the formatter).
connect-src	'self' ws: wss: http: https:	Supports user-configured proxies and IMAP-over-TLS.
object-src	'none'	Disables all browser plugins.
base-uri	'self'	Limits the document base URL.
form-action	'self'	Limits form submission targets.

Sources: README.md:38-51, crates/mailiner-app/Dioxus.toml:13-16

HTML & CSS Sanitization

Mailiner uses the ammonia crate to sanitize HTML content during message viewing and composition. The sanitization process differs depending on the context: viewing received mail, editing a draft, or exporting a message for sending.

Formatting & Privacy Controls

The MessageFormatter and format_html function in mailiner-app handle the display of received emails. By default, remote resources are blocked to prevent senders from tracking the user.

• Remote Resource Blocking: The formatter strips src, srcset, and href attributes if they point to remote HTTP(S) hosts, unless the user explicitly clicks "Allow remote resources".
• CID Resolution: The system rehydrates cid: (Content-ID) references by converting internal message parts into data: URLs for safe local rendering.
• CSS Sanitization: <style> blocks and inline style attributes are processed to remove @import rules and remote url() references.

Sanitization Policies

The project defines specific sets of allowed tags and attributes to maintain a safe subset of HTML.

• Allowed Tags: Common presentational tags such as p, br, div, span, b, i, table, and img are permitted.
• Forbidden Content: script, iframe, object, embed, svg, and math tags are explicitly removed along with their content.
• Protocol Filtering: The system rejects javascript: and vbscript: URI schemes in all contexts.

Sources: crates/mailiner-html/src/lib.rs:71-125, crates/mailiner-app/src/formatter/html.rs:163-182

Data Validation & Limits

The mailiner-composer crate enforces strict resource limits and validation rules for outgoing drafts to prevent abuse and ensure compatibility with mail servers.

Draft Constraints

The system defines hard caps for various components of an email draft.

Resource	Maximum Limit
Single File Attachment	25 MiB
Single Inline Image	25 MiB
Total Draft Payload	40 MiB
Max Attachments	20
Max Inline Images	30
Body Length (HTML/Plain)	1.5 MiB each

Sources: crates/mailiner-composer/src/model/draft.rs:125-141

Email Syntax Validation

Validation ensures that email addresses conform to a safe subset of RFC 5322. The is_valid_email_v1 function requires exactly one @ symbol, non-empty local and domain parts, no whitespace, and at least one dot in the domain.
Sources: crates/mailiner-composer/src/model/draft.rs:205-234

Message Export Security

During the export process (prepare_submit), Mailiner serializes the draft into RFC 5322 MIME format.

1. Header Protection: The MIME writer (mailiner-mime) validates header names to ensure they do not contain colons, CR, or LF characters, preventing header injection attacks.
2. Bcc Handling: To maintain recipient privacy, Bcc addresses are included in the SMTP envelope but are strictly omitted from the RFC 5322 message headers in the final serialized output.
3. Encoding: The system uses quoted-printable for text and base64 for binary data. It also implements RFC 2047 for encoding non-ASCII characters in headers and RFC 2231 for attachment filenames.

Privacy & Encryption

Mailiner operates as a "serverless" web client.

• End-to-End Encryption: Encryption is handled in the browser. The WebSocket proxy acts only as a transport layer and cannot decrypt the IMAP/SMTP traffic.
• Local Storage: Account settings, including IMAP passwords and proxy tokens, are stored exclusively in the browser's localStorage.
• Location Privacy: By routing traffic through a ws-tcp-proxy, the user's IP address is hidden from the destination email server.

Sources: README.md:18-32