月別アーカイブ: 2026年3月

コンピュータ

SendGridからOCI Email Deliveryに乗り換えた話

コメントする

** この記事はClaude Codeと作業した記録をClaude Codeに記事にてもらい、Claude in Chromeを通してClaude Codeが投稿しています。 **

自宅サーバで長年お世話になっていたTwilio SendGridのFreeプランが、2026年3月31日で終了することになりました。4月1日から60日間のトライアルに移行し、5月末にはメール送信が止まってしまうとのこと。

うちのサーバではPostfix経由でSendGridを使って、Redmineの通知メールを飛ばしたり、lambeden.jpに届いたメールをGmailに転送したりしていました。さてどうしましょうか。

OCI Email Deliveryを選んだ理由

うちのサーバはOracle Cloud Infrastructure（OCI）のAmpere A1インスタンスで動いています。OCIにはEmail Deliveryというメール配信サービスがあって、月3,000通まで無料で使えます。同じプラットフォーム内で完結するので、これが一番スマートな選択肢かなということで移行してみました。

Claudeに手順を聞きながら作業しました (^_^)/

OCI Email Deliveryの設定

1. SMTP資格証明の生成

OCIコンソールで「アイデンティティ」→「ドメイン」→「Default」→「ユーザー」から自分のユーザーを開いて、SMTP資格証明を生成します。

⚠️ 生成されたユーザー名とパスワードはその場でコピー必須。画面を閉じると二度と確認できません！

2. 承認済み送信者の登録

「開発者サービス」→「電子メール配信」→「承認済送信者」で、メールのFromアドレスとして使うアドレスを登録します。

3. SPFの設定

承認済送信者の画面から「SPFの表示」でTXTレコードを確認して、お名前.comのDNS管理画面に追加します。

v=spf1 include:ap.rp.oracleemaildelivery.com ~all

4. DKIMの設定

「電子メール配信」→「電子メール・ドメイン」でドメインを作成して「DKIMの追加」からCNAMEレコードを生成、DNSに追加します。セレクター名はmail-tokyo-20260305みたいな形式が推奨されています。

10〜30分待って「Refresh DKIM Status」でActiveになれば完了です。

5. Postfixの設定変更

/etc/postfix/main.cfのリレーホストをOCIに変更します。

relayhost = [smtp.email.ap-tokyo-1.oci.oraclecloud.com]:587

/etc/postfix/sasl_passwdの認証情報も更新。

[smtp.email.ap-tokyo-1.oci.oraclecloud.com]:587    SMTPユーザー名:パスワード

あとSMTPUTF8関連のエラーが出たのでmain.cfに以下も追加しました。

smtputf8_enable = no

反映して動作確認。

sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix
echo "テスト" | mail -s "テスト" -r xxxx@lambeden.jp 宛先アドレス

Redmineの通知メールもバッチリ届くようになりました。

問題発覚：転送メールが弾かれる

実はlambeden.jpに届いたメールをGmailに転送する設定もしていて、ここでハマりました。

OCI Email DeliveryはエンベロープFromとヘッダFromの両方が承認済み送信者に登録されていないと拒否する仕様です。転送メールの場合、Fromは外部の不特定の送信者になるので、これは構造的にどうにもなりません。

解決策：転送だけGmail SMTPを使う

PostfixのTransport Mapsで、自分のGmailアドレス宛の転送メールだけGmailのSMTPサーバー経由で送るようにしました。

/etc/postfix/transportに追記：

xxxx@gmail.com    smtp:[smtp.gmail.com]:587

/etc/postfix/sasl_passwdにGmailのアプリパスワードを追記：

[smtp.gmail.com]:587    xxxx@gmail.com:アプリパスワード

/etc/postfix/main.cfにtransport_mapsを追加：

transport_maps = hash:/etc/postfix/transport

反映して動作確認：

sudo postmap /etc/postfix/transport
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix

iCloudからlambeden.jpにテストメールを送ったら、ちゃんとGmailに届きました！GmailはFromを自分のGmailアドレスに書き換えますが、X-Google-Original-Fromヘッダに元の送信者が保持されるので実用上問題ありません。

まとめ

最終的なPostfixの構成はこうなりました。

用途 経路
Redmine通知・外部への送信 OCI Email Delivery
Gmailへの転送 Gmail SMTP

OCI Email Deliveryは同じプラットフォーム内で完結するので管理が楽で良いですね。SendGridよりも設定の自由度が低い部分もありましたが、無事移行できて一安心です。

コンピュータ

GOGETSSLからLet’s Encryptに乗り換え

コメントする

今までGOGETSSLの証明書を使っていましたが、更新期限が来たのと、今後、証明書の期限が200日以内になるという話もあるので、これを機にLet’s Encryptに乗り換えてみました。

Let’s Encryptは無料で使えますが、有効期限が90日なので、自動更新でもしないとやってられません。はい。自動更新の仕組みあります(^^;

今回は、Claude Codeに手順を出してもらって実施しました。完璧に動きました。すごい。（操作も含めて実行してもらうこともできるのですが、ちょっと怖かったので手順を出してもらって自分で事項しましたが、全く問題ありませんでした。本当にびっくりです。）

手順は以下の通り

Let’s Encrypt SSL証明書の自動更新（Apache + Postfix）

1. Certbot のインストール

# Ubuntu/Debian
sudo apt update
sudo apt install certbot python3-certbot-apache

# RHEL/CentOS/Rocky Linux
sudo dnf install certbot python3-certbot-apache

2. Apache 用の証明書取得

# Certbot が Apache の設定を自動的に更新する場合
sudo certbot --apache -d example.com -d www.example.com

# 証明書のみ取得（Apache 設定は手動）
sudo certbot certonly --apache -d example.com -d mail.example.com

mail.example.com を Postfix 用に同じ証明書に含めることを推奨

3. Postfix の SSL 設定

sudo nano /etc/postfix/main.cf

# TLS 設定
smtpd_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/example.com/privkey.pem
smtpd_tls_security_level = may

smtp_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtp_tls_key_file  = /etc/letsencrypt/live/example.com/privkey.pem
smtp_tls_security_level = may

sudo systemctl reload postfix

4. 自動更新の設定（重要）

Certbot はインストール時に systemd タイマーまたは cron を自動登録します。確認：

# systemd の場合
sudo systemctl status certbot.timer
sudo systemctl enable certbot.timer

# cron の場合（/etc/cron.d/certbot が存在するか確認）
cat /etc/cron.d/certbot

5. 更新後フック（サービス自動リロード）

更新後に Apache と Postfix を自動リロードするフックを作成：

sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

#!/bin/bash
# Let's Encrypt 更新後に Apache と Postfix をリロード

echo "Reloading Apache and Postfix after certificate renewal..."
systemctl reload apache2   # Ubuntu/Debian
# systemctl reload httpd   # RHEL/CentOS

systemctl reload postfix

echo "Done: $(date)"

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

6. 動作テスト

# ドライランで更新をテスト（実際には更新しない）
sudo certbot renew --dry-run

# フックも含めてテスト
sudo certbot renew --dry-run --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

7. 証明書の状態確認

# 証明書一覧と有効期限
sudo certbot certificates

# Postfix の TLS 確認
openssl s_client -connect mail.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates

まとめ・ポイント

項目 内容
証明書の場所 /etc/letsencrypt/live/example.com/
自動更新タイミング 有効期限 30 日前（Certbot が自動判断）
フックの場所 /etc/letsencrypt/renewal-hooks/deploy/
更新頻度 1 日 2 回チェック（systemd timer）

ポイント：

  • Apache と Postfix で 同じ証明書ファイルを共有 できる
  • deploy/ フォルダのスクリプトは更新成功時のみ実行される
  • ポート 80 が外部から到達可能である必要がある（HTTP-01 チャレンジ）

ドメイン名や OS の種類を教えていただければ、より具体的な設定を出せます。

以上、本当にすごい時代になったものです。