SASL（Simple Authentication and Security Layer）

この用語をシェア

SASLとは

SASL（Simple Authentication and Security Layer）は、RFC 4422で標準化された「プロトコルに依存しない認証フレームワーク」です。メールサーバーでは、SMTP AUTH（SMTP認証、RFC 4954）の実装基盤として使用され、メール送信時のユーザー認証を実現します。Submission（ポート587）での認証に不可欠な技術であり、IMAPやPOP3でのメールボックスアクセス認証にも同じ枠組みが使われています。

SASLが登場した背景には、SMTP・IMAP・POP3・LDAPといった各プロトコルがそれぞれ独自の認証方式を持つと、認証方式を追加・更新するたびにプロトコル仕様自体を書き換える必要が生じるという問題がありました。SASLは「認証のやり取り方法（メカニズム）」を各プロトコルから切り離して抽象化することで、新しい認証方式（例：SCRAM-SHA-256やOAUTHBEARER）が登場しても、プロトコル本体を変更せず追加のメカニズムとして差し込めるように設計されています。この設計思想はTLSにおける暗号スイートの拡張性とよく似ています。

SASLの仕組み・詳細解説

SASLは単一の技術ではなく、「メカニズムのネゴシエーション」「クレデンシャルの交換手順」「成功・失敗の通知」という3つの要素からなる認証の骨組みです。以下、実装レベルで押さえておくべきポイントを整理します。

SASLはプロトコルではなく「認証の抽象化レイヤー」

SASL自体は特定の暗号方式やパスワード検証ロジックを持ちません。各アプリケーション層プロトコルが「SASLをどう組み込むか」を規定し（SMTPならAUTH拡張＝RFC 4954、IMAPならAUTHENTICATEコマンド＝RFC 3501、POP3ならAUTHコマンド＝RFC 5034）、SASL側は「どういう手順でユーザー名・パスワード等をやり取りするか」という認証メカニズム（PLAIN、CRAM-MD5、SCRAM-SHA-256など）を規定します。この役割分担により、Postfix・Dovecot・Cyrus IMAPのような別々の実装が、Cyrus SASLやDovecot SASLといった共通の認証バックエンドを使い回せるようになっています。

認証ネゴシエーションのステートマシン

SASL認証は概ね次の手順で進みます。①クライアントがサーバーの対応メカニズム一覧を確認する（SMTPならEHLO応答のAUTH行）。②クライアントが使用するメカニズムを選びAUTHコマンドで開始する。③メカニズムによってはサーバーがBase64エンコードされたチャレンジを追加で返す。④クライアントがレスポンスを返す。⑤サーバーが認証成功（235）または失敗（535等）を応答する。PLAINやLOGINは1往復で完結しますが、CRAM-MD5やSCRAM-SHA-256はチャレンジ・レスポンスを複数回やり取りします。実際のSMTPセッションは次のようになります。

S: 220 mail.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-mail.example.com
S: 250-AUTH PLAIN LOGIN CRAM-MD5 SCRAM-SHA-256
S: 250 STARTTLS
C: AUTH PLAIN AGluZm9AZXhhbXBsZS5jb20AcGFzc3dvcmQxMjM=
S: 235 2.7.0 Authentication successful

上記のAGluZm9A...はBase64文字列で、デコードすると\0info@example.com\0password123（RFC 4616で定義された「authzid\0authcid\0password」形式）になります。認証ID（authcid）と認可ID（authzid）を分離できるのがPLAINメカニズムの特徴で、代理送信などのユースケースにも対応できます。

IMAP・POP3におけるSASLの扱いの違い

IMAPではAUTHENTICATEコマンドでSASLを起動し、CAPABILITY応答にAUTH=PLAINのようにサポートメカニズムが列挙されます。POP3は本来USER/PASSコマンドによる独自認証のみでしたが、RFC 5034でAUTHコマンドが追加されSASLに対応しました。Dovecotのような実装では、SMTP submission・IMAP・POP3のすべてで同一の認証バックエンド（authソケット）を共有できるため、ユーザーDBやパスワードポリシーを一元管理できるのが運用上の大きな利点です。

認証データはBase64でエンコードされるが暗号化ではない

