Posts on ma3ki's memo

dovecot2.4.4にアップグレードしたらSieveのheader :regexで日本語Subjectが文字化けした

Tue, 14 Jul 2026 07:48:00 +0900

Rocky Linux 9 (Dovecot 2.3系) から AlmaLinux 10 (Dovecot 2.4.4) へメールサーバを移行したところ、WordPress(Postie)へメール投稿する際に件名が文字化けするようになった。

例えば、“ランドセル” という件名が、 “ã©ã³ãã»ã«” のように文字化けする。最初はPostie や WordPress、phpなどを疑ったが、原因はその前に件名を修正していた Sieve の header :regex にありました。

状況

もともと使用していた Sieve ルールは件名の先頭に日付(YYYY/MM/DD)を挿入する以下のようなもの。

require ["editheader","fileinto","regex","variables","date"];

if header :regex "Subject" "(.*)" {
    set "subj" "${1}";
    deleteheader :regex "Subject" ".*";
    addheader "Subject" "2026/07/14 ${subj}";
}

Rocky Linux 9 (Dovecot 2.3系) では想定通りに動作していました。

対応

Pigeonhole 2.4 系では regex が Unicode comparator をサポートしたことに気付きました。(Chatgptが) 比較器を明示すると想定通り動作します。

require [
    "editheader",
    "fileinto",
    "regex",
    "variables",
    "date",
    "comparator-i;unicode-casemap"
];

if header :comparator "i;unicode-casemap"
          :regex "Subject" "(.*)"
{
    set "subj" "${1}";
    deleteheader :regex "Subject" ".*";
    addheader "Subject" "2026/07/14 ${subj}";
}

さくらのAI Engineを使った対話型AIアバターを作ってみた

Tue, 07 Apr 2026 23:17:00 +0900

先日、とある会社のオフィスを訪問するとエントランスにAIと連携した3Dの社員が設置されており面白いと思った。アニメ風かつ口パクなら自分でも似たようなもの作れるんじゃないか？と考え、最近遊んでいるさくらのAI Engineを使って会話文、音声データを生成するものを作ってみた。コードと画像は普段使っているgeminiで生成した。

デモ動画

会話がインチキすぎて成り立たず笑ってしまったw

Your browser doesn't support HTML5 video. Here is a link to the video instead.

リポジトリ

ai_conversation

仕組み

「会話生成API」にて回答と感情の抽出ブラウザで認識した音声をテキスト化し、さくらのAI Engine の会話生成APIへリクエストを送信します。プロンプトによって回答の冒頭に [happy] などの感情タグを付与するように制御しており、バックエンド側でこのタグを解析することで、回答文と「キャラクターの今の感情」を切り分けて抽出しています。
「音声合成API」による発話データの生成音声データの生成(再生)は３パターンに対応した。複数対応した理由はさくらのAI Engineの音声合成APIは無料枠が限られているため。

さくらのAI Engine の音声合成APIに渡して固有の音声データ生成
edge-tts
Chromeブラウザ内蔵TTS

ブラウザ側での感情表現とリップシンク制御フロントエンドは、受け取った感情データに基づいてキャラクターの画像を切り替えながら、音声の再生時間に合わせて「口の開閉画像」を一定間隔でループさせることで、口パクを実装しました。これにより、AIの回答とキャラクターの動きが同期した自然な対話体験を作っています。

作ってみて

キャラクター画像と設定ファイルを用意すればどんなキャラクターにも対応できるので面白いと思った。例えばアニメのキャラクター画像を生成して子供と会話させてみたり。

Rspamd GPT Plugin をさくらのAI Engine で動かしてみるその2

Wed, 11 Feb 2026 22:12:08 +0900

前回の記事「Rspamd GPT Plugin をさくらのAI Engine で動かしてみた」で Rspamd のバージョンを 3.13.0 から 3.14.2 へ更新してから40日が経過しました。AI 側に送信するプロンプト（指示文）も改善されたので記事に残しておきます。

約4,000通の受信データを解析したところ、AIの「回答」が変化し、実用的なフィルタへと進化していることが分かりました。

1. 判定結果の劇的な変化（比較）

バージョンアップ前後で、判定の割合は以下のように変化しました。違いは、新しく導入された GPT_UNCERTAIN（判定保留） の登場です。

