Sieve

この用語をシェア

Sieveとは

Sieveは、サーバーサイドでメールをフィルタリングするための標準スクリプト言語です。IETF（Internet Engineering Task Force）によってRFC 5228として標準化されており、受信メールに対する自動振り分け、転送、削除、応答（不在通知）などの処理を、メールクライアントを一切起動することなくサーバー側で完結させます。

「Sieve（ふるい）」という名称は、届いたメールを条件に応じてふるい分けるという設計思想をそのまま表しています。C言語やPerl、シェルスクリプトのような汎用プログラミング言語とは異なり、意図的にチューリング完全ではないように設計されている点が仕様上の大きな特徴です。ループ構文や外部プログラム呼び出しの手段を持たないため、ユーザーが書いたスクリプトが無限ループやリソース枯渇、任意コード実行を引き起こす余地が構造的に排除されています。この「機能を絞った言語」という性質が、後述するメリット・デメリットの多くに直結しています。

Sieveの起源は1990年代後半にさかのぼります。当時Carnegie Mellon Universityで開発が進んでいたCyrus IMAPサーバー向けのメールフィルタ言語として設計され、その後IETFのSieve作業部会で標準化が進められました。基本仕様は1999年公開のRFC 3028を経て、2008年に改訂版であるRFC 5228として再発行され、現在この版が事実上の標準となっています。標準化団体が仕様を管理しているため、特定ベンダーの独自拡張に依存せず、実装間でスクリプトの可搬性が保たれている点も見逃せません。

実装としては、オープンソースのIMAP/POP3サーバーであるDovecotに統合されているPigeonhole（Dovecot Pigeonholeプロジェクト）が最も広く使われています。ここで注意したいのは、「Sieve」はあくまで言語仕様の名称であり、「Pigeonhole」はDovecotがその仕様を実装したソフトウェアコンポーネントの名称である、という点です。両者を同じものとして説明している資料も見かけますが、実務では区別して理解しておくと設定ファイルの参照先（dovecot.conf内のplugin { sieve = ... } ブロックがPigeonholeの設定である、等）を追いやすくなります。

Sieveの仕組み

Sieveスクリプトは、メールがメールボックスへ最終的に書き込まれる直前、すなわちLDA（Local Delivery Agent）またはLMTP（Local Mail Transfer Protocol）による配送処理のタイミングで評価されます。PostfixやSendmailなどのMTAが受信メールをDovecotのLMTPソケット（またはdeliverコマンド経由のLDA）へ引き渡すと、Dovecotは対象ユーザーのSieveスクリプトを読み込み、記述された順序でルールを評価し、条件がマッチしたアクションを実行します。SpamAssassinやRspamdによるコンテンツ判定はSMTP受信段階（Postfix側）で行われることが多く、Sieveはそのさらに後段、最終配送の直前で動くレイヤーだと理解すると全体像がつかみやすくなります。

スクリプトの基本構造は次の4段階で成り立っています。

1. require文で、そのスクリプト内で使用する拡張機能（テスト・アクション）をあらかじめ宣言する
2. if / elsif / elseによる条件分岐で、ヘッダーやエンベロープ（envelope）情報、本文サイズなどに対してテストを行う
3. 条件がマッチした場合にアクション（fileinto、redirect、discard、vacationなど）を実行する
4. 複数ルールが連続する場合はstop文で以降の評価を打ち切る（stopを書かなければ、後続のルールも引き続き評価される点に注意）

require宣言は単なる作法ではなく、実行環境（サーバー）側で有効化されている拡張機能しか使えないという制約と直結しています。Dovecot管理者はsieve_extensionsパラメータによって、利用可能な拡張をホワイトリスト（またはブラックリスト）形式で明示的に制御できます。つまりSieveには「言語仕様として定義されている機能」と「そのサーバーで実際に有効な機能」という2層があり、ユーザーが書いたスクリプトがサーバー側ポリシーによってrequireの時点で拒否されることがある、という点は運用上おさえておきたいポイントです。

Sieveスクリプト例

もっとも基本的な振り分けから、複数条件を組み合わせた実務的な例まで見てみます。

# 基本的なフィルタリング例
require ["fileinto", "reject"];

# スパムを削除
if header :contains "Subject" "[SPAM]" {
    discard;
    stop;
}

# メーリングリストを振り分け
if header :contains "List-Id" "dev-team.example.com" {
    fileinto "INBOX.MailingLists.Dev";
    stop;
}

# 特定送信者を重要フォルダへ
if address :is "from" "boss@example.com" {
    fileinto "INBOX.Important";
    stop;
}

