メールサーバと設定について

メール送受信の基本的なポリシー

電子メールは、本学の使命である研究教育及びそれら支援業務だけではなく、本学構成員の日々の生活に必須のインターネットアプリケーションの最重要なものの一つです。しかしながら、電子メールは、ウイルスメール等の情報インフラに害をおよぼすものや、スパムメールのようにユーザの時間を無駄に使わせるもの等の温床にもなっています。特にウイルスメールは本学が被害者になるだけではなく、加害者にもなりうるもので、注意しなければなりません。

また、メールサーバの設定は、設定に失敗するとスパムメールの配信に利用されたり、SMTPを通して攻撃を受けたりします。これらの設定ミスを防ぐためには学内の管理者のスキルを向上するしかありませんが、ケアレスミスを防ぐことは非常に困難です。

そこで情報基盤センターは、学外と学内の対外接続部に全学メールゲートウェイを設置し、ウイルスメールチェックとスパムメールチェックを行なっています。この全学メールゲートウェイを経由せずに学外から学内、学内から学外へのメール配送は行なえません。また、学内から学内へのメール配送に関しても全学メールゲートウェイを経由することを強く推奨します。

メールを正しくかつ安全に配送するためには、本ドキュメントに従ってメールサーバとDNSサーバを設定しなければなりません。これら以外の設定を行なっている場合は、全学メールゲートウェイでのメール配送を保証できませんのでご注意下さい。

全学メールゲートウェイを介するメール配送

全学メールゲートウェイを設置したときのメール配送のモデル図は以下のようになります。


  学外サーバ -------+   +-----------+--- 学内サーバA -- クライアントA
                    |   |           |
         全学メールゲートウェイ     +--- 学内サーバB -- クライアントB

このとき、学内サーバのメール配送の設定は、自分自身を宛先としているメール以外は全て全学メールゲートウェイに転送する、としておきます。

学外から学内へ届けられるメールは、まず最初に全学メールゲートウェイに転送されます。全学メールゲートウェイはメールの検疫を行ない、安全になったメールを学内サーバに再配送します。

学内から学外へ届けられるメールは、クライアント - 学内サーバ - 全学メールゲートウェイ - 学外サーバの順に転送されます。このときウイルスに感染したクライアントを用いていたとしても、全学メールゲートウェイでブロックされますので学外へウイルスメールが送られることはありません。

学内から学内へのメールは、クライアントA - 学内サーバA - 全学メールゲートウェイ - 学内サーバB - クライアントBの順に転送されます。全学メールゲートウェイを通りますので、ウイルスの検疫が行なわれ安全なメールが配送されます。

MTAの設定不良によって起こるスパムリレーについては、スパム発信者は全学メールゲートウェイにしか接続できません。全学メールゲートウェイでは学外から学外へのメールの転送を許可していませんので、スパムリレーを行なうことはできません。これでスパムリレーは撲滅できます。

全学メールゲートウェイに関する情報

全学メールゲートウェイは以下の３台です。

mx-east.uec.ac.jp
mx-west.uec.ac.jp
mx-delivery.uec.ac.jp

ただし、設定ファイル等で全学メールゲートウェイのFQDNを指定するときは

mx.uec.ac.jp

と書いてください。学外からはmx-east.uec.ac.jp, mx-west.uec.ac.jpが検索され、学内からはmx-delivery.uec.ac.jpが検索されます。

全学メールゲートウェイ上で動作しているのは以下のソフトウェアです。

全学メールゲートウェイの２台以外のホストからは学外から学内、学内から学外のSMTP接続はできません。対外接続ルータでTCP/25（SMTP）をフィルタリングしています。

全学メールゲートウェイでは、本学からのスパムメールの大量配信を防止するため、メールの送信時の宛先数に対して制限を掛けております。通常の利用では問題は起こりませんが、あらかじめご注意下さい。

MTAとDNSサーバの設定について

MTAの設定は主に正しく送信するために、DNSサーバの設定は主に正しく受信するために必要です。必ず確認してください。

MTAとしてpostfixを用いている場合

main.cfのrelayhostを


relayhost = mx.uec.ac.jp

とします。その後、postfixを停止して再起動するか、postfix reloadで設定ファイルの再読み込みを行なって下さい。正しい設定がされているかログを確認して下さい。

MTAとしてsendmailを用いている場合

sendmailの設定ファイルであるsendmail.cfは生成ツールのCFやcfで生成することが一般的です。その場合の設定法を説明します。

CFの場合は、defファイルに


DIRECT_DELIVER_DOMAINS=none

DEFAULT_RELAY='smtp:mx.uec.ac.jp'

の二行を加え、cfファイルを生成し直します。

cfの場合は、mcファイルに