SASLメカニズムのやり取りで使われるBase64は「難読化」であって「暗号化」ではありません。ネットワークを盗聴できる第三者はBase64文字列を一瞬でデコードできます。したがってPLAINやLOGINのような平文相当のメカニズムを使う場合は、TLS（STARTTLSまたは暗号化ポートでの直接TLS）でセッション全体を保護することが前提条件になります。SASL自体は「本人確認（認証）」を担う技術であり、「通信路の保護（暗号化）」はTLSの役割という点を混同しないことが重要です。

SASLの主な認証メカニズム

代表的な認証方式

• PLAIN: ユーザー名・パスワードを平文で送信（TLS併用必須）
• LOGIN: PLAIN類似（Base64エンコード、事実上のレガシー方式）
• CRAM-MD5: チャレンジ・レスポンス方式（MD5ハッシュ化、既知の弱点があり非推奨）
• DIGEST-MD5: より強固なハッシュ認証だが仕様として非推奨（Obsolete）扱い
• SCRAM-SHA-256: ソルト付きチャレンジ・レスポンス方式。サーバー側は平文パスワードを保存せずに検証でき、リプレイ攻撃にも耐性がある現行の推奨方式
• GSSAPI: Kerberos認証（Active Directory等の企業環境向け）
• EXTERNAL: TLSクライアント証明書など、SASL外の手段で既に確立された認証情報を利用
• OAUTHBEARER: OAuth 2.0のアクセストークンをSASLの枠組みで運ぶ方式（RFC 7628）

メカニズム比較表

推奨設定

現代のメールサーバーでは、PLAIN（またはSCRAM-SHA-256）＋STARTTLSの組み合わせが標準的です。TLS暗号化により、平文相当のパスワード送信も安全に行えます。CRAM-MD5やDIGEST-MD5のような古いチャレンジ・レスポンス方式は、実装によってはSCRAM系ほどの安全性がなく、既に非推奨（Historic/Obsolete）に分類されているため、新規構築では有効化しないのが定石です。

SASLの具体例・ユースケース

ケース1: メールクライアントからのSMTP送信認証

ThunderbirdやOutlookのようなメーラーがSubmission（587番ポート）に接続し、ユーザーがメールソフトに登録したユーザー名・パスワードでPLAINまたはLOGINメカニズム（STARTTLS併用）で認証する、最も一般的なSASL利用シーンです。ここで認証ユーザーとFROMアドレスの整合性をsmtpd_sender_login_maps等でチェックしておくと、認証済みアカウントを踏み台にした「詐称送信」を防げます。

ケース2: SaaSアプリケーション・業務システムのトランザクションメール送信

自社が開発するWebアプリケーションがパスワードリセットメールや注文確認メールなどのトランザクションメールを送信する場合、PHPMailerやNodemailerといったSMTPライブラリがSASL PLAINで認証を行い、submissionポート経由で自社のPostfix等に接続する構成が典型的です。バッチ処理やcronジョブから送信する場合も同様に、専用の送信用アカウント（他の一般ユーザーとは権限を分けたアカウント）を用意してSASL認証させるのが定石です。

ケース3: Webメール（Roundcube等）からのIMAPアクセス

RoundcubeのようなWebメールクライアントは、ブラウザ側で受け付けたログイン情報をバックエンドのDovecot IMAPサーバーに転送し、SASL PLAIN（またはLOGIN）で認証してからメールボックスの内容を取得・表示します。Webメールとメールサーバーが別ホストの場合は、この区間もTLSで保護されているかを必ず確認する必要があります。

ケース4: クラウドメール（Microsoft 365 / Google Workspace）とのOAUTHBEARER連携

Microsoft 365やGoogle Workspaceは、SMTP/IMAPでのパスワード直接送信による「基本認証」を段階的に廃止する方向にあります。外部システムやオンプレメールサーバーからこれらのクラウドサービスへメールを中継・取得する連携（例：バックアップ用のIMAPアクセス、業務システムからの送信代行）では、SASLのOAUTHBEARARメカニズムでOAuth 2.0のアクセストークンを引き渡す実装への切り替えが必要になるケースが増えています。

SASLのメリット・デメリット

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

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

Postfix + Dovecot SASL設定

PostfixでDovecot SASLを使用する設定：

# /etc/postfix/main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes

# Submission認証必須
smtpd_recipient_restrictions = 
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination

Dovecot SASL設定

# /etc/dovecot/conf.d/10-master.conf
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

# /etc/dovecot/conf.d/10-auth.conf
auth_mechanisms = plain login

Docker Mailserverでの設定

Docker Mailserverでは、SASL認証が自動的に設定されます：

