feat: L402-Based Paid Inbound Gating for the Archon DMail Gateway

[santyr]

Proposal: L402-Based Paid Inbound Gating for the Archon DMail Gateway

Executive Summary

This proposal recommends adding L402-backed paid inbound gating to the Archon DMail gateway as an optional anti-spam and contact-control feature.

The recommended first phase is:

• keep token-threaded replies free
• keep trusted or allowlisted senders free
• require payment for unsolicited first-contact inbound mail
• perform payment verification through Archon Drawbridge
• initially enforce the feature at the gateway/application layer, with a longer-term option to move enforcement to the SMTP edge via archon-mail-bridge or Postfix policy delegation

This is a practical fit for Archon because the current Herald email bridge already distinguishes between token-threaded replies and unsolicited inbound mail, and Drawbridge already exposes L402/payment capabilities that can be reused as the settlement and authorization layer.

Goals

1. Reduce unsolicited inbound spam and abuse.
2. Preserve a smooth experience for legitimate ongoing conversations.
3. Reuse Archon’s existing L402 and DID infrastructure where practical.
4. Avoid breaking the current Email ↔ DMail bridge model.
5. Preserve a path to SMTP-edge enforcement later.

Non-Goals

• Replacing DKIM, SPF, or DMARC.
• Building a content-classification spam engine.
• Requiring payment for all email by default.
• Replacing standard mailbox storage with Archon-native message storage in the first phase.

Current State

Archon’s current Email ↔ Dmail Bridge design is centered on Herald as a trusted courier. The bridge currently supports:

• outbound DMail → email delivery
• inbound email replies via token-gated reply addresses
• unsolicited inbound email to registered Herald names
• webhook authentication and a basic spam-score threshold
• an EmailServiceInterface abstraction with SendGridEmailService as the documented implementation

The design explicitly lists rate limiting as future work, which makes paid admission control a natural extension rather than a conceptual mismatch.¹

Archon also already has Drawbridge as an L402 API gateway. The sample environment file includes:

• ARCHON_DRAWBRIDGE_L402_ENABLED
• ARCHON_DRAWBRIDGE_DEFAULT_PRICE_SATS
• invoice expiry and rate-limit settings

That confirms the project already has an L402-oriented service boundary and configuration model that can support payment-gated access flows.²

Separately, the archon-mail-bridge project provides a more SMTP-native architecture, with:

• an inbound SMTP listener
• outbound SMTP delivery
• name → DID resolution
• SQLite-backed conversation/message storage
• standard email threading headers

That project is a stronger long-term fit if the goal is true SMTP-time enforcement rather than post-accept application-layer handling.³

Problem Statement

The current DMail gateway can reject obvious abuse through simple checks, but it does not impose a meaningful economic cost on unsolicited inbound contact. Traditional content spam filtering is imperfect, and a paid-contact control can be effective even when sender identity is weak.

L402 does not classify spam content. Instead, it changes the economics of unsolicited contact by requiring payment before a message is delivered into a DMail conversation.

This makes L402 best suited for:

• first-contact inboxes
• premium aliases
• professional or consulting endpoints
• anti-spam gating for public-facing recipients

Proposed Feature

Add an optional L402 paid inbound policy to the Archon DMail gateway.

Recommended Default Policy

Free

• token-threaded replies
• allowlisted senders
• policy-exempt recipients
• optionally, DID-authenticated trusted contacts

Paid

• unsolicited first-contact inbound mail to name@domain
• optionally, large attachments or high-volume senders

Rejected or Quarantined

• unpaid unsolicited mail after challenge issuance
• expired invoice cases
• mail that fails existing spam/auth policy before payment is even considered

Why This Fits the Existing Architecture

The current Herald bridge already has a clean branch point between:

1. token-gated reply mail, and
2. unsolicited inbound mail

That is exactly where a paid gate belongs. Free replies preserve ongoing conversations, while payment requirements are applied only to cold inbound messages.¹

The current bridge also already stores mappings and token state in Herald’s database. A paid-gating feature can reuse the same general model by storing a short-lived pending inbound message record until payment clears.¹

Architecture Options

Option A — Herald Webhook-Layer Paid Gating (Recommended First Phase)

Flow