define(`SMART_HOST',`mx.uec.ac.jp')dnl

の一行を加え、cfファイルを生成し直します。

あとは、規定のディレクトリ(/etc または /etc/mail)にsendmail.cfをコピーしてsendmailを再起動してください。その後、送信メールがmx-deliveryに転送されていることをログで確認して下さい。

MTAとしてqmailを用いている場合

control/smtproutesを


:mx.uec.ac.jp

として下さい。空行は入れてはいけません。

control/smtproutesを利用するのはqmail-remoteで、このプログラムはqmail-rspawnが配送されるメール毎に起動します。qmailを再起動する必要はありません。正しい設定がされているかログを確認して下さい。

DNSサーバの設定

BIND9あるいは複数台のDNSサーバを用いて、学内からDNSクエリを行なった場合と、学外からDNSクエリを行なった場合とで異なる返答を行なえるようにするDNSサーバ運用のテクニックをゾーンスプリティングと呼びます。正しいメールの送受信のためには、このゾーンスプリティングによる運用が必須です。

この場合、学外から見える正引きゾーンに対しては（example.uec.ac.jpドメインを仮定します）


host    IN A            130.153.X.X
        IN MX 10        mx.uec.ac.jp.

と記述し、学内から見える正引きゾーンに対しては


host    IN A            130.153.X.X
        IN MX 10        hostA.example.uec.ac.jp.

と記述します。このDNSサーバを用いると学外から学内へメールが配送される場合は、

学外のMTAはhostA.example.uec.ac.jpの学外から見える正引きゾーンMXレコードを検索し、mx.uec.ac.jpにメールを配送する。つまりは全学メールゲートウェイの２台のどちらかかがメールを受信する。
全学メールゲートウェイは学内から見える正引きゾーンのMXレコードを検索し、hostA.example.uec.ac.jpへメールを再配送する。
結果としてhostA.example.uec.ac.jpがメールを受信する。

の手順でメールが配送されます。

全学メールゲートウェイをバックアップMXとして利用するような設定を行なった場合、正常なメール配送を保証できません。qmailをバックアップMXとして動作させるためにはプライマリMX一台に対して一つの静的ルーティングの設定が必要ですが、情報基盤センターでは個別の静的ルーティングの設定は致しません。バックアップMXとして設定しないとしても、プライマリMXが落ちている場合は全学メールゲートウェイでプライマリMX宛のメールは７日間は保持されます。ご注意下さい。

FAQ

Q1. 普通のメールを間違えてウイルスメールとして処理してしまうことはありませんか？
A1. その可能性は全てのウイルスチェッカーソフトに対して存在しています。しかしながら、センターが調べた限り、そのような問題がクローズアップされたことはないか、あってもそれほど大きな問題にならなかったのではと考えます。
もし届くべきメールが届いていないことが判明しましたら、FAQに沿ってセンターまでご連絡下さい。
Q2. これはメールの検閲ではないでしょうか？
A2. 違います。メールゲートウェイを通過するメールの保存は行ないませんし、特定のメールに関して保存したり文書を走査したりすることも行ないません。あくまでウイルスチェッカーに搭載されている機能を用いてウイルスチェックとスパムのチェックを行なうだけです。
Q3. ウイルスチェッカー付ゲートウェイがあるから、電子メールに関する各々のセキュリティ対策はやらなくてもよいか？
A3. それぞれのPCやメールサーバのセキュリティ対策は今まで通りに行なってください。防御は縦深に何段階も用意しておくというのがセキュリティ対策の基本だからです。
特に、本学ネットワーク以外のネットワークに接続するノートPC等には今まで通りの対策が必要です。
Q4. 研究や実験でSMTPを使いたい場合、研究用途でウイルスメールやセキュリティホールのPoCを受信したいときはどうすればよいでしょうか?
A4. 実験用ネットワークをご利用下さい。
Q5. 学内のメールサーバでメーリングリストの運営は可能ですか？
A5. 可能です。変更すべき点はありません。なお、センターでは@uec.ac.jpによるメーリングリストサービスを行っています。ご利用下さい。
Q6. 学外から学内のメールサーバのメールは読めなくなりますか？
A6. 学外のネットワークに接続されたメイラーからPOP3を用いて学内のメールサーバにアクセスすることは従来通り可能です（ただし、POP3やAPOPの利用は推奨していません。VPNを通した利用に限定して下さい）。
Q7. 学外から学内のメールサーバを経由してメールを送信できますか？
A7. 学外のネットワークに接続されたメイラーから、TCP 25番ポート(SMTP)による学内のメールサーバからのメールの送信は、全学メールゲートウェイ mx-east.uec.ac.jp, mx-west.uec.ac.jp の２台以外からはできません。
TCP 587番ポート(Submission)には制限を掛けていませんので、メールサーバにSubmissionの設定が正しくされていれば利用可能です。あるいはVPNを通して利用して下さい。
Q8. 学外からPOP3 over SSL(POP3s), IMAP over SSL(IMAPs), SMTP認証・SMTP over SSL(Submission)の利用はできますか？
A8. 情報基盤センターのIMAPサーバ imap.cc.uec.ac.jp は、UECアカウントによる認証を用いて学外からPOP3s, IMAPs, Submissionが利用できます。なお、全学メールゲートウェイ mx-delivery.uec.ac.jp は、UECアカウントによる認証を用いて学外からSubmissionが利用できます。
また、情報基盤センターが提供するバーチャルドメインサーバはPOP3s, Submissionによる学外からのメールの利用が可能です。
Q9. IPv6のメール送受信はどうなりますか？
A9. IPv6のSMTP接続はフィルタリングによりできません。メールの送受信はIPv4を利用してください。
Q10. uec.ac.jpドメイン以外のドメインのメールサーバを学内で運用することは可能ですか？
A10. 可能です。全学メールゲートウェイの設定ファイルに学外から学内に中継を許容する宛先ドメインを全て列挙する必要があるので、support@cc.uec.ac.jpまでご連絡下さい。2014年11月の現在、学内でメールを送受信するuec.ac.jpドメイン以外のドメインの運用があり、正常に動作しています。
そのメールサーバの設定とDNSサーバの設定は、学内で動作するメールサーバと同様にする必要があります。