判定項目	以前 (v3.13.0)	今回 (v3.14.2)	傾向と分析
GPT_HAM (安全)	44.1%	72.3%	救済ルールにより「白」判定が大幅増。
GPT_UNCERTAIN (保留)	0%	19.9%	証拠不十分なものを「保留」にする慎重派へ。
GPT_SPAM/PHISHING	9.6%	4.3%	確実な「黒」のみを絞り込み。誤判定が激減。
NONE (判定なし)	3.6%	3.5%	既存フィルタで確定したスパムは賢くスキップ。

「無理に白黒つけない」

以前のプロンプトは「厳格に判断せよ」という指示だったため、少しでも怪しいとスパム扱いされ、誤判定もありました。更新後は「複数のレッドフラグがない限り決めつけない」というルールが徹底されており、柔軟な判断になっています。

2. 判定理由の具体例（英文と日本語訳）

AIが実際にどのような理由（X-GPT-Reason）で判定を下しているのか、各カテゴリーの代表例をまとめました。

【GPT_HAM】（安全）

信頼できる送信元や、正当なビジネスメールが正しく認識されています。

Legitimate recruitment email from known domain with no suspicious requests. （既知のドメインからの正当な求人メールであり、不審な要求は見られません。）
Legitimate job scouting email from a known domain with no malicious requests or urgent threats. （既知のドメインからの正当なスカウトメールであり、悪意ある要求や緊急の脅しはありません。）
Official transactional update from a recognized service with no phishing indicators. （認識されているサービスからの公式な通知であり、フィッシングの兆候は見られません。）

【GPT_UNCERTAIN】（保留）

安全そうだが100%の確証がないグレーゾーンです。日本の配信システム経由のメールに多い傾向があります。

Legitimate technical mailing list discussion with no suspicious requests or links. （不審なリンクや要求はありませんが、技術的なメーリングリストでの議論のようです。）
Promotional language found, but it originates from a potentially recognized sender. （宣伝的な表現が含まれていますが、認識されている送信者からの可能性があります。）
A standard technical update or notification that does not meet the strict threshold for ham. （標準的な通知ですが、完全に安全と断定するための厳格な基準には達していません。）

【GPT_SPAM】（迷惑メール）

詐欺ではないものの、一方的な宣伝や過度な売り込みを検知しています。

Unsolicited promotional email pushing a business seminar with sensational claims. （衝撃的な主張を伴う、未承諾のビジネスセミナー勧誘メールです。）
Dense promotional offer with discounts and coupon roulette, typical of marketing spam. （割引やクーポンが詰め込まれた過度な宣伝で、典型的なマーケティングスパムです。）
The email is a promotional solicitation with multiple marketing pitches and calls‑to‑action. （複数の宣伝文句や行動を促す言葉が含まれた、一方的な営業メールです。）

【GPT_PHISHING】（フィッシング詐欺）

なりすましやアカウント停止を装う「明確な悪意」を正確に射抜いています。

Sender uses unrelated domain and links to a third‑party URL instead of an official domain. （送信者が無関係なドメインを使用し、公式サイトではないURLへ誘導しています。）
Urgent threat about account restriction combined with a mismatched URL domain. （アカウント制限という緊急の脅しと、送信元と一致しないドメインのURLが含まれています。）
Uses a fake sender address and directs users to a suspicious URL, classic signs of phishing. （偽の送信アドレスを使用し、不審なURLへ誘導しています。フィッシングの典型的な兆候です。）

3. さくらのAI Engine の活用について

2ヶ月半使ってみて、 さくらのAI Engine は迷惑メール判定に十分活用できるということがわかりました。

安定性: さくらのAI Engineの平均判定時間は 1.66秒。最長でも3秒程度。
納得感: 判定理由（Reason）を読むと、AIが文脈をしっかり理解して「なぜ怪しいか」を論理的に説明している

毎日100通前後のメールが届いており、月末に無料枠を使い切っていた。 Rspamd のログを確認したところ、1/30 20時頃から制限され、2/1 8時過ぎまで続いた。月初の9時にリセットされるのかな。

2026-01-30 20:11:11 #3605770(normal) <ace518>; lua; gpt.lua:896: bad reply: {"error":{"message":"rate limit exceeded"}}
...
2026-02-01 08:17:52 #3605770(normal) <67de09>; lua; gpt.lua:896: bad reply: {"error":{"message":"rate limit exceeded"}}

この記事は Gemini と壁打ちして作成しています。

RoundcubeとAutheliaで2要素認証を試してみた

Sat, 24 Jan 2026 23:43:33 +0900

メールサーバの2要素認証について調べていたら自身で運用しているメールサーバでも少し頑張れば動かせそうだったので試してみました。

