SMTP認証実施時に中継の制限【effect.dat】に "norelay,0" を指定したときの処理順序について new!

SMTP認証を実施している環境で中継の制限【effect.dat】に "norelay,0" の指定行を記述することにより、SMTP認証が通っても外部からの送信要求をさせないで拒絶することができます。このとき、SMTP認証の成否確認が先か、あるいは【effect.dat】で指定されるリレー禁止の制限が先か、処理順序について説明します。

１．中継の制限【effect.dat】に "norelay,0" を指定したとき想定されるリレー違反の拒絶以外のエラー応答について

以下のような【effect.dat】の設定を行っている前提で外部からの接続を行ったときに、想定しているリレー違反の拒絶ではなく、SMTP AUTHがらみのエラー応答が返されるケースがあります。この理由についてはメールクライアントからの接続時に、EHLO 後にAUTH コマンドで接続していないか、あるいは単純にHELOコマンドで接続した（ESMTPを有効にしていない設定）のいずれかの状況であることが考えられます。
（前提となる使用環境）
・ SMTP認証を認証ファイルレベルで導入、該当アカウントはSMTP AUTH必須
・ 中継の制限【effect.dat】の事例
　---------------------------------------------------------------------------------
　192.168.*.* default　←ローカル内にある全クライアントPCはデフォルト条件
　*.*.*.* norelay,0　　←外部を含むその他すべてからの送信要求・リレーは
　　　　　　　　　　　　 たとえSMTP AUTHで認証成功しても拒絶
　---------------------------------------------------------------------------------
２．SMTP認証を実施している環境で【effect.dat】に "norelay,0" を指定したときの実際の動きについて

SMTP認証を実施している環境で、【effect.dat】に "norelay,0" を指定しているときには、以下のような動きになります。

(1). クライアントから EHLO コマンド後にAUTH コマンドで接続していないか、単なる HELO コマンドを出して接続した場合、EHLOおよびAUTHを使った認証が先に必要となるため、送信要求や中継依頼の前に拒絶する

メールクライアント側でESMTP（拡張SMTP）を有効にしない設定で単なるHELOコマンドで接続したとき、あるいは、メールクライアント側でESMTP（拡張SMTP）を有効に設定していてもEHLOコマンド後にAUTHコマンドで接続しないとき、いずれも 503 5.0.0 Need EHLO before AUTH のエラー応答が先に返されます。
receivelog（SMTP受信詳細ログ）を取得すれば、ログから下記に抜粋するような内容が確認できます。
※ESMTP（拡張SMTP）を有効にする／しないは、メールクライアント種類によって設定ができるもの、設定がまったくできないものがあります。Outlook系ではSMTP認証を有効にするときにセットになっているようです。
---------------------------------------------------------------------------------
（HELOで拒絶される例） S:メールサーバ側、C:クライアント側
S: 220 xxxx.jp E-POST ESMTP Receiver (5.xx)
C: HELO [xxx.xxx.xxx]
S: 250 xxxx.jp Hello [xxxx.xxx.xxx], pleased to meet you
C: MAIL FROM: <xxx＠xxxx.jp>
S: 503 5.0.0 Need EHLO before AUTH
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
（EHLOするがAUTHせず拒絶される例） S:メールサーバ側、C:クライアント側
S: 220 xxxx.jp E-POST ESMTP Receiver (5.xx)
C: EHLO [xxx.xxx.xxx]
S: 250 xxxx.jp Hello [xxxx.xxx.xxx], pleased to meet you
C: MAIL FROM: <xxx＠xxxx.jp>
S: 503 5.0.0 Need EHLO before AUTH
---------------------------------------------------------------------------------
(2). クライアントから EHLO コマンド後にAUTHコマンドで認証成功しても、その後【effect.dat】に記述されている "noreray,0" に引っかかり、送信要求・中継リレーを拒絶する

クライアント側でSMTP認証を設定、EHLOコマンド後にAUTHコマンドで 235 2.0.0 Authentication successful. で認証成功の記録があっても、"RCPT TO:" の指定時に中継の制限【effect.dat】に指定された条件に引っかかり、550 5.7.1 Sorry xxx＠xxxx.jp, I don't allow unauthorized relaying. のエラー応答が返され、【effect.dat】に指定した意図通りに送信要求や中継リレーが拒絶されます。
receivelog（SMTP受信詳細ログ）を取得すれば、ログから下記に抜粋するような内容が確認できます。
---------------------------------------------------------------------------------
（EHLO後にAUTHで認証成功するが中継の制限の指定条件で拒絶される例）
　S:メールサーバ側、C:クライアント側
S: 220 xxxx.jp E-POST ESMTP Receiver (5.xx)
C: EHLO [xxx.xxx.xxx]
S: 250 xxxx.jp Hello [xxxx.xxx.xxx], pleased to meet you
C: AUTH CRAM-MD5　（※CRAM-MD5での例）
S: 334 [Base64エンコード：'認証キー情報'］
C: [Base64エンコード（メールアドレスと暗号化パスワード）］
S: 235 2.0.0 Authentication successful.
C: MAIL FROM: <xxx＠xxxx.jp>
C: RCPT TO: <xxx＠xxxx.jp>
S: 550 5.7.1 Sorry xxx＠xxxx.jp, I don't allow unauthorized relaying.
---------------------------------------------------------------------------------

　　　　　　　　　☆　　　　　　　　　　☆

以上のことから、ここであげたケースでは、EHLOやAUTHコマンドなどの確認、SMTP認証の成否確認があって、認証が通ったならその後に【effect.dat】のリレー禁止の制限が適用されるという順で処理されるという理解をしてください。

（参考FAQ）
●中継の制限【effect.dat】でSMTP認証と関連する "norelay,2" オプション
●SMTP AUTHあり／なしで接続したときの動作とメッセージについて
●SMTP AUTH有効時のログ記録からログインID（Username）などを知るには
●epstrd（SMTPレシーバー）応答コード