sovrn

Experimental AT protocol email hosting

Evaluate: per-sender SMTP2GO subaccounts + bounce/spam reputation monitoring (>5% bounce, >0.05% spam)

open
#e3c101f opened by agent Sep 24

Goal

Make sure sovrn isn’t a path for mass spam. Isolate each sender on SMTP2GO and flag any sender whose reputation metrics cross these thresholds:

  • Bounce rate > 5%
  • Spam complaint rate > 0.05%

Proposed approach (to evaluate)

Put each domain or tenant in its own SMTP2GO subaccount. Use SMTP2GO’s per-subaccount limits and reporting to monitor bounce and spam rates, and to contain damage: throttle or suspend a single subaccount instead of the whole account being put at risk.

Evaluate

  • [ ] Granularity: subaccount per domain or per tenant? Consider the limits on subaccount count, cost, and how multi-domain tenants map.
  • [ ] Subaccount API: create/edit/close subaccounts, set per-subaccount send limits, and get per-subaccount API keys. Fit it into the domain signup saga (516fcde) alongside RegisterDomain.
  • [ ] SMTP routing: today Route() returns a single global SMTP username and password, so Stalwart has one relay route. Per-subaccount SMTP credentials would mean Stalwart picks the route or credentials by sender domain. Check Stalwart’s queue routing expressions (e.g. on sender_domain) and the secret/vault provisioning for per-subaccount credentials (3418287). A per-subaccount API key could be the alternative if routing by SMTP user is too awkward.
  • [ ] Metrics source: SMTP2GO stats/reporting API per subaccount (bounce and spam rates, sent counts) vs. aggregating our own from webhooks. relay.Event already carries EventBounce (with a Hard flag) and EventSpam. Probably both: webhooks for near-real-time counts, the stats API for reconciliation.
  • [ ] Rate math: use a rolling window with a minimum volume floor. 0.05% is 1 complaint in 2,000 messages, so a small sender would trip it on a single complaint. Decide the window (e.g. 7 or 30 days), the minimum send count before flagging, and whether to count hard bounces only or hard and soft. For reference, Gmail’s bulk-sender guidance is to stay under 0.1% and never reach 0.3% spam.
  • [ ] Flag action: what “flagged” does: admin alert/dashboard only, automatic throttling (lower the subaccount limit), or automatic suspension. Decide who gets notified (sovrn operators, the tenant admin) and how a sender is un-flagged.
  • [ ] SMTP2GO’s own enforcement: find out what SMTP2GO does automatically at the subaccount vs. the parent account level, so our thresholds trip before theirs.
  • [ ] Metrics export: show per-sender rates in /metrics (dfb37b1) for alerting.

Output

A written design (comment on this issue) covering the choices above, followed by implementation subtasks.

1 Comment

BT e73fcc1 Oct 8

I reviewed the subaccount documentation at SMTP2Go. It’s intended for allowing users to log in to the service and manage their account when resold by a reseller, which is not the intent with this app. The only value subaccounts may have is in setting a per-domain quota on sent emails (not currently envisioned to be limited per domain.)

SMTP2Go has a reporting function to monitor spam and bounce reports in a CSV format and also has the ability to POST to a webhook endpoint on bounce and spam (along with other deliverability events). Need to investigate the formats of those options and set up a monitoring service (likely on the shared relay host) that receives these reports and offers a management admin UI to identify problem senders and alert on likely spam.