現在のメールサーバの構成

freenginxのmail_moduleによるMail Proxyを設定しており、そこでTLSを終端している。認証には自前のphpスクリプトを介してLDAP認証をし、LDAPからProxy先のdovecotの情報を得ている。 dovecotでは認証をしていない。また、メールの送信については、Proxy先がpostfixになりxclientを使用して同じく認証はしていない。

2要素認証設定後のメールサーバの構成

2要素認証のためにAutheliaを導入し、認可やトークン発行周りの処理を一任した。図には書いてないがバックエンドはMySQLを選択。自前のphpスクリプトは10年前に作成したもの。今回geminiにXOAUTH2対応とついでにリファクタリングをしてもらった。 KeycloakではなくAutheliaを選択したのは、サーバのメモリ節約のためJavaを動かしたくなかったから。

ログイン画面遷移

Roundcubeのログイン画面 Autheliaのログイン画面 Autheliaの2要素認証画面(初回) Autheliaの2要素認証画面

メモ

Roundcube
- この構成ではpasswordプラグインでのパスワード変更は不可
- managesieveプラグインも認証できず動作しないが、少しソースを修正することで動作を確認した
試してみて
- 自分の使い方で実用性があるかというと微妙だが、今まで何となく使用する側だった2要素認証の仕組みを理解できたのはよかった。
- ClientにThunderbirdが利用できないかと試行錯誤をしていたが、任意のOAuth2クライアントに対応していないことがわかり諦めた。

Rspamd GPT Plugin をさくらのAI Engine で動かしてみる

Thu, 01 Jan 2026 14:40:41 +0000

Rspamd 3.9以降で標準的な外部AI連携機能（GPT Plugin）が利用可能になりました。
１ヶ月程度使用してみたので久しぶりに何か書いてみます。

環境

サーバ: さくらのVPS
OS: Rocky Linux 9.5
Rspamd: 3.13.0
LLM: さくらのAI Engine

メールサーバは個人ドメインのもので月2500通程度メールが届く
さくらのAIエンジンは月3000リクエストまでは無料のプランがある

設定

/etc/rspamd/local.d/gpt.conf  
enabled = true;  
type = openai;  
url = https://api.ai.sakura.ad.jp/v1/chat/completions;  
api_key = さくらのAI Engine の アカウントトークン;  
model = gpt-oss-120b ;  
autolearn = true;  
timeout = 10s;  
allow_ham = true;  
reason_header = X-GPT-Reason;

判定例

X-GPT-Reason に判定理由
X-Spamd-Result に GPT_PHISHING や GPT_SPAM、GPT_HAMなどが追加される。

結果

集計対象メール数: 2,485 通
GPTの判定平均時間: 1.66 秒 (最長で3秒程度)

さくらのAI Engine の利用グラフ

1. 【HAM（正常）】判定に多い理由

英文の理由	日本語訳
Legitimate technical mailing list discussion with no suspicious links or requests, indicating ham.	不審なリンクや要求を含まない、正当な技術系メーリングリストの議論であるため、HAM（正常）と判断
The email is a legitimate automated TLS report from example.com with no suspicious content.	example.com からの正当な自動生成TLSレポートであり、不審なコンテンツは含まれていない。
Legitimate job recruitment notification from a known domain (example.com) with matching sender info.	既知のドメイン（example.com）からの正当な求人通知であり、送信者情報も一致している。
Likely ham: a legitimate technical mailing list reply with matching domain and benign URLs.	正常な可能性が高い：ドメインが一致しており、無害なURLを含む正当な技術メーリングリストへの返信である。

2. 【GPT_PHISHING（フィッシング）】判定に多い理由

英文の理由	日本語訳
The email pretends to be from Amazon but originates from an unrelated domain (example.com) and uses suspicious links.	Amazonを装っているが、無関係なドメイン（example.com）から送信されており、不審なリンクを使用している。
Suspicious request for account update or login using an external URL (example.com/path) that is not the official domain.	公式ドメインではない外部URL（example.com/path）を使用して、アカウント更新やログインを促す不審な要求。
Uses urgency and suspicious links (example.com) to solicit personal information, typical of phishing scams.	フィッシング詐欺に典型的な、緊急性の強調と不審なリンク（example.com）を用いた個人情報の搾取。
Matches credential harvesting patterns by directing to a non-official login page for site administration.	サイト管理用の非公式なログインページへ誘導しており、認証情報搾取（クレデンシャル・ハーベスティング）のパターンに一致する。