# 不在通知（vacation）
if header :contains "To" "user@example.com" {
    vacation :days 7 "I am on vacation until next week.";
}

もう少し実務的な例として、複数条件のAND/OR、IMAPフラグ操作、通知拡張を組み合わせたスクリプトを示します。

# require節はまとめて宣言するのが一般的
require ["fileinto", "imap4flags", "envelope", "vacation", "variables"];

# 添付ファイル付きの大きいメールはArchiveへ、かつ既読フラグを付けない
if allof(header :contains "Content-Type" "multipart/mixed",
         size :over 5M) {
    fileinto "INBOX.Archive.LargeAttachments";
    stop;
}

# 社内ドメインからのメールだけ優先フォルダへ振り分け、重要フラグを付与
if envelope :domain :is "from" "example.co.jp" {
    setflag "\\Flagged";
    fileinto "INBOX.Internal";
    stop;
}

# 特定の送信者グループはどれか一つでも一致すれば振り分け（anyof）
if anyof(address :is "from" "billing@vendor-a.example",
         address :is "from" "billing@vendor-b.example") {
    fileinto "INBOX.Invoices";
    stop;
}

allof / anyof は論理AND・ORに相当する組み込みテストで、条件を入れ子にすることで複雑な判定も表現できます。ただし、Sieveには繰り返し処理（forループ相当）がないため、「同じパターンの条件を10件羅列する」ようなスクリプトは冗長になりがちです。この点はextlists拡張（外部リストの参照）である程度緩和できますが、根本的な柔軟性の限界として理解しておくとよいでしょう。

Sieveの主な機能（テスト・アクション・拡張）

RFC 5228が定義する基本アクションに加え、Sieveは用途ごとに追加のRFCで拡張されています。代表的なものを整理すると次のとおりです。

名称	分類	できること
fileinto	基本アクション	指定フォルダへメールを振り分ける
discard	基本アクション	エラーを返さずメールを破棄する
redirect	基本アクション	他のアドレスへ転送する
reject / ereject	拡張（RFC 5429）	送信者へエラー応答を返して拒否する
vacation	拡張（RFC 5230）	不在通知（自動応答）を送る。応答間隔（:days）を指定可能
imap4flags	拡張（RFC 5232）	既読/重要（\\Seen, \\Flagged等）のIMAPフラグを操作する
subaddress	拡張（RFC 5233）	user+tag@example.com形式のサブアドレスを判定する
variables	拡張（RFC 5229）	スクリプト内で変数を使い、マッチ結果を再利用する
editheader	拡張（RFC 5293）	メールヘッダーの追加・削除・書き換え
date / currentdate	拡張（RFC 5260）	日付・時刻を条件に含める
extlists	拡張（RFC 6134）	外部で管理されたアドレスリストを参照する
duplicate	拡張（RFC 7352）	Message-ID等で重複配送を検知して破棄する
include	拡張（RFC 6609）	他のSieveスクリプトを読み込み、共通ルールを再利用する

すべての拡張が常に使えるわけではなく、前述のとおりサーバー側のsieve_extensions設定次第で有効・無効が決まります。どの拡張が使えるかは、契約しているホスティング事業者やDovecotの設定ドキュメントで確認するのが確実です。

メリット・デメリット

メリット

• クライアント非依存で一貫した振り分け: サーバー側で実行されるため、PC・スマートフォン・Webメールのどこからアクセスしても同じ振り分け結果が得られます。IMAPで複数デバイスからメールを見る現代的な使い方と相性が良い設計です。
• 標準化による可搬性: RFC 5228として仕様が固定されているため、Dovecot以外の実装（Cyrus IMAP等）へ移行してもスクリプトをほぼそのまま再利用できます。
• 安全性の高さ: チューリング完全でない、外部コマンド実行機構を持たないという制約により、レンタルサーバーのような不特定多数のユーザーにスクリプト編集権限を開放しても、システム全体への影響を抑えやすい設計になっています。
• 遠隔管理が容易: ManageSieveプロトコル（RFC 5804）により、SSHのシェルアクセスを与えずとも、専用クライアントやWebUIからスクリプトを更新できます。
• 高度な自動処理: vacation（不在通知）やimap4flags（フラグ操作）、editheader（ヘッダー書き換え）など、単純な「振り分け」を超えた自動化が可能です。
• 非エンジニアでも扱えるGUIが存在: RoundcubeのmanagesieveプラグインやSOGoのフィルタ設定画面は、内部でSieveスクリプトを生成してくれるため、利用者がSieve構文を意識せずにルールを作成できます。

