新型コロナの2024年秋の状況

新型コロナワクチンの5回目接種からそろそろ1年。

日本のニュースではあまり聞かなくなったけれど、今どんな状況かな？

札幌の下水に含まれる新型コロナのRNA濃度は、この8〜9月に2022年以降最大のピークを迎えていて、今ようやく落ち着いてきている様子。夏にピークがあって秋に急に落ちるのはこの3年共通しています。

定点医療機関あたりの患者報告数と比べてみると、増減の連動はあるものの、ウイルス総量は増えても病院にかかる人の割合は減ってきているように読めます。

西オーストラリアは落ち着いていて、下水にピークがあっても病院にかかる人が増えてないのは日本と同じ。季節は反対やけど。

オランダはこれからピークに向かうところかな。

変異株については、世界の主流はKP.3.1.1。日本だけKP.3.3という新バージョン(？)が流行ってます。

系統樹的にはこんな感じ。10月からワクチン接種が始まったJN.1は、KP.3系統の直系の先祖(？)になるので、去年打ったXBB.1.5のワクチンよりはだいぶ効きそう。

感染中和試験の結果、オミクロンKP.3.1.1株は、これまでのオミクロン系統の流行株（XBB.1.5株、EG.5.株、HK.3株、およびJN.1株）の既感染もしくはブレイクスルー感染（breakthrough infection, BTI）（注4）、またはオミクロンXBB.1.5株対応1価ワクチン（注5）接種によって誘導される中和抗体（注6）に対してオミクロンKP.3株より高い逃避能を示すことが分かりました。

とはいえ、KP.3.1.1はJN.1より後発なので、ワクチンが効きにくくはなってるみたい。KP.3.3は新しすぎるからか、論文も全然見つかりません。

市から補助の出る定期接種は65歳以上とかやけど、旅先でかかるとやっかいやし、Long COVIDの症状がかなりいやな感じなので自費で打っておこうかな。

ということで、都内の病院で申し込みをしました。

大きなところで使うべき技術を小さなところで

最近いろいろ独自ドメインのDNSをいじって遊んでいるけれど、以前数万人の社員さんを抱える会社の大元のDNSの運用管理をしていたことがあります。

大きな会社だと高度なセキュリティ技術とかが導入されてそうに思うんですが、案外そうでもないです。

たとえばDNSだと、構成変更をミスするとインターネット上から対外的に会社を消滅させることもできてしまうので、何か新しいセキュリティ技術を導入しようとすると「いかにこの構成変更に問題がないか」の説明やその準備が大変で、へたすると年単位の時間がかかります。それがあまりにめんどくさいので、現状維持でいいやとなってしまいがちなんです。ほかにいくらでもやることがあるし。

そんなわけで、当時手もつけられなかったDKIMとかDMARCの導入や実験が今独自ドメインでらくらくできるのは楽しいです。

レジストラの引っ越し(移管)を検討する

DNSの引っ越しはこないだやった以前にも仕事でやったことがあったんですが、さらにその上位のレジストラの引っ越しはまだやったことがないです。

▼こないだやったこと

レジストラ：シンドメイン–権威DNS：シンドメイン
↓
レジストラ：シンドメイン–権威DNS：Cloudflare

▼やってみたいこと

レジストラ：シンドメイン–権威DNS：Cloudflare
↓
レジストラ：どこか別のところ–権威DNS：Cloudflare

こんな感じ。

ドメインを取ってから60日たたないとできないので、やるとしても11/10以降になります。

レジストラ移管をしてみたいわけ

レジストラ移管にはどんな作業があって、サービス停止なしでやるにはどこを気をつけたらいいのか実際体験してみたいというのもあるんですが、ほかにも理由があります。

★DNSSEC対応

DNSには、今はまだ金融機関ぐらいでしか使われてない(？)DNSSECというセキュリティ技術があるんですが、Cloudflareは対応していても上位のシンドメインが対応してないので使えないんです。
(自分のDNSサーバのにせものを作られるハードルをめっちゃ上げる技術です。)

というわけで、独自ドメインでDNSSECを使ってみたいというのがひとつ。

★DNS管理のハードウェアトークン必須化

そしてDNSの乗っ取り耐性を上げたいというのがもうひとつ。