3. 【GPT_SPAM（スパム）】判定に多い理由

英文の理由	日本語訳
High spam probability due to excessive promotional language, marketing keywords, and unsolicited recruitment.	過度な宣伝文句、マーケティングキーワード、および未承諾の求人勧誘が含まれるため、スパムの可能性が高い。
Primarily promotional content with multiple marketing links and emphasis on discounts or offers.	主にプロモーション内容であり、多数のマーケティング用リンクや、割引・特典の強調が見られる。
Frequent use of marketing phrases and a clear intent to drive traffic to a commercial service.	マーケティング用語が頻繁に使用されており、商業サービスへ誘導しようとする明確な意図がある。

注意

GPT_PHISHING がついたもので迷惑メールと判定されたくないものが数通あったので調査したところ、テストしていたrspamdバージョン(3.13.0)と最新のバージョンでプロンプトが大幅に改善されていることに気づいたので、バージョンアップ(3.14.2)をしてしばらくまた様子をみたい。

rspamd 3.13.0 のプロンプト

settings.prompt = "Analyze this email strictly as a spam detector given the email message, subject, " ..
      "FROM and url domains. Evaluate spam probability (0-1). " ..
      "Output ONLY 3 lines:\n" ..
      "1. Numeric score (0.00-1.00)\n" ..
      "2. One-sentence reason citing whether it is spam, the strongest red flag, or why it is ham\n" ..
      "3. Empty line or mention ONLY the primary concern category if found from the list: " ..
        table.concat(lua_util.keys(categories_map), ', ')

rspamd 3.14.2 のプロンプト

settings.prompt = "Analyze this email as a spam detector. Evaluate spam probability (0-1).\n\n" ..
      "LEGITIMATE patterns to recognize:\n" ..
      "- Verification emails with time-limited codes are NORMAL and legitimate\n" ..
      "- Transactional emails (receipts, confirmations, password resets) from services\n" ..
      "- 'Verify email' or 'confirmation code' is NOT automatically phishing\n" ..
      "- Emails from frequent/known senders (see context) are more trustworthy\n\n" ..
      "Flag as SPAM/PHISHING only with MULTIPLE red flags:\n" ..
      "- Urgent threats or fear tactics (account closure, legal action)\n" ..
      "- Domain impersonation or suspicious lookalikes\n" ..
      "- Requests for passwords, SSN, credit card numbers\n" ..
      "- Mismatched URLs pointing to different domains than sender\n" ..
      "- Poor grammar/spelling in supposedly professional emails\n\n" ..
      "IMPORTANT: If sender is 'frequent' or 'known', reduce phishing probability " ..
      "unless there are strong contradictory signals.\n\n" ..
      "Output ONLY 3 lines:\n" ..
      "1. Numeric score (0.00-1.00)\n" ..
      "2. One-sentence reason citing the strongest indicator\n" ..
      "3. Primary category if applicable: " ..
      table.concat(lua_util.keys(categories_map), ', ')

さくらのクラウドに RockyLinux9 でメールサーバを構築する

Thu, 05 Sep 2024 15:58:43 +0000

さくらのクラウドで自分が利用する構成の単体のメールサーバを構築する手順書兼スタートアップスクリプトを書いた。

https://github.com/ma3ki/startupscripts/tree/master/originalscript/mailsystem_rockylinux9

サーバを作成開始してから20分程度で完成する。

SPF/DKIM/DMARC/ARC に対応、送信StartTLS にも対応し、すぐに Gmailにも送信できちゃう。mta-sts はメールサーバ移行時に忘れててトラブったことがあるので不要と判断した。

さくらのレンタルサーバから転送するメールのSPF認証をpassさせる

Sun, 21 Apr 2024 13:21:04 +0000

2026/1/15 追記) さくらのレンタルサーバは ARC に対応したため、この対応は不要です。

さくらのレンタルサーバでメールを転送すると大抵の場合、転送先で SPF認証が fail します。

理由は送信元のメールアドレスを Envelope From に設定したまま転送先にメールを送信する為です。(大抵のレンタルサーバサービスのメール転送はこの仕様です)

さくらのレンタルサーバはメールの転送に maildrop を使用しているため、設定を書き換えることで転送メールの Envelope From を変更することができます。転送メールの SPF認証を pass させたい場合は、Envelope From をさくらのレンタルサーバで使用しているメールアドレスに書き換えればよいです。