1. External sender emails alice@domain.
2. SendGrid accepts the message and forwards it to Herald’s inbound webhook.
3. Herald classifies the message:
   • if token-threaded reply: deliver immediately
   • if allowlisted/trusted: deliver immediately
   • if unsolicited and payment required: create a pending inbound record
4. Herald or Drawbridge generates an invoice/payment challenge.
5. After payment confirmation, Herald converts the pending message into a DMail.

Advantages

• Minimal disruption to the current documented bridge design.
• Reuses existing Herald routing logic.
• Reuses Drawbridge’s L402/payment machinery.
• Low implementation surface compared with a full SMTP-edge redesign.

Limitations

• Payment gating happens after SendGrid has already accepted the email.
• This is not true SMTP-time refusal.
• Operational behavior is closer to quarantine-until-paid than “pay before acceptance.”

This limitation follows directly from the documented SendGrid inbound parse webhook architecture used by Herald today.¹

Option B — archon-mail-bridge SMTP-Time Paid Gating (Recommended Long-Term Path)

Flow

1. External sender connects to the bridge’s SMTP listener.
2. The bridge checks whether the recipient policy requires payment.
3. If payment is required and not yet satisfied, the bridge defers or rejects according to policy.
4. After payment clears, a retry or release path allows delivery.

Advantages

• Cleaner SMTP-native control point.
• Better fit for message acceptance policy.
• Easier to evolve into a full paid-inbox mail front end.
• Avoids dependency on SendGrid webhook semantics.

Limitations

• Larger implementation and deployment scope.
• Requires careful SMTP behavior design.
• More moving parts than the Herald-first approach.

This is attractive because archon-mail-bridge already documents an inbound SMTP listener, outbound SMTP, and local conversation storage.³

Option C — Postfix Policy Service + Archon Settlement Backend (Best for Mature Mail Deployments)

Flow

1. Postfix receives inbound SMTP.
2. check_policy_service asks an Archon-aware policy daemon whether the sender may proceed.
3. The policy daemon checks payment state in Drawbridge or a companion service.
4. Postfix accepts, defers, or rejects accordingly.

Advantages

• Best fit for operators already running Postfix.
• True SMTP policy enforcement point.
• Clean separation between mail transport and Archon business logic.

Limitations

• More operational complexity.
• Requires extra policy-service implementation.
• Less aligned with the documented Herald bridge as it exists today.

Postfix explicitly supports delegated policy services and can make decisions at states including RCPT, DATA, and END-OF-MESSAGE. It also supports delivery to external commands through pipe(8) when final delivery needs to be handed to another system.⁴⁵

Recommendation

Adopt a two-stage roadmap:

Stage 1

Implement Herald webhook-layer paid gating for unsolicited inbound only.

Stage 2

Move policy enforcement to archon-mail-bridge or Postfix if operators want true SMTP-edge behavior.

This approach gives Archon a useful feature quickly without forcing an immediate redesign of the existing bridge.

Detailed Policy Design

1. Policy Decision Matrix

Message Type	Default Policy
Token-threaded reply	Deliver free
Allowlisted sender	Deliver free
Trusted DID-linked sender	Deliver free or discounted
First-contact unsolicited inbound	Require payment
Oversized/abusive sender	Higher price or reject
Unknown invalid recipient	Reject/ignore per deployment policy

2. Payment Object

For unsolicited inbound mail, create a short-lived pending object containing:

• sender address
• recipient address/name
• message metadata
• message body pointer or encrypted storage reference
• invoice id / payment id
• expiry timestamp
• delivery status

3. Payment Outcomes

Outcome	Action
Paid before expiry	Convert to DMail and deliver
Not paid	Discard or keep pending until expiry
Invoice expired	Mark failed; optionally allow reissue
Already-paid trusted sender	Deliver immediately

4. Pricing Model

Start simple:

• global default price in sats
• optional per-recipient override later
• optional discounts for trusted contacts or credentialed senders later

This aligns with Drawbridge’s existing default pricing configuration model.²

DID and Identity Integration

DIDs should not be treated as a universal SMTP anti-spoofing solution, but they can still improve policy quality.

Recommended uses:

• tie paid privileges to a DID for Archon-aware users
• allow DID-authenticated or credentialed senders to bypass fees
• give lower pricing to senders with stronger identity proof
• keep ordinary SMTP senders on the default paid-first-contact path

This preserves compatibility with ordinary email while letting Archon-native identity improve trust and usability.

