FEATURE(`nocanonify', `canonify_hosts')を入れておきましょう。
2.6.6 エンベロープFROMのチェック
8.9以降ではエンベロープFROMにDNSで引けないドメイン名が含まれていると、メイルの受け取りを拒否するようになっています。 ファイアウォール内とかDNSで送信者のアドレスを引くことができないような環境だと、FEATURE(`accept_unresolvable_domains')を加えて、エンベロープFROMのチェックを行わないようにする必要があります。 これはCFでUSE_SENDER_DNS_CHECK=noを指定するのと等価です。
また、エンベロープFROMにドメイン部がないと、メイルを受け取りません。 そのようなメイルも受け取りたい場合は、
FEATURE(`accept_unqualified_senders')を指定します。 CFでNEED_SENDER_DOMAIN=noとCHECK_FROM_FQDN=noを指定するのに相当します。
2.6.7 リレー制限
おそらく、多くのサイトが、サイト外からのメイルのリレーは禁止するが、サイト内からのメイルはリレーを許可していることでしょう。freebsd.mcでは、relay_based_on_MXによるリレーのみが許可されています。 また、access_db機能が組み込まれていますので、access_dbを使ってアクセス制御を行うことができます。 つまり、access dbでRELAYとして許可されたホストあるいはドメインからのリレーが許可されます。 これ以外にも、access_dbは非常に多くの機能を持っています。
あるいは、RELAY_DOMAINを使って以下のように.mcファイル内に直接書いておくこともできます。
RELAY_DOMAIN(`example.com')RELAY_DOMAINには、ドメイン名やIPアドレスを指定することができます。
また、FEATURE(relay_entire_domain)を指定すると、クラス{m}で定義されたドメイン全体に対してリレーが許可されるようになります。
2.6.8 Message-Id:不正
CFでHDR_REJECT_BADMID=yesを指定し、Message-Id: ヘッダの内容に@が含まれない場合に受信を拒否している方も多いでしょう。 cfにはこれに対応するマクロはありませんのでリスト4のようにLOCAL_RULESETSを使って記述します。 この例では、HDR_REJECT_ACTION=discardの場合と等価になっています。
リスト4 Message-Id:不正メイルへの対処
3 SMTP AUTHを使おう
3.1 SMTP AUTHとは
世の中にはPOP before SMTPという仕掛けがはびこっています。 多くのSPAMが飛び交う昨今、会員などの許可された人だけがSMTPサーバを使える仕掛けは必須と言えるでしょう。しかし、ここでちょっと疑問を持って頂きたい。 メイルを出すのに使われるプロトコルはあくまでSMTPです。 なぜPOPで認証しないといけないのでしょうか？
答えは簡単です。 SMTPが認証の枠組を持っていなかったからです。 それを補うために考え出されたのがPOPbefore SMTPというやり方です。 要するに、メイルを出す前にPOP接続して、一定時間だけPOP接続元のホストからのメイルのリレーを受け付けるようにするわけです。
しかし、今はそんなまどろっこしいことをしなくても、SMTP自体が認証の枠組を持っています。 sendmailは8.10.XからSMTP AUTH*5)に対応しています。
ここで問題になるのがsendmail.cfです。8.10.Xというとsendmail.cfのフォーマットはV9/Berkeleyです。 SMTP AUTHの設定をしようとすると、V9/Berkeleyを使わなければなりません。 しかし、CFが対応していなのです。 つまり、CFを使っている限り (真っ当な方法では) SMTP AUTHは使えないということになります。
ここであきらめてはいけません。 POP before SMTPを駆逐するために、もとい、SMTP AUTHを使うためにも、是非cfを使えるようになりましょう。
3.2 SASLライブラリのインストールと設定
SMTP AUTHはSASLライブラリを使用します。 SASLはRFC2222に定義される認証のための枠組です。FreeBSDではports / packagesになっていますので、ports でインストールするなら、/usr/ports/security/cyrus-sasl/でmake installするだけです。
SASLで利用できる認証方式として、CRAM-MD5、DIGEST-MD5、LOGIN、PLAINなどがあります。 LOGINとPLAINは一応base64でエンコードはされていますが生パスワードがネットワーク上を流れますので、基本的に使わない方が良いでしょう。 ただし、NetscapeやOutlookExpressはSMTP AUTHに一応対応しているものの、NetscapeはPLAINのみ、Outlook ExpressはLOGINのみしか使えませんので、これらのメイラに対応させたい場合はPLAINとLOGINを有効にしないといけません。 広く使用されているメイラですので、悩ましいところです。
SASL認証は/usr/local/etc/sasldb.dbに格納されているパスワードによって行われます。 加えて、LOGINとPLAINについては、/etc/passwdを使うこともできます。 また、設定によってPAMなどを参照するようにもできます。
デフォルトでは、sasldbしか見ませんので、/etc/passwdを使用しPLAINまたはLOGINを許可したい場合は、
pwcheck_method: pwcheckと書いた/usr/local/lib/sasl/Sendmail.confを用意しましょう。
ports / packagesでインストールすると、FreeBSDのブート時にに
3.3 ユーザ管理
sasldbにパスワードを登録するには、sasldbに書き込みできる権限*6)でsaslpasswdコマンドを実行します。 例えばユーザumeを登録するには saslpasswd umeを実行します(図3)。 この時、realmはデフォルトでsaslpasswdコマンドを実行したホスト名になります。 realmを指定したい場合-uオプションを使用します。 ユーザを削除するのは-dオプションです。オフィシャルドメイン名をconfDOMAIN_NAMEで明示的に指定している場合は注意して下さい。 hostnameコマンドが返すホスト名と異なる名前を指定している場合、saslpasswdコマンドでユーザを登録する際に、-uオプションで同じホスト名を指定してあげる必要があります。*7)
図3 SASLパスワードの登録
現在登録されているユーザを確認したい場合はsasldblistusersコマンドを実行します(図4)。
図4 SASL登録ユーザの一覧表示
3.2 SASL対応sendmailの作成
次に、sendmailにSASLライブラリをリンクします。 /etc/make.confにリスト5の3行を追加します。 こうしておくと、make buildworldした際に必ず有効になりますので、FreeBSDを作り直した際にsendmailが元に戻ってしまうことなく便利です。 ここで、-D_FFR_UNSAFE_SASLは、後で述べるGroupReadableSASLFileを使えるようにするオプションで、sasldbをsendmail以外のアプリケーションと共有する際に必要となります。*8)さあ、sendmailを作り直しましょう。図5のようにmakeを行います。
リスト5 SASL用フラグ
図5 SASL対応sendmailの作成
3.2 sendmail.cfでのSASL関係ルール
動くsendmail.cfの元となる.mcファイルが既に用意されているなら、リスト6を追加して生成しなおすだけで、ルール的にはOKです。では、それぞれの意味を説明していきましょう。
リスト6 SMTP AUTHのための.mcファイルの設定
- define(`confDONT_BLAME_SENDMAIL', `GroupReadableSASLFile')
- define(`confRUN_AS_USER', `root:mail')
- SASLライブラリをports / packagesでインストールした場合、Cyrus IMAPサーバからの利用を考慮した設定となっています。
具体的には、imapdからアクセスできるように、SASLのパスワードデータベースである/usr/local/etc/sasldb.dbは所有者: cyrus、グループ: mailとなっており、グループに対するリード権限が与えられています。(図6)
そのため、sendmail側で、sasldbにグループに対するリード権限が付いていても許してあげる必要があります。 sendmailからしかSASLを使わないのであれば、この設定を入れずに、sasldbをrootだけが読めるようにしても構いません。図6 sasldbのパーミッション -rw-r----- 1 cyrus mail 16384 Feb 9 00:48 /usr/local/etc/sasldb.db
- define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5')
- AUTHで使用する認証メカニズムの一覧を指定します。 実際には、ここで指定したもののうち実際にSASLライブラリで使用できるものが有効となります。 デフォルトでDIGEST-MD5とCRAM-MD5は含まれているので、LOGINやPLAINを使わないのであれば特に指定する必要はありません。
- TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5')
- リレーを許可する認証メカニズムを指定します。 この例では、DIGEST-MD5かCRAM-MD5で認証されればリレーを許可します。 LOGINやPLAINによる認証でも許可したい場合は、それらも含めます。
3.4 動作確認
さぁ、ではsendmailがちゃんとSMTP AUTH対応になっているか試してみましょう。 SMTP AUTHに対応していれば、EHLOコマンドに対して、使用できる認証メカニズムの一覧を返します。(図7)これで、SMTP AUTHで認証されればリレーが許可されるようになります。
図7 EHLOに対する応答
では、実際にメイルを出してみます。Mewの開発版である1.95では、
(setq mew-smtp-auth t)と設定すると、SMTP AUTHを喋るようになります。 SMTP AUTHで認証するユーザ名がローカルのログイン名と異なる場合は、
(setq mew-smtp-user "ユーザ名")で設定します。 また、認証に使用したい認証メカニズムをmew-smtp-auth-listで設定できるようになっています。
図8はMewでメイルを出し、SMTP AUTHのパスワードを入力しているところです。
図8 MewでSMTP AUTHを使う 
3.3 Received:ヘッダへの記録
SMTP AUTHで認証された場合、Received:ヘッダに(authenticated)が付加されます。 しかし、これだとどのように認証されたのかわかりません。 デバッグなどでもう少し詳しい情報が欲しいかもしれないでしょう。define(`_REC_AUTH_', `_REC_FULL_AUTH_')を加えると、どの認証メカニズムを使って誰が認証されたのか記録されるようになります。 図9の例はSMTP AUTHを使用した場合のReceived:ヘッダです。 CRAM-MD5を使用して認証されていることがお分かりだと思います。
ただし、_REC_AUTH_はドキュメントに書かれていない内部変数なので、将来的に使えるかどうかはわかりません。きちんと公開仕様に従うなら、confRECEIVED_HEADERを使うべきでしょう。(リスト7)
図9 認証時のReceived:ヘッダ
リスト7 confRECEIVED_HEADERを使用した設定例 define(`confRECEIVED_HEADER', `$?sfrom $s $.$?_($?s$|from $.$_) $.$?{auth_type}(authenticated$?{auth_ssf} (${auth_ssf} bits)$.) $.by $j ($v/$Z)$?r with $r$.$?{daemon_family}/${daemon_family}$. id $i$?{tls_version} (using ${tls_version} with cipher ${cipher} (${cipher_bits} bits) verified ${verify})$.$?u for $u; $|; $.$b$?g (envelope-from $g)$.')
3.4 SMTP AUTH導入時の注意事項
近頃はSMTP AUTHを使えるメイラは徐々に増えて来ているようですが、まだまだ少ないのが現状でしょう。 メジャーであるNetscapeやOutlook Expressも一応サポートしていますが、生パスワードを使うPLAINまたはLOGINのみです。PLAINまたはLOGINを有効にする場合、STARTTLSを併用し暗号路を確保することも検討した方が良いでしょう。*9)
さらに、NetscapeなどいくつかのメイラはSMTPサーバがEHLOに250-AUTH LOGIN PLAINと答えると、無条件にSMTP AUTHを使用します。 認証にsasldbのみを使用するようにサーバ側を設定する場合、あらかじめ全てのユーザをsasldb側に登録しておかないと、そのようなメイラでは認証に失敗しメイルが出せないということになります。 このため、PLAINやLOGINを有効にすると、段階的移行が難しくなります。
auto_transitionというPLAIN認証されれば自動的にsasldbに反映するオプションもあります。 しかし、アプリケーションがsasldbに書き込めるようにしないといけませんし、一旦反映されたあとユーザがパスワードを変更してもsasldb側はそのままですので、ユーザが混乱するかもしれません。
また、セキュアな認証メカニズムを使用する場合、認証には基本的にはsaslsbを使うことになります。 つまり、POPなどメイル受信に使用するパスワードと連係しておらず、サーバ側では受信用パスワードと送信用パスワードを別々に管理することになります。 しかし、受信用パスワードと送信用パスワードを別々に扱えないメイラも存在します。
Cyrus IMAPサーバ*10)を導入すると、SASL認証を用いてIMAP4およびPOPをサービスできますので、パスワードの二重管理の問題からは開放されます。 しかし、POP AUTH*11)に対応しているメイラは現状でほとんどないと思われますし、Cyrus IMAPサーバはAPOPをサポートしていませんので、POP中心の環境では生パスワードを使わざるを得ないため、非常に悩ましいです。*12)
加えて、パスワードの変更はsaslpasswdコマンドで行うわけですが、管理者のみしか実行できないというのは実際の運用において非常に大きな制約になります。 ユーザレベルでパスワードの変更が行える管理ツールの登場が望まれます。
4 IPv6とsendmail
sendmail 8.10.X以降では標準でIPv6をサポートしています。 ただし、-DNETINET6を付けてコンパイルする必要があります。 FreeBSD添付のsendmailは-DNETINET6付で作られており、IPv6が使用できる環境であれば、何も考えなくてもIPv6を使ってメイルを出すことができます。 しかし、そのままではIPv6でメイルを受けることはできません。 sendmail.cfでIPv4のみlistenするようになっているためです。DAEMON_OPTIONS(`Name=MTA-v4, Family=inet')と書いてあげると、どちらもlistenするようになります。 ちなみに、なぜデフォルトでそうしてないかというと、IPv4のみのkernelだとsendmailが動かなくなるためです。
DAEMON_OPTIONS(`Name=MTA-v6, Family=inet6')
Received:ヘッダにIPv4かIPv6かどちらで受け取ったか記録したければ、
define(`_REC_BY_', `$.by $j ($v/$Z)$?r with $r$.$?{daemon_family}/${daemon_family}$. id $i$?{tls_version}')と書いておきましょう。 ただし_REC_BY_は_REC_AUTH_と同様にドキュメント化されていませんので注意して下さい。
5 おわりに
sendmail.cfの作り方をFreeBSD流に説明し、sendmailに最近追加された機能であるSMTP AUTHとIPv6サポートについて簡単ながら解説しました。 CFからcfへの移行に少しでもお役に立てれば幸いです。 そして、SMTP AUTHが普及しSPAMが少しでもなくなることを期待しつつ筆を置きます。参考文献
参考文献として、以下の2冊をあげておきます。 sendmail 8.8.Xの頃のものですので、内容的に若干古くなっておりますが、動作原理・設定方法などは基本的に変わっていませんので、非常に役に立つこと思います。 cf/READMEと併せて参照すると良いでしょう。- 「sendmail システム管理」
- Bryan Costales, Eric Allman 共著
- 中村素典 監訳, 鈴木克彦 訳
- オライリージャパン 発行
- ISBN4-900900-40-0
- 中村素典 監訳, 鈴木克彦 訳
- 「sendmail リファレンス」
- Bryan Costales, Eric Allman 共著
- 中村素典 監訳, 鈴木克彦 訳
- オライリージャパン 発行
- ISBN4-900900-41-9
- 中村素典 監訳, 鈴木克彦 訳