.mailfilter は下記のように書き換えます。

$LOGNAME はさくらのレンタルサーバのメールアドレスが保存されている変数
FROMは Envelope Fromの変数
foobar@example.com は転送先のメールアドレス

FROM="$LOGNAME"
cc "!foobar@example.com"

これで転送先でSPF認証はpassします。

389 Directory Server マルチマスタレプリケーション設定

Sat, 06 Nov 2021 06:16:03 +0000

Rocky Linux 8.4 にて 389 Directory Server のマルチマスタレプリケーション設定を試した手順(※SELinuxは無効にしてます)

構成

1台目(サプライヤー1)のIPアドレス 192.168.1.1
2台目(サプライヤー2)のIPアドレス 192.168.1.2

1台目,2台目共通手順

#-- 389portの接続許可
# firewall-cmd --permanent --add-port=389/tcp
# firewall-cmd --reload

#-- 各種設定を変数に代入
# ROOT_DN="cn=Directory Manager"
# ROOT_PASSWORD="RootdnPassword"
# REP_DN="cn=replication manager,cn=config"
# REP_PASSWORD="ReplicaPassword"
# SUPIP1=192.168.1.1
# SUPIP2=192.168.1.2

#-- 389 Directory Serverのインストール
# dnf -y module enable 389-ds
# dnf -y install 389-ds-base openldap-clients

#-- version の確認
# rpm -qa 389-ds-base
389-ds-base-1.4.3.16-19.module+el8.4.0+636+837ee950.x86_64

#-- テンプレート作成
# dscreate create-template ldap.inf

#-- テンプレート編集
# sed -ri -e "s/;(root_password).*/\1=${ROOT_PASSWORD}\nroot_dn=${ROOT_DN}/" ldap.inf

#-- インスタンスを作成 (インスタンス名はデフォルトのlocalhostのまま)
# dscreate from-file ldap.inf
Starting installation...
Completed installation for localhost

#-- インスタンスを起動
# systemctl enable dirsrv@localhost.service
# systemctl start dirsrv@localhost

#-- データベースを作成
# dsconf localhost backend create --suffix="dc=example,dc=com" --be-name="userRoot"
The database was sucessfully created

2台目のみで実行

#-- レプリケーション用のアカウントを作成(replica-id=2)
# dsconf localhost replication enable --suffix="dc=example,dc=com" --role="master" --replica-id=2 --bind-dn="${REP_DN}" --bind-passwd="${REP_PASSWORD}"
Replication successfully enabled for "dc=example,dc=com"

#-- 389-ds のバージョンが 1.4.4.14以降の場合は role に supplier を使用する

1台目のみで実行

#-- ルートDNのエントリーを作成
# cat <<_EOL_> example_com.ldif
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: example.com

_EOL_

# ldapadd -x -h localhost -D "${ROOT_DN}" -w ${ROOT_PASSWORD} -f example_com.ldif
adding new entry "dc=example,dc=com"

#-- レプリケーション用のアカウントを作成(replica-id=1)
# dsconf localhost replication enable --suffix="dc=example,dc=com" --role="master" --replica-id=1 --bind-dn="${REP_DN}" --bind-passwd="${REP_PASSWORD}"
Replication successfully enabled for "dc=example,dc=com"

#-- レプリカ合意を作成し、サプライヤー2を初期化 (何故かコマンドの応答まで時間がかかる)
# dsconf localhost repl-agmt \
      create --suffix="dc=example,dc=com" --host="${SUPIP2}" --port=389 \
      --conn-protocol=LDAP --bind-dn="${REP_DN}" \
      --bind-passwd="${REP_PASSWORD}" --bind-method=SIMPLE --init \
      agreement-supplier1-to-supplier2
Successfully created replication agreement "agreement-supplier1-to-supplier2"
Agreement initialization started...

ここまででサプライヤー1 からサプライヤー2 へのデータ更新は同期されるが、
まだサプライヤー2 からサプライヤー1 へのデータ更新は同期されない

### 2台目のみで実行
#-- レプリカ合意を作成
# dsconf localhost repl-agmt \
      create --suffix="dc=example,dc=com" --host="${SUPIP1}" --port=389 \
      --conn-protocol=LDAP --bind-dn="${REP_DN}" \
      --bind-passwd="${REP_PASSWORD}" --bind-method=SIMPLE \
      agreement-supplier2-to-supplier1
Successfully created replication agreement "agreement-supplier2-to-supplier1"

これで双方向でデータ更新がされる状態となる