Cloudflareのログインには、2段階認証としてハードウェアトークン必須の設定にしてあるんですが、上位のシンドメインが乗っ取られたらCloudflareのセキュリティが無力化されてしまいます。「Cloudflareじゃない別のDNSが本物だ」という指定ができてしまうので。

シンドメインは2段階認証として、ワンタイムパスワードアプリが使えるんですが、6桁の数字だったら100万分の1の確率でまぐれ当たりもありえます。なので、レジストラ側のログインにもハードウェアトークンを必須にしたいです。

そんなわけで、引っ越し先はPorkbunにしようと考えています。

最初はCloudflareをレジストラにするのが一番よさそうに思えたんですが、.earthドメインの収容に対応してなくて断念(>_<)

あと、Porkbunはドメイン更新料がシンドメインより安そうなのもいいです。ドル払いになるので将来のレート次第やけど。

秋の出鼻をくじかれる

年次の健康診断関係も片づいたし、

ちぎれかかったGarminのベルトの替えも3週間待ってようやく届いたし、

そろそろ千葉を離れて塩の道に出かけようかなと思ったら・・・

(>_<)

中国行きは保留中で、カンボジア再訪も考えているんですが、気候のいい季節は日本をめぐらないともったいないので、各地の天気を見つつ検討中です。

CloudflareのEmail Workersで正規表現許可リストを使って複数宛先に受信メールを転送する

CloudflareのEmail Routing機能を使うと、受信アドレスごとに転送先を振り分けることができるんですが、Email Workersという機能を使えばスクリプトでもっと細やかな制御ができるようです。

たとえばどこかのサービス登録に使うアドレスは、そのサービスのドメインからのメールしか受信しないようにするとか。

Email Workersには、許可されたアドレスからのメールだけを転送するAllowlist sendersというテンプレートがあるんですが、そのままだと正規表現が使えないのでメールアドレスをフルで決め打ちする必要があるし、転送先が1つしか書けません。なので、これを改造してみることにしました。

とはいえスクリプトの文法がよくわからないので、いろいろなAIに頼んでみました。

それでEmail Workersでちゃんと動くコードが返ってきたのが、Claudeだけ。中国語の文法のわからないことを聞いてもかしこい答えを返すなあとふだんから感心していたんですが、コード生成でも優秀です。そもそもほかのAIは、Email Workersのコードを何の言語で書けばいいのかわかってなかったです。

で、そのClaudeの生成したものに若干手を加えてできたのが以下。

// Cloudflare Email Workers Forwarding Script with Regex Filtering

export default {
  async email(message, env, ctx) {
    // Regular expression patterns for allowed From addresses
    const allowedFromPatterns = [
      /^.*@aaa\.com$/i,
      /^.*@.*\.aaa\.com$/i,
      /^.*@bbb\.com$/i,
      /^.*@.*\.bbb\.com$/i
    ];

    // Forwarding destination email addresses
    const forwardToAddresses = [
      "[email protected]",
      "[email protected]"
    ];

    // Check the From address
    const from = message.from;

    if (allowedFromPatterns.some(pattern => pattern.test(from))) {
      // Forward the message to each destination address
      for (const forwardTo of forwardToAddresses) {
        // Forward the original message without modification
        await message.forward(forwardTo);
        console.log(`Forwarded email from ${from} to ${forwardTo}`);
      }
    } else {
      // Reject the email if it doesn't match the allowed patterns
      message.setReject("Address not allowed");
      console.log(`Set to reject email from ${from}. Reason: Address not allowed`);
    }
  }
}

aaa.comかbbb.comのメールアドレス(サブドメイン含む)がFromにあったら、 [email protected] と [email protected] に転送して、それ以外のメールは拒否するというコードです。
( [email protected] と [email protected] は、事前にCloudflareのダッシュボード上でEmail > Email Routing > Destination addressesに登録しておく必要があります。)

この正規表現からすると、Fromの末尾が厳密にaaa.comかbbb.comになっていないと転送されないように見えるんですが、メールヘッダ上“AAA” <aaa.com>のような形式のFromのメールでもちゃんと転送対象になります。さすがにそのあたりちゃんとわかってくれてます。

Email Workersの注意点

