このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

リレーの考え方

発言者:重松修
( Date Sunday, June 24, 2001 11:11:18 )


非常に初歩的な質問なんだろうとは思うんですが、
メールのリレーというものの概念がよくわかりません。

今まで EIMS 1.x を使っていたのですが、そのメールアカウントで、
他のメールサーバに送信はできます。それで、リレーはしない、
という設定のようです。

しかし、よく考えなくても、SMTP って認証がないので、
そのアカウントのふりをして第三者が大量にメールを送るという
行為を許すような穴がある気がしています。

qmail にしたところ、自分のネットワークのみリレーを許可したところ、
送信で拒否されるようになってしまいました。

inet 経由で使用をしているのですが、hosts.allow の
tcp-env :       127. 192.168.1. : setenv = RELAYCLIENT
に外部ネットワークのアドレスを書けば、
送信はできるのですが、これって、ORBS だとかに
リストアップされちゃうんでしょうか?

たとえ、POP before SMTP を導入したところで、
やってることは、IP で制限する代わりに、パスワード認証をして、
それでリレーを自分以外のネットワークから認めることに
代わりはないので、リレーはリレーだと思うのですが。

大西 恒樹 さんからのコメント
( Sunday, June 24, 2001 13:08:08 )

自分(そのメールサーバー)宛以外のメールを受け取ることが、
全てリレーです。

リレーを行わないと、ローカル配送しかできませんので、どこへも
メールは送れません。したがって、ほとんど全てのメールサーバーは
リレーを行います。違いはOpenRelayか、RestrictedRelayか、だけの
ことです。

qmailではqmail-smtpdというデーモンがリレーの受け取りを処理します
ので、これを相手ホストのIPアドレスを限定して起動します。

私が運用するqmailサーバーはtcpserverを使ってこれを起動していますが、
まあ、inetdでも基本的には同じ原理で、ここにリレーを許可するホストの
IPアドレスをリストすればよいでしょう。

重松修 さんからのコメント
( Monday, June 25, 2001 12:43:18 )

大西さん、コメントありがとうございます。
なるほど、いわれてみれば、リレーしないとメールが外に送れませんね。
inetd はパフォーマンスに問題があるようですが、
そのうちに、tcpserver に切替えたいと思います。
とりあえず、不特定多数が使う訳ではないので、POP before SMTP ではなく、
hosts.allow の設定でリレーするクライアントを限定し、
運用しようと思います。

p さんからのコメント
( Monday, June 25, 2001 13:52:02 )

SMTPリレーが行われない場合

  ローカル to ローカル  OK
  外部   to ローカル  OK
  ローカル to 外部    NG
  外部   to 外部    NG

#サーバとクライアントが同一構内で物理的に
LANで接続されていても、クライアントが
ローカルであることをサーバに認識されない場合もあります。
この場合、クライアントからどこにも発信できない
ことでしょう。
余談ですが
不正な中継を許さない設定をしたらクライアントから
外部への発信が出来なくなるという不具合な症状の多くは
クライアントがローカルでないよと、思われているわけです。



SMTPリレーを、全部許す場合

  ローカル to ローカル  OK
  外部   to ローカル  OK
  ローカル to 外部    OK
  外部   to 外部    OK

#この第4番目が、踏み台となりうるわけですね。
昔はこれでOKだったわけです。



SMTPリレーを、適切な条件によっては許す場合

  ローカル to ローカル  OK
  外部   to ローカル  OK
  ローカル to 外部    OK
  外部   to 外部    NG

#このようにすれば、不正な中継を禁止してありますし
ローカルなクライアントからはどこにでも送信OK
外部からのメールは、サーバのローカルなユーザにのみ
OKとなります。ローカルなクライアントは
POPすればメールを引き取れます。
(POPの認証は、POPアカウントと付随するパスワードのみ
ですので、原則的には、ローカルでない場所からでもOKに
なるサーバが多いですね)

#さて、どんな条件をもって「ローカル」であると認識させるのか?
いくつかの条件を複合的に設定して、その組み合わせで判定すること
が多いのです。

#とっても脇の甘い例では、
サーバ登録済みのメールアカウントで、ありさえすればOKというのも
あります。これは、穴ですね。メールアカウントは外部に公開する
のが原則ですから。SMTPはパスワードチェックしないのが
おおもとの考えですから、事実上、悪用を防げません。

#たとえば、おお甘なサーバ運用ならば
ローカルな条件として
「POP before SMTP」のみ採用することでしょう。
複合技を使わないわけですね。
SMTPをクライアントが利用する場合に、そのクライアントが
あらかじめサーバに登録済みのPOPアカウントを利用していること
そして、そのパスワードがOKであること、これを先にチェックする
仕様ですね。SMTPの前にPOPを強制的に促して、POPOK
ならばその後10分間だけはSMTPを許してあげよう、、となります。

#上記までの条件の例では、アカウント、ないし、そのパスワードで
判定しようとするものでした。
別な条件を組み合わせる手があります。
IPアドレスによる制限です。
代表的なものが、サーバと同じIPアドレスのセグメントならば
「ローカル」であると認証しようとするものです。

#構成上、上のチェックができないのであるのらば
特定のIPアドレスのみ「ローカル」であると
認めさせるのもひとつの考え方です。
サーバがグローバルなIPを持っていて、
クライアントがプライベートなIPを持っているとき
などはこの考え方が、よろしいでしょう。
ルータの設定によって、Internetの世界からの
アクセスで、プライベートなアドレスできたものは
当然、遮断となっているのが原則です。

#応用ですが、
構内にサーバがあり、LANでクライアントが
直結されていて、そのクライアントのIPならば
SMTPリレーを許す設定に、条件を
ORでプラスアルファすることがあります。
構内が本社で、外部の別な場所の出先のIPアドレスが
グローバルな意味で、固定であるときなどがわかりやすい
ですね。構内LANのプライベートアドレスと
出先のグローバルアドレスからのみ、SMTPリレーを
許します。ただし、メールアカウントは、サーバに
登録済みであるとします。(アカウントは詐称されるので
あまり当てにできませんが、ないよりマシです)

#別な応用ですが、サーバがホスティングされて構内に
無い場合を考えます。
構内は、インターネット上のサーバに対して
どのように、「ローカル」だよ、と身を立てればいいでしょう?
ADSLで接続を許す一部のISPは、グローバルなIPアドレス
を付与してくれますので、そのIPであるならばOKとしても
よろしいでしょう。グローバルなIPアドレスしかくれない
ISPならば(NTTさんとか)
サーバが、POP before SMTP か
もしくは、はるかに優れている SMTP AUTH 認証を
かましてくれることに期待するのがいいでしょう。
これしかできないというのもさびしいことですが
IPアドレスは払底する一方ですので、固定アドレスの払出を
受けることはむつかしいのかもしれません。

#構内のサーバを、一部の外部の利用者にPPP接続などで
接続を許したい場合に、PPP接続の電話番号を知っている
という事実だけで、SMTPを許すという例があるようです。




>しかし、よく考えなくても、SMTP って認証がないので、
そのアカウントのふりをして第三者が大量にメールを送るという
行為を許すような穴がある気がしています。

おっしゃられる通りです。
SMTP認証の機能があるものが望ましいですね。
POP before SMTP ではちょっとさびしいです。

>qmail にしたところ、自分のネットワークのみリレーを許可したところ、
送信で拒否されるようになってしまいました。

お使いのメールクライントは、本当に、許可されたネットワーク上に
あると、qmailに認識されているのでしょうか?