デメリット・注意点

• 汎用プログラミング言語ではない: 繰り返し処理や外部API呼び出し（Webhook通知、Slack連携など）はできません。複雑な自動化をしたい場合はMTA側のmilter機構やメールボックス監視型の外部連携ツールと組み合わせる必要があります。
• 拡張機能の可否がサーバー設定に依存: 管理者がsieve_extensionsで制限している場合、ユーザーが使いたい機能をrequireした時点でスクリプトエラーになります。
• 構文エラー時の配送失敗リスク: スクリプトに文法ミスがあると、設定によってはそのユーザーへのメール配送自体が失敗する場合があります。sieve_defaultによるフォールバックスクリプトの用意や、後述する構文チェックの運用が欠かせません。
• ManageSieveの通信保護が前提: TLSを有効化せずにManageSieveのポート（既定4190）を公開すると、認証情報が平文で流れる恐れがあります。STARTTLS必須の設定が事実上の必須要件です。
• 評価順序が複雑になりやすい: 組織全体で強制するsieve_before／sieve_afterスクリプトと、ユーザー個人のスクリプトが組み合わさると、どのルールがどの順で評価されているか把握しづらくなります。
• GUIエディタとの併用に注意: Webメールクライアントのルールエディタは、Sieve拡張の一部しかサポートしないことがあります。手書きで拡張機能を使ったスクリプトをGUIで開いて保存し直すと、意図せず内容が書き換えられる場合があるため注意が必要です。

混同されやすい用語・類似技術との違い

Sieve と procmail / maildrop

procmailは、Unix系OSで古くから使われてきたメールフィルタリングプログラムで、ユーザーのホームディレクトリに置く.procmailrcに独自の「レシピ」構文でルールを記述します。maildrop（Courier系で使われる）も考え方は近く、いずれも正規表現ベースの条件と、外部コマンドへのパイプ処理を含む、手続き的でより自由度の高い言語です。自由度が高い反面、外部プログラムを呼び出せてしまうためセキュリティ上の配慮が必要で、実行にはユーザーのシェルアカウントが前提になることが多く、レンタルサーバーのような共有環境では管理者が慎重に扱う対象でした。Sieveはこれと対照的に、意図的に機能を絞った宣言的な言語として設計されており、シェルアクセスなしにManageSieve経由で安全に開放できる点が最大の違いです。

Sieve とメールクライアントのルール機能（Outlook・Gmail・Thunderbirdのローカルフィルタ）

Outlookの「仕分けルール」やThunderbirdの「メッセージフィルター」は、既定ではクライアントアプリケーションが起動している間だけ、あるいはメールを取得したタイミングでのみ動作するローカル処理です（Exchangeの受信トレイルールのようにサーバー側で動くものもありますが、これはSieveとは別のベンダー独自機能です）。複数のPC・スマートフォンで同じメールアカウントを見ている場合、クライアントごとにルールを設定し直す必要があり、振り分け結果もクライアントごとに異なり得ます。Sieveは配送時にサーバー側で一度だけ評価されるため、どのデバイス・クライアントで見ても既に振り分けが完了した状態のメールボックスを参照することになります。

Sieve と Pigeonhole

前述のとおり、Sieveは言語仕様（RFC 5228ほか）であり、Pigeonholeはその仕様を実装したDovecot向けプラグインです。「Pigeonhole」という名称そのものは、Dovecotの設定ファイル中にはほとんど登場せず、設定はplugin { sieve = ... }のように「sieve」という名前で現れるため、両者が別物であることに気づきにくいという事情もあります。他のIMAPサーバー（Cyrus IMAP等）にも独自のSieve実装があり、「Sieveスクリプトの書き方」は共通でも「実装固有の設定方法」は変わる、という整理が正確です。

Sieve と単純な .forward / エイリアス転送

Postfixのエイリアス（/etc/aliases）や、ユーザーのホームディレクトリに置く.forwardファイルは、宛先を機械的に書き換えるだけの単純な転送設定であり、条件分岐によるフィルタリング機能は持ちません。「特定の条件を満たすメールだけ転送する」「一部は振り分け、一部は転送する」といった条件付きの処理をしたい場合は、Sieveのredirectアクションとif文を組み合わせる必要があります。

自社メールサーバー運用への応用

Dovecotでの設定

Dovecot + Pigeonholeでの基本設定は次のとおりです。ユーザー個人のスクリプトに加えて、sieve_before／sieve_afterで組織共通のルールを強制できる点が実務上重要です。