services:
  mailserver:
    environment:
      - ENABLE_SASLAUTHD=1
      - SASLAUTHD_MECHANISMS=rimap
    # ユーザー追加
    # docker exec -it mailserver setup email add user@example.com password

トラブルシューティングと監視

SASL認証がらみのトラブルは「認証情報自体が誤っている」「TLSの前段が確立していない」「バックエンド（saslauthd/Dovecot auth）に接続できていない」の3系統に大別できます。まず切り分けとして次のコマンドを使います。

# Dovecotのauth testコマンドで認証情報を直接検証（Dovecot SASLの場合）
doveadm auth test user@example.com

# saslauthdの動作確認（Cyrus SASLをバックエンドに使う場合）
testsaslauthd -u user@example.com -p 'password'

# Postfixの現在のSASL関連設定を確認
postconf -n | grep sasl

# 認証失敗ログの抽出
sudo journalctl -u postfix | grep "SASL LOGIN authentication failed"
sudo journalctl -u dovecot  | grep "auth failed"

よくあるログの例として、Postfixのwarning: hostname[IP]: SASL LOGIN authentication failed: UGFzc3dvcmQ6は多くの場合パスワード不一致、SASL authentication failure: cannot connect to saslauthd serverはsaslauthdデーモン未起動やソケットパーミッションの不整合、DovecotのDisconnected (auth failed, 1 attempts)は該当ユーザーのパスワードDB参照に失敗していることを示します。認証失敗が特定のIPから継続する場合は、fail2banのpostfix-saslジェイル等でのブロックも検討します。

セキュリティベストプラクティス

• TLS暗号化必須: PLAIN・LOGINメカニズムはTLS併用が必須。smtpd_tls_auth_only = yesを設定し、TLS確立前のSASL認証コマンド自体を拒否する
• 平文メカニズムの制御: smtpd_sasl_security_options = noanonymous, noplaintextとし、smtpd_sasl_tls_security_options = noanonymousでTLS確立後のみPLAIN等を許可する構成にする
• 認証失敗のレート制限: smtpd_client_connection_rate_limitやfail2banと組み合わせ、ブルートフォース攻撃を検知・遮断する
• 強固なパスワードポリシー: 12文字以上・辞書語を避けた複雑なパスワードを要求し、可能であればSCRAM-SHA-256のようにサーバー側で平文パスワードを保存しない方式に寄せる
• 送信者検証: smtpd_sender_login_mapsで認証ユーザーとFROMアドレスの一致を確認し、内部アカウントを使った送信者詐称を防ぐ
• 古いメカニズムの無効化: DIGEST-MD5・CRAM-MD5のような非推奨メカニズムはauth_mechanismsから外し、PLAIN/SCRAM-SHA-256/OAUTHBEARERに限定する
• 第三者アプリ向けはアプリパスワードよりOAuthを優先: 外部SaaSやモバイルアプリを連携させる際は、可能な限りOAUTHBEARERによるトークン認証を選び、恒久的な平文パスワードの共有を避ける

fail2banと組み合わせる場合の設定例は以下の通りです。

# /etc/fail2ban/jail.local
[postfix-sasl]
enabled  = true
port     = smtp,465,submission
filter   = postfix-sasl
logpath  = /var/log/mail.log
maxretry = 5
bantime  = 3600

関連ブログ記事

• Docker Mailserver完全ガイド
• メール認証技術SPF/DKIM/DMARC

まとめ

SASLは、SMTP・IMAP・POP3・LDAPなど複数のプロトコルで再利用できる、プロトコル非依存の認証フレームワークです。SASL自体は暗号化を提供しないため、自社メールサーバーでは、SASL認証の有効化、TLS（STARTTLS）暗号化との併用、SCRAM-SHA-256やOAUTHBEARERといった安全なメカニズムの選択、そしてfail2ban等によるブルートフォース対策を組み合わせることで、初めて安全なメール送受信環境を構築できます。特にSubmission（ポート587）では、SASL認証とsmtpd_tls_auth_only = yesの組み合わせを必須とし、平文パスワードがネットワーク上に流れない構成にすることが重要です。今後はクラウドメールとの連携を中心にOAUTHBEARERへの移行が進むため、既存のPLAIN/LOGIN構成に依存しすぎないよう、認証メカニズムの棚卸しを定期的に行うことをおすすめします。

よくある質問（FAQ）

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

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