Interview, Fireside Chat, Conference Presentation, Keynote
Building a Functional Email Server with Dominick LoBraico
- Core Problem: Jane Street replaced its legacy open-source mail server because its bespoke configuration language created high complexity, requiring specialized knowledge that generalist engineers lacked.
- Compliance Risks: The legacy system suffered "near misses" in archiving compliance logs due to the difficulty of reasoning about its opaque configuration semantics.
- Regulatory Complexity: Jane Street operates under diverse global regulatory regimes, necessitating intricate, hard-to-manage rules for what data to log, where to store copies, and which metadata to retain.
- Build vs. Buy Decision: The team rejected switching to another open-source server with a similar complex configuration language or a new server with a different proprietary language (like Python or Lua) due to the lack of tooling and organizational familiarity.
- Architecture Choice: The team decided to build "MailCore," a homegrown email server implemented in OCaml, where the configuration is written as composable OCaml code rather than a custom DSL.
- Design Philosophy: The system treats the email server as a function taking input messages and outputting processed messages, leveraging OCaml's type system, functions, and composability to replace the legacy configuration language.
- Migration Strategy: To mitigate risk during the one-year migration, a "shadow instance" was run in parallel with the legacy system, diffing outputs to detect behavioral divergences and correct the new system before a full cutover.
- Knowledge Extraction: A significant portion of the project involved reverse-engineering implicit knowledge and workarounds buried in years of legacy configuration changes to faithfully reproduce behavior in the new system.
- Security Benefits: Writing in OCaml eliminates the class of memory-safety bugs (e.g., buffer overruns) prevalent in C-based mail servers, and the obscurity of a custom server reduces its attack surface compared to widely used open-source alternatives.
- Operational Agility: MailCore lowered the barrier to change, allowing security teams and generalists to implement new scanning filters and routing logic using standard OCaml tools, code review, and testing without needing "specialist" knowledge.
- Internal Tooling: The team created a "relay list" feature allowing any employee to route emails to internal hosts/ports, federating automation capabilities without granting access to core infrastructure.
- Cultural Shift: Storing configuration as code in the same repository as implementation fostered a "software culture" of refactoring, testing, and code review, contrasting with the ad-hoc nature of traditional config files.
- Compiler Safeguards: Aggressive OCaml compiler warnings, such as treating unused variables as errors, prevent common configuration mistakes where defined rules are inadvertently omitted or forgotten.
- Protocol Limitations: Despite internal improvements, the email protocol itself remains difficult to secure due to its foundational openness, leading to persistent challenges with spoofing, phishing, and the fragmented adoption of authentication standards (SPF, DKIM).
- Productivity Challenges: A primary organizational pain point is the high cost of mass email distribution, prompting Jane Street to develop tools that visualize audience size and impact at the moment of sending to encourage concise communication.
- Filtering Improvements: The team moved email filtering logic into OCaml to enable team-shared, composable, and code-reviewed filter rules, though this introduces the risk of "black-holing" email if shared filters are misconfigured.
- Future Outlook: MailCore represents a successful application of functional programming to infrastructure, demonstrating that building custom systems can yield significant long-term value in flexibility, security, and developer experience over adopting standard tools.