# /etc/dovecot/conf.d/90-sieve.conf
plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_default = /var/lib/dovecot/sieve/default.sieve

  # ユーザースクリプトより先に必ず評価される組織共通ルール（上書き不可）
  sieve_before = /var/lib/dovecot/sieve/global/spam-quarantine.sieve

  # ユーザースクリプトの後に評価される共通ルール（アーカイブ等）
  sieve_after = /var/lib/dovecot/sieve/global/archive-old-mail.sieve

  # スクリプトサイズの上限（肥大化・誤設定対策）
  sieve_max_script_size = 1M

  # 有効化する拡張を明示的に制御（+追加 / -無効化）
  sieve_extensions = +vacation +imap4flags +editheader -body
}

protocol lda {
  mail_plugins = $mail_plugins sieve
}

protocol lmtp {
  mail_plugins = $mail_plugins sieve
}

sieve_beforeは、たとえば「スパムスコアが一定以上のメールは問答無用でQuarantineフォルダへ」といった、ユーザーが誤って削除・変更できない全社ポリシーを強制するのに使います。sieve_afterは逆に、ユーザー個人のルールを尊重しつつ、それでも振り分けられなかったメールに対する最後の処理（例: 90日以上前のメールを自動アーカイブ）に向いています。

ManageSieve

ManageSieve（RFC 5804）は、Sieveスクリプトをリモートから安全にアップロード・切り替え・削除するためのプロトコルで、既定ポートは4190です。シェルアクセスを与えずにエンドユーザーへスクリプト編集を開放したい場合、実質的にこのプロトコルが前提になります。

# /etc/dovecot/conf.d/20-managesieve.conf
service managesieve-login {
  inet_listener sieve {
    port = 4190
  }
}

# TLSは10-ssl.conf側の ssl = required 設定を継承させ、
# 平文でのスクリプト送受信・認証を許可しないことが望ましい

運用上の注意点

• 構文チェック: Pigeonholeに付属するsieve-testコマンドを使うと、実際にメールを配送する前にスクリプトの構文と挙動をローカルで検証できます。本番反映前のCIやデプロイ手順に組み込んでおくと事故を防げます。
• ログの確認: Dovecotのログ（mail_debug有効時やsieveプラグインのログ）には、どのルールがマッチしfileintoやdiscardが実行されたかが記録されるため、「振り分けられるはずのメールが振り分けられない」といった問い合わせの一次切り分けに使えます。
• スクリプトのバックアップ: ユーザーごとの~/.dovecot.sieve（実体はsieveディレクトリ内の各スクリプトへのシンボリックリンク）は、通常のメールボックスと同様にバックアップ対象に含めておく必要があります。
• 移行時の互換性: 他のIMAPサーバーからDovecotへ移行する際、Sieveスクリプト自体はRFC準拠であれば概ね移植できますが、拡張の対応状況やサーバー固有の設定（sieve_extensions等）は移行先で個別に確認が必要です。

クライアント対応

Sieve自体はサーバーサイドの言語なので、エンドユーザーがルールを編集するには、Sieve/ManageSieveに対応したクライアントやWebUIが必要になります。

クライアント／製品	対応状況
Thunderbird	近年のバージョンではフィルタ設定画面からManageSieve経由でサーバー側フィルタを編集できる機能が搭載されています
Roundcube	managesieveプラグイン（同梱プラグインの一つ）を有効化することでGUIからルール編集が可能
SOGo	Webメール上のフィルタ設定画面でネイティブにSieveルールを生成・管理
Outlook / Apple Mail	Sieve/ManageSieveのネイティブ対応なし。サーバー側フィルタを使いたい場合はWebメールやThunderbird等、別クライアント経由での編集が必要

関連ブログ記事

• Docker Mailserver完全ガイド

まとめ

Sieveは、サーバーサイドで動作する標準的なメールフィルタリング言語です。クライアント非依存で振り分けルールが適用されるため、複数デバイスでメールを利用する現代の環境に最適です。procmailやmaildropのような手続き的な旧来のフィルタと違い、チューリング完全性をあえて持たせない設計により安全性を確保しつつ、ManageSieveによる遠隔管理でエンドユーザーへの機能開放も両立させています。Dovecot（Pigeonhole）との組み合わせが事実上の標準実装であり、自社メールサーバーで柔軟かつ安全なメール振り分けを実現したい場合の第一候補になります。導入・運用にあたっては、sieve_extensionsによる拡張制御、sieve_before／sieve_afterによる組織ポリシーの強制、構文エラー時のフォールバック設計まで含めて検討することをおすすめします。

よくある質問（FAQ）

この用語についてもっと詳しく

Sieveに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。