きっかけ

中島聡さんのニュースレター経由で以前MulmoClaudeを知ったのと同じように、彼のニュースレターで「エンジニアを目指すなら、まず実物をGitHubに公開するといい」という趣旨のアドバイスを目にしていた。ドメイン運用やセルフホスティング、メールまわりで試行錯誤してきたことが、同じ問題にぶつかった誰かの検索結果に引っかかれば十分だと思い、公開することにした。

形式は「時系列の日記」にした

最初はテーマ別のハウツー記事にしようかと考えたが、途中で「実際に起きた順番のまま書く日記形式」に変更した。うまくいかなかったこと、迷ったこと、あとから直したことも含めて、そのまま時系列で残す方が実態に近い。

スタックを決める

静的サイトジェネレータはHugoにした。決め手は多言語対応(i18n)が標準で入っていること。テーマはPaperMod。GitHub Actionsでビルドし、GitHub Pagesにデプロイ、独自ドメイン blog.taikiito.com をCloudflareのCNAMEで割り当てた。

リポジトリは2つに分けた。実際に編集するHugoのソース一式(blog-source)は非公開、ビルド後の静的ファイルだけを別リポジトリ(blog)にforce pushで公開する構成にしている。GitHub Actionsの1ジョブの中で、ビルド→出力先リポジトリへのpushまで完結させた。ソース側の編集履歴や下書きを外に出さずに、成果物だけを公開できるのが気に入っている。

ついでにユーザー名も変えた

GitHubのユーザー名も、このタイミングで変えた。もともと登録したときに深く考えず入れた生年月日由来の文字列が入っていて、前から気に入っていなかった。理想の名前は既に他の人に使われていたので、末尾に-devを足した形に落ち着いた。公開リポジトリがまだ0個の状態だったので、切り替えのコストは低かった。

合わせて、ユーザー名と同じ名前のリポジトリを作ると自動でプロフィールページに表示される、GitHubのプロフィールREADME機能も使った。中身は最小限、2行だけ。

Tinkering with computers on the side. Hoping it helps someone.

ここから

ブログの器と、公開用のGitHubアカウントが整った。中身の記事は、実際に起きたことをこうして後から書き足していく形になる。

つづく。

DMARCを足しても、まだ消える

前回の時点ではDMARCを設定していなかったので、まずそこを埋めた。

• DMARC(TXT、_dmarc.taikiito.com): v=DMARC1; p=none; rua=mailto:(レポート送付先)

外部のDNSチェッカーで反映を確認し、伝播も待って、満を持して再送。……届かない。バウンスも一切なし。エラーもない。ただ、何事もなかったかのように消える。ポストに投函した手紙が、配達員ごと蒸発したような感覚だった。

SPF・DKIM・DMARC、教科書通り全部揃えたのに、というのがこの時点のモヤモヤ。原因は認証の失敗ではなく、センダーレピュテーション(そのドメインがどれだけ送信履歴を積んで信頼されているか)だと分かった。フィルタが厳しい受信サーバーほど強く効くらしい。SPF/DKIM/DMARCは「なりすましでないこと」の証明であって、「信頼できる送信元であること」の証明ではない。似ているようで全然別物、というのをここで痛感した。打てる手はもう無く、あとは時間が積み上がるのを待つだけ。地味に一番効かないタイプの「解決策」だ。

iCloud+のカスタムドメインメールで運用することにした

