HN threadでのCloudflare Email Serviceは、agent時代の新しいinterfaceというより、email infrastructureの古い問題を再点検する材料になった。Cloudflareのpostはagentがemailを送受信する姿を前面に出しているが、コメントの多くは「これは実質的にSES alternativeではないか」という読みだった。

その見方は必ずしも否定的ではない。Workersから直接emailを送り、APIでtransactional emailを扱えるなら、小さなteamやsolo developerには魅力がある。AWS SESのsandboxから出る手続きに苦労した経験も共有されていた。CloudflareがDNS、Workers、routingをすでに持っているなら、outbound emailを足すplatform戦略は自然だという声もある。

ただしHNはagent marketingをそのまま飲み込まなかった。CIが通ったらmailを送る、orderが出荷されたら通知する、といった例はagentなしでも昔からできる。だから議論は「AI agentがemailを使う」より、「新しいemail senderはdeliverabilityとabuseをどう扱うのか」に移っていった。

spamとreputationは中心論点だった。SMTPは送信コストが低く、open platformは必ずabuse圧力を受ける。GmailやOutlookのような大手mailbox providerの判断がdeliverabilityを左右しやすいことへの不満も出た。発信側platformが増えるだけでは、受信者側のcontrolはあまり増えない。

security detailも見逃されなかった。emailはthreadedで非同期、どこでも使えるのでagent workflowには合っている。一方で、HTTP APIとは違うtransit security問題がある。コメントではMTA-STSやdowngrade attackへの注意が挙がった。HNの結論は地味だが重要だ。agentがemailを使う未来でも、pricing、sending limit、domain reputation、encryption、abuse handlingというemail運用の問題は消えない。

#email

Cloudflare Email Service、HNはagent文脈よりSMTPとdeliverabilityを見た