User Experience

Recipient Experience

• fewer unsolicited messages
• no payment friction for active threads
• optional premium public contact inboxes

Sender Experience

• ordinary correspondents can still reply normally in active threads
• first-contact senders may receive payment instructions or a payment-gated contact page
• Archon-native users may qualify for bypass or reduced rates

Security Considerations

Benefits

• raises the cost of unsolicited abuse
• reduces low-effort spam economics
• preserves existing thread continuity via free replies
• lets Archon identity and credential systems add trust where available

Risks

• paywalling can frustrate legitimate first-contact senders
• webhook-layer enforcement does not stop upstream acceptance by SendGrid
• invoice state handling and expiry logic add complexity
• malicious actors may still pay; payment is an admission control, not a content-quality guarantee

Operational Considerations

Observability

Track:

• total unsolicited inbound attempts
• invoices issued
• invoices paid
• paid messages delivered
• invoice expiries
• allowlist bypasses
• false-positive complaints

Configuration

Suggested first-pass settings:

• feature disabled by default
• one global default price
• recipient-level opt-in
• free token-threaded replies
• hard bypass for allowlisted contacts

Rollout Strategy

Phase 0 — Internal Testing

• add pending message storage
• add invoice generation and settlement callbacks
• simulate successful/expired unpaid flows
• verify free reply path remains unchanged

Phase 1 — Soft Launch

• enable for one or two experimental recipients
• use low sats pricing
• collect sender/recipient feedback

Phase 2 — Expanded Recipient Controls

• per-recipient prices
• allowlists and exemptions
• trust-tier discounts

Phase 3 — SMTP-Edge Migration (Optional)

• move enforcement into archon-mail-bridge or Postfix policy services
• reserve Herald for identity and final DMail conversion logic

Implementation Notes

Herald-Focused Changes

1. Add a policy check in unsolicited inbound handling.
2. Create pending-message storage.
3. Integrate Drawbridge invoice creation/status checks.
4. Deliver only after settlement.
5. Preserve the existing token-threaded reply fast path.

archon-mail-bridge / SMTP-Focused Changes

1. Add recipient policy lookup before final acceptance.
2. Add payment-state tracking.
3. Decide on SMTP defer/reject wording and retry semantics.
4. Preserve standard threading behavior after paid admission.

Postfix-Focused Changes

1. Implement a policy daemon reachable via check_policy_service.
2. Query Drawbridge-backed payment state.
3. Optionally hand accepted mail to Archon via pipe(8) or another delivery transport.

Key Open Questions

1. Should unpaid first-contact mail be silently dropped, quarantined, or acknowledged with payment instructions?
2. Should the challenge be exposed as an email response, a web payment page, or both?
3. Should recipients opt in individually, or should the domain default to paid-first-contact?
4. Should trusted DID-authenticated senders bypass payment entirely?
5. Should payment attach to a sender address, a DID, a conversation, or a one-time contact token?

Final Recommendation

Implement optional L402-based paid gating for unsolicited inbound mail in the current Herald bridge first, while preserving free token-threaded replies and free trusted-contact flows.

Treat this as admission control, not content filtering.

Design the feature so that the payment and policy logic can later move to archon-mail-bridge or Postfix policy services for cleaner SMTP-edge enforcement when needed.

---

Sources

Footnotes

1. Archon Email ↔ Dmail Bridge design: docs/email-dmail-bridge.md. Source reviewed from the current repository. See: https://raw.githubusercontent.com/archetech/archon/main/docs/email-dmail-bridge.md ↩ ↩² ↩³ ↩⁴

2. Archon sample environment file showing Drawbridge L402 settings. See: https://raw.githubusercontent.com/archetech/archon/main/sample.env ↩ ↩²

3. archon-mail-bridge README describing bidirectional SMTP ↔ DMail bridging, SMTP listener, and SQLite-backed conversation storage. See: https://raw.githubusercontent.com/archetech/archon-mail-bridge/main/README.md ↩ ↩²

4. Postfix SMTP access policy delegation documentation. See: https://postfix.cs.utah.edu/SMTPD_POLICY_README.html ↩

5. Postfix pipe(8) documentation for delivery to external commands. See: https://manpages.ubuntu.com/manpages/jammy/man8/pipe.8postfix.html ↩