土台はApple iCloud+の「カスタムメールドメイン」機能。必要なレコードはMX・SPF・DKIMの3つだけで、Appleの設定ウィザードが値をそのまま出してくれるので、ほぼコピペ作業だった。

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF(TXT): v=spf1 include:icloud.com ~all
• DKIM(CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

Fastmailと迷ったが、思い込みが一つ崩れた

有名な対抗馬としてFastmailがある。料金以外の軸で比較してみた: 標準プロトコル対応、Apple以外の端末での使い勝手、ドメイン・エイリアスの上限(iCloud+はApple ID一つにつき数個、Fastmailはほぼ無制限+catch-all)、サーバー側のフィルタルール、送信ドメインとしての評判、データの持ち出しやすさ。

比較の途中で、自分の思い込みが一つ崩れた。iCloud MailはApple製品専用だとばかり思っていたが、実際にはimap.mail.me.com / smtp.mail.me.comにアプリ専用パスワードでアクセスすれば、Thunderbirdのような普通のIMAP/SMTPクライアントからも使える。Apple Mailの「書き出す」機能で.mbox形式のバックアップも取れる。「ロックインされて出られなくなる」という一番の懸念は、調べてみたらほぼ杞憂だった。

結局、iPhoneのバックアップ用に元々iCloud+を契約しているので、カスタムドメインのメールボックスを足しても実質タダ(容量を共有するだけ)。ロックインの心配もほぼ無いと分かった以上、今Fastmailに乗り換える動機はない。Apple以外の端末がメインになるとか、エイリアスを大量に使うようになったら、その時また考える。

完璧に設定しても、ドメインの「信頼」だけは時間でしか買えない。今回学んだのはそこに尽きる。

つづく。

サブドメインを1つ切って、静的ページだけを置く

card.taikiito.com というサブドメインを新しく作り、Lightsailの同じサーバー上にnginxのserver blockをもう1つ追加する形で対応した。ポイントは、MulmoClaude本体のNode.jsアプリとは完全に切り離したこと。proxy_pass は使わず、ただの静的HTMLファイル1枚を配信するだけの設定にしたので、名刺ページのアクセスがMulmoClaude本体の負荷に影響することはない。

中身は実際に普段使っている名刺の情報をそのまま移した。ボタンは2つだけに絞った。

• 「連絡先に保存」— クリックするとJSのBlobで .vcf ファイルをその場で生成し、スマホの連絡先追加シートを開く
• 「WhatsApp」— wa.me のクリック・トゥ・チャットのディープリンクを踏むだけ

最初はメール送信ボタンも用意していたが、後で削って情報行(mailto:リンク)だけに縮小した。ボタンは絞れるだけ絞った方が結局使いやすい。

色で少し迷った

配色は最初からネイビーで作っていたが、比較のために白黒版も一度作ってみた。並べて見て、結局ネイビーの方が良いという結論に落ち着き、白黒版は削除した。

地味なハマりどころ

公開直後、このアプリ自体に埋め込んだプレビュー用のiframe内でカードを確認したところ、メールアドレスの表示が記号だけの謎の文字列になっていた。最初は自分のミスかと疑ったが、正体はCloudflareの「メールアドレス難読化」機能(Scrape Shield)だった。ページ内のメールアドレスをスパム避けのため自動でエンコードして表示する仕組みで、通常のブラウザではJSが実際のアドレスに戻して表示するが、このアプリのプレビュー用iframe内ではそのデコード用スクリプトが動かなかった、というだけの話だった。ゾーン全体の設定なので個別にOFFにはせず、実際のブラウザでは問題なく表示されることを確認して終わりにした。

名前のドメインは、こう転がっていく

自分の名前をドメインにした瞬間から、こういう小さいサブドメインを次々に切れるようになった。この後もいくつか同じパターンで増やしていくことになる。

つづく。

自分で開けてしまっていた裏口

アクセス周りの設定を見直している最中、ドメインではなくLightsailのオリジンIPに直接アクセスしてみたところ、普通に開けてしまうことに気づいた。

これは、ドメイン経由のアクセスにはCloudflare Accessによる認証ゲートを設けていたのに、オリジンIPに直接アクセスすればそのゲートを完全にバイパスできてしまう、ということを意味していた。自分で用意した鍵が、裏口からは意味をなしていなかった、という状態だ。

同日中に ufw を導入し、inbound の80/443番ポートを Cloudflareの公開IPレンジ(https://www.cloudflare.com/ips-v4)からのみ許可、それ以外はデフォルトで拒否する設定にした。SSH(22番)は明示的に ufw allow OpenSSH で許可を先に入れてから有効化した(この順番を間違えると、ufw有効化と同時にSSH接続自体が失われるリスクがある)。適用後、ドメイン経由のアクセスは変わらず機能し、オリジンIP直接アクセスは接続不可になった。

2つ目のオリジンを追加したときの522エラー

このドメインの下に、MulmoClaude用の2つ目の入り口(mulmoclaude.taikiito.com)と、デジタル名刺用のサブドメイン(card.taikiito.com)を追加した。

2つ目の入り口のDNS(Aレコード)とCloudflare Accessのポリシーを設定した直後、アクセスするとCloudflareの 522エラー(オリジンへの接続タイムアウト) が出た。原因は、SSL/TLSの暗号化モードがゾーン(ドメイン)ごとに個別管理されていること。新しい taikiito.com ゾーンはデフォルトの Full モードになっていて、Cloudflareがオリジンの443番ポートへHTTPS接続を試みるが、nginx側は80番しか listen していなかった。既存のドメインと同じ Flexible モードに変更したら、即座に解消した。

続けて、SPF/DKIM/DMARCを設定してメールも作った

ドメインを持ったので、iCloud+の Custom Email Domain 機能を使って me@taikiito.com を作った。追加契約は不要で、案内された通りにDNSレコードを3つ登録するだけだった。

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF(TXT): v=spf1 include:icloud.com ~all
• DKIM(CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

これらは「このメールは、なりすましではなく本当に自分のドメインから送られている」ことを証明する仕組みで、値をコピーして貼り付けるだけの単純作業だった。

それでも一部の宛先にだけ届かない

設定は正しく完了したはずだったが、試しに別のメールアドレス宛に送ってみたところ、そちらには届かなかった。バウンス(エラー返信)も一切なく、静かに消えているような状態だった。

念のため DMARC(TXT、v=DMARC1; p=none; rua=mailto:(レポート送付先))も追加し、外部のDNSチェッカーで正しく反映されていることも確認した。それでも届かない。原因は、SPF/DKIM/DMARCがすべて正しくても解決できない、ドメインの送信履歴(センダーレピュテーション)の問題だった。フィルタが厳しいメールサーバーほど、この影響を強く受けるらしい。

技術的に打てる手は尽きたので、これも時間が解決してくれるのを待つことにした。ドメインの「信頼」は、SPF/DKIM/DMARCを完璧に設定しても、技術設定だけではどうにもならない部分がある、というのは、ウェブアクセスとメールの両方で学んだことだった。

つづく。

自分の名前が、まだ空いていた

ある日、自分の名前をそのままドメインにできないか調べてみた。taikiito.com — 空いていた。特にひねりのない、名前をつなげただけのドメインが、まだ誰にも取られていなかった。

自分の名前をドメインにしている人たちのパターンをいくつか見比べてみた。苗字だけを使う人、下の名前と苗字をそのまま一続きにする人、ニックネームをブランド化して実体は別サイトにリダイレクトさせている人。ハッカー文化だと、本名と切り離した完全に別のハンドルを使うことも多い。

自分の名前を看板にするなら、変にひねらず、名前をそのまま素直に繋げる形が一番しっくりきた。苗字を先にする(itotaiki.com)か、ハイフンを入れる(taiki-ito.com)かも迷ったが、結局一番シンプルな taikiito.com に決めた。

今のうちに取っておくことにした理由

ドメインは取りたてのうちは、ネットワーク製品の自動フィルタなどから「作られたばかりで分類のない(uncategorized)ドメイン」として警戒されやすい、と聞いたことがあった。これを回避する方法は基本的になく、ドメインの年齢とアクセス・送信履歴が積み上がって「信頼できるカテゴリ」に分類されるのを待つしかないらしい。

だったら、本格的に使う予定が固まっていない今のうちに取っておいて、気長に信頼が育つのを待てばいい。そう考えて、Cloudflare Registrarで taikiito.com を取得した(実費のみ、WHOISプライバシー込み)。.jp や .net も保険で押さえておくか迷ったが、.com 一本で十分だと判断した。

自分の名前がそのままアドレスになる、というのは、想像していたよりも気分が良かった。

つづく。