Proof / OSMAP

Secure mail for high-consequence systems.

OSMAP adds browser access to a hardened OpenBSD mail platform without allowing the web application to become the mail authority.

See Secure Systems Engineering →Back to Proof →

Keep browser access outside mailbox authority

◎

BrowserHostile content · user action

▣

TLS edgeRequest boundary

⚙

Rust appUnprivileged · bounded

◇

HelperNarrow privileged operation

✉

MailboxDovecot authority

✓

SubmissionPostfix boundary

The engineering problem

Adding a browser should not erase the hardening underneath it.

A browser-facing mail application introduces hostile content, session state, parsing, rendering, and request risk. OSMAP treats those as new trust boundaries while preserving the hardened mail platform underneath.

Security-sensitive software design

◇

Privilege separation

The browser-facing process does not own general mailbox authority.

▽

Safe rendering

Hostile mail content is sanitized, bounded, and prevented from silently inheriting browser trust.

▣

Bounded sessions

Authentication, session lifecycle, CSRF, throttling, request validation, and worker limits define the runtime boundary.

Security-visible product design

A secure state should be understandable to the user.

Sanitization, blocked content, sender context, cryptographic readiness, and protected states are treated as product behavior rather than invisible backend controls.

Visible protection state

✉

ReceiveMessage · sender context

▽

SanitizeRemove unsafe behavior

BlockRemote or unsafe content

◇

SignalShow protection state

◎

ReviewUser sees context

✓

ActBounded user control

What this proves

Hardening principles can become working application architecture.

OSMAP connects secure software, platform hardening, privilege separation, hostile-content handling, accessible UX, and operational integration rather than treating them as separate disciplines.

Capability demonstrated

◇

Narrow authority

Components receive only the power they need.

Fail closed

Unsafe or ambiguous state does not silently become allowed behavior.

◎

Usable security

Security controls remain understandable and accessible to the operator.

▦

Operational fit

The software preserves the hardened OpenBSD mail, filtering, TLS, network, and recovery model.

Why a client should care

Security-sensitive software has to make privilege, content, UX, and operations work together.

Those same principles apply to client systems that need more than surface-level hardening.

Discuss secure engineering →

OSMAP

◇

Least privilege

Narrow authority.

▽

Content isolation

Hostile input stays hostile.

◎

Visible state

Protection is understandable.

✓

Operational security

Architecture survives real use.