Email Workersはいろいろできておもしろそうなんですが、ちょっと注意点が。

Cloudflareのダッシュボード上、Email Workersで転送されたメールは、Email RoutingのActivity LogでResultがDroppedになってしまうんです。Forwardedでなく。

転送されずにRejectされたメールはDelivery Failedとなるので区別はつくんやけど。

ちなみに複数の転送先のうち転送できたところとできなかったところが混ざっていた場合もDelivery Failedでした。

追記 2024-11-24

Email Workersで転送されたメールのActivity LogでのResultが最近DroppedからForwardedに変わっていました。

ただ、たとえば1通の受信メールを4アドレスに転送した場合、Email Routing summaryでは

Total received: 5
Forwarded: 4
Dropped: 1
Other: 0

のようにカウントされています。

独自ドメインで無料でメール送受信する環境を作る

独自ドメインを使ってGoogle Workspaceをおためししていましたが、そろそろ無料期間が終わるので解約することにしました。

Google SitesのHTTPSでのwwwなしアクセスもGoogle Workspaceなしで無料でできることがわかったし、独自ドメインでのメール送受信も無料でできることがわかったので。

無料でのメール送受信

メール受信(転送)は、CloudflareのEmail Routing機能を使えば無料でできるということにはこの前ふれました。

で、無料での送信はどうやるか。

これにはMailgunというサービスを使うことにしました。このサービスの提供するSMTPサーバを使って送信する設定をGmailに入れて使います。1日100通までの送信なら無料。広告配信とかするのでなければこれで十分かな。

Mailgunは無料アカウントだと1ドメインしか管理できないので、生ドメインとそのサブドメインをいっしょに扱うことはできません。
(アカウント作成時にSMS認証があるので、2アカウント作る場合は電話番号が2つ必要かも。SMS認証しなくても各種設定はできるけど、実際のメール送信はできませんでした。)

さっきのプラン比較のページによると、“Authentication Protocols (SPF, DKIM, CNAME, DMARC, BIMI, etc.)“はFreeプランだと使えないことになっているんですが、SPF・DKIM・DMARCはなぜか問題なく使えて、受信側の検証もちゃんと通っています。

SPF・DKIM・DMARC非対応ドメインのブロックがGmailで始まったから、広く開放することにしたんかな？

しかもDKIMは2048ビットの鍵長にも対応しているので、そのあたりもGoogle Workspaceと遜色ないです。

ちなみに上位プランでしか使えないほかの機能へのアクセスにはちゃんとUpgradeの案内が出るので、おためし期間中だから全機能利用できてるみたいな感じではないです。そもそもおためし期間じゃないし。

DNS設定

DNS側の設定ですが、送信だけの目的なら、Mailgunの管理ページの

Send > Sending > Domains > (ドメイン名) > DNS Records

に書かれてあるSending recordsの2レコードだけ書けばいいです。
(わかりにくいけど、1つ目がDKIMで、2つ目がSPFです。)

SPF・DKIMレコードはSimpleLoginのと共存可能なので、Mailgunの設定を入れても送信はSimpleLoginでも問題なくできます。
(SPFはちゃんと1行に混ぜて書く必要があるけれど。)

Receiving recordsはMXレコード。受信メールをどのサービスに受け取らせるか。今回受信はCloudflareがやるので使いません。サブドメイン運用なしなら、Cloudflareでなくこっち使うのもありかも。正規表現でのメールの振り分けとか、複数宛先転送もできるみたいやし。

Tracking recordsって何やろ？と思ったんですが、送信メールに埋め込む既読検知用のビーコンとかUnsubscribeリンクとかのURLがこのドメインで書かれるみたいです。自分は使わないけど。

ちなみにこの送信メールに埋め込むUnsubscribeリンク、クリックされるとその後その宛先に一切メール送信ができなくなります。

「まちがってクリックしてしまった人のために戻す方法を提供してほしい！」というリクエストが2017年にフォーラムに出ていたんですが、まだ対応されてないようです。

このせいで、送信テスト用に使っているアドレスにまったく送れなくなってこまったので、Mailgunの設定でドメイン自体を消して登録しなおしたら送れるようになりました。DKIMキーも作り直し。

なぜかそれでも、Dashboardの統計データとかは消えずに引き継がれました。