どうも、わたしです。
今日は、長らく頭を悩ませていたメールアドレスの運用について、その移行経緯と最終的な結論を記録しておこうと思います。

はじめに

かつては自宅サーバーでメールサーバーを運用していましたが、自宅サーバー群の完全撤廃に伴い、その運用も当然ながら終了しました。
以前はHomeNOCより割り当ていただいたIPで運用していましたが、自宅の一般回線はOP25Bの影響を避けられないため、代替としてAmazon Simple Email Service (SES)を暫定的に利用していた、というのがこれまでの経緯です。

SESのコストや機能に大きな不満はなかったものの、ごく稀に発生するGmailへの転送失敗という、再現性の低い問題が看過できなくなり、本格的に移行先を探すことにしました。

検討と検討と検討

まず、国内でよく名前が挙がる安価なメールサービス、例えばConoHaやさくらのメールボックスあたりから検討を始めましたが、これらはその仕様のお粗さから、候補にすら入りませんでした。

特にさくらのメールボックスに関しては、価格の安さからスパム業者の温床になっているという話は有名で、実際にAS単位でメールサービスからブロックされることも珍しくありません。
私のような真っ当な利用者が、なぜスパマーのせいでメールが届かないリスクを負わなければならないのか。
サービス設計としてあり得ない話です。
たまったものではありません。

そもそも私の要件は極めてシンプルです。

1. 独自ドメインで、大量のエイリアスを生成・受信できること。
2. それらを普段使いのメールボックスに転送できること。
3. エイリアスからメールを送信できること。

メインで利用しているメールアドレスを、素性の知れないウェブサービスに登録するのが生理的に受け付けない、というだけの理由で、サービスごとにアドレスを使い分けるためだけに独自ドメインを利用しています。
プライバシーがどうこうという崇高な理念は、あいにくと持ち合わせていません。
現代において、ビッグテックから完全に情報を秘匿することが、現代においてどれほど非現実的か理解しているつもりですので。

Tech系の界隈を見渡すと、Zoho MailやProtonMailを利用している層がかなり観測できます。
しかし、私のユースケースはサービス登録の都度、数百から数千といった単位でアドレスを量産することにあるため、エイリアス数に課金されるこれらのサービスはコスト的に全く見合いません。

コストだけを考えればCloudflare Email Routingも候補でしたが、基本的に受信専用のものでした。
送信もそれなりに行うため、機能的に片手落ちであり、これも除外。(これを書いている少し前にCloudflare Email Service’s🔗なるものがプライベートベータとしてリリースされたようですが、検討していた時点では存在しなかったため、考慮していません)

正直なところ、VPSを借りて再びメールサーバーを構築することも一瞬考えました。
しかし、あの不毛な設定と、セキュリティアップデートやスパム対策に追われる運用保守に、再び貴重なリソースを投下するのはあまりにも非合理的だと判断し、即座に却下しました。
あんな面倒なこと、二度とやりたくありません。

Apple Hide My Email、お前だったのか

ここで私はiCloud+に含まれるHide My Email機能の存在に行き着きます。

最近の私の身の回りは比較的Apple製品で固められており、そのエコシステムとの親和性は言うまでもありません。
そして何より、私の目的はアドレスを使い分けることであり、独自ドメインの利用は、その目的を達成するための単なる手段に過ぎませんでした。
その手段へのこだわりを捨てることに、何のためらいもありません。

むしろ、独自ドメインを手放すことには予期せぬメリットすらありました。
PictLinkのような、特定のドメイン以外からの登録を受け付けない、前時代的で愚かな仕様を持つサービスが未だに存在しますが、icloud.comというドメインパワーの前では、そうした問題も発生しにくい。
これはうれしい。我ながらかなり合理的な判断です。

一つ問題だったのは、パスワード管理に利用しているVaultwarden(Bitwarden互換)のクライアントから、直接Hide My Emailのアドレスを生成できない点でした。
サービス登録のたびに手動でアドレスを生成し、コピペするのは普通にしんどいですし、UXとして最悪です。

しかし、この問題はお友達のまくらくら🔗が作っていたブリッジツールによって解決しました。
https://github.com/lqvp/hme_bridge🔗

外向きにはSimpleLoginのAPIとして振る舞うことで、Bitwardenクライアントを騙し、内部でiCloudのAPIを叩いているようです。
Rustで書かれていたのでコードの詳細は読んでいませんが、きちんと動くので多分問題ないでしょう。
ありがたく利用させてもらうことにしました。

各種サービスに登録していたメールアドレスの変更も概ね完了し、現在はiCloud基盤で安定して稼働しています。
SES + Lambdaの環境で発生していたようなメールのロストもなく、不満はありません。

さいごに

最近のサービスはSSOを前提とし、ユーザーにメールアドレスの入力すらさせず、GoogleアカウントやiCloudアカウントでログインさせるものが増えているように感じます。
この風潮の背景には、「原則としてユーザーは馬鹿で愚かで無能なものなので、まともにアカウント管理など到底できる訳がない」という、サービス提供者側の諦観にも似た思想があるのでしょう。
それ自体は否定しませんし、私も同感です。

しかし、例えばGoogleのような単一の認証基盤に、あらゆるサービスの認証を依存させるアーキテクチャには、強い違和感を覚えます。
これは、すこし考え方を変えて見れば、SPOFを意図的に作り出しているに等しいあまりにも稚拙で傲慢な設計です。
一つのサービスから情報が流出しただけで、他の全アカウントに影響が及びかねない構造など、本来あってはならない。
どうやら世の中の多くの人間に、まともなセキュリティ感覚はないらしいようです。

GoogleがDon't be evilを捨てて久しいですが、そのGoogleアカウントに生活の全てを預けることを、なぜ誰も疑問に思わないのでしょうか。
なーにがゼロトラストだ。口だけでフルトラストじゃないか。