電子メールサーバのソリューションでご存じの方、是非ご教示下さい。

現在DMZ上で運用中のメールサーバ(SV1とします)があり、SMTPおよびPOP3サーバの機能を有しています。
※SV1のSMTPはPOPbeforeSMTPで認証しており、またLAN側といわゆるSMTPサーバ同士のリレーはできません。
IMAP4運用を行いたいため、別途LAN内にメールサーバ(SV2)を設置して
・定期的にSV2からSV1へPOP3アクセスしてSV2の該当メールディレクトリへ格納する。
・SV2へ依頼された電子メールをSV1へ、あたかもMUAがSV1へ直接アクセスしたかのように転送する。(つまりPOPbeforeSMTPアクセスをする)
といった動作をするソリューション(1つのソフトあるいは組み合わせ)を探しています。
セキュリティーポリシー上、メールはSV1に必ず経由させます。
Windows運用でもLinux運用でもかまいません。ご教示頂けますでしょうか?

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2007/05/12 22:20:41
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:JULY No.3

回答回数966ベストアンサー獲得回数247

ポイント30pt

@IT:TCP/IPアレルギー撲滅ドリル【超実践編】(3)

実はSMTPサーバのいわゆるリレー動作時とMUAがSMTPサーバへ依頼するときとで、プロトコル手順(シーケンスやコマンドなど)の違いがあるのかないのかわからずにいます。

基本的に違いはありません。というか、違いがなかったから spam の問題が出てきた、とも言えます。

大昔は、同じコンピュータにアカウントを持つ別の人にメールを送る、というとこからスタートしていて、この時は SMTP というプロトコルすら必要ありませんでした。つまり、MUA に当たるプログラムが SMTP を話すこともなく、そのコンピュータ上で閉じたメールシステムにメールの送信をお願いするような仕組みでした。

それがやがて、インターネットを介して他のコンピュータへメールを送信できる仕組みができたわけですが、この時も、当初は MUA 自体が TCP/IP で通信するのではなく、MUA は同じコンピュータ上で動いているメールシステムにお願いする形式でした。

SMTP というプロトコルは、上記のようなメールシステムの前提にしていたために、あくまでも「システム間の通信プロトコル」という位置づけで作られました。

やがて PC がインターネットにつながるようになると、そもそも PC 上でメールシステムが動作していることは無かったので、MUA が直接 SMTP を使って送信するようになりました。

元々「システム間の通信プロトコル」だった SMTP を、エンドユーザが利用する MUA が使うようになったことにより、SMTP の「ユーザを認証しない」という仕様が問題になってきて、そこで、POP before SMTP という仕組みや、SMTP AUTH といった拡張がされてきた、というのが歴史的な流れです。

spam が大きな問題になってきたことから、Outbound Port 25 Blocking と、Submission プロトコル(プロトコルの中身は認証必須とした SMTP)というのが、この1年ぐらいの間で ISP 側の対応が取られてきましたが、現在でも「自 ISP が保有している IP アドレスからの SMTP 接続」に関しては、MTA 間と同じ認証なしの SMTP が使われています。

id:HISI

大変わかりやすい説明有難う御座います。

納得です。

2007/05/12 22:19:33

その他の回答2件)

id:JULY No.1

回答回数966ベストアンサー獲得回数247

ポイント30pt

FetchMailの導入

私の自宅サーバで似たようなことをしているのですが、プロバイダのメールサーバから fetchmail と cron を使って定期的にメールを POP で受信し、自宅サーバで構築した IMAP のメールサーバに入るようにしています。

送信側の方ですが、SV1 の POP before SMTP でタイムアウトする時間より短い間隔で SV2 が定期的にメールを取りに行けば、MUA → SV2 → SV1 とするのは問題ないと思います。

送信側、受信側とも多くの Linux ディストリビューションで標準的に提供されているソフトで構築できます。それぞれのソフトの設定は、たとえば IMAP のサーバに何を使うのか、とか、MTA のソフトは Postfix なのか sendmail なのか、といったところで違ってくるので、具体的な細かい設定までは紹介できませんが、Linux で普通にできると思います。

id:HISI

有難う御座います。

実際に運用されているところが心強いです。

centosでfetchmail,postfix,dovecotを使って組んでみようと思います。

2007/05/10 22:58:21
id:nyamap No.2

回答回数22ベストアンサー獲得回数0

ポイント30pt

設定がややこしいですがLinuxでfetchmailを使うとお望みにかなり近いことが出来ると思います。

SV2->SV1への定期転送は普通に出来ますが、SV2からSV1への転送を行うのに設定がややこしそうです。

id:HISI

有難う御座います。

実はSMTPサーバのいわゆるリレー動作時とMUAがSMTPサーバへ依頼するときとで、プロトコル手順(シーケンスやコマンドなど)の違いがあるのかないのかわからずにいます。

もしご存じであればそのあたりを教えて頂けると大変助かります。

2007/05/10 22:58:24
id:JULY No.3

回答回数966ベストアンサー獲得回数247ここでベストアンサー

ポイント30pt

@IT:TCP/IPアレルギー撲滅ドリル【超実践編】(3)

実はSMTPサーバのいわゆるリレー動作時とMUAがSMTPサーバへ依頼するときとで、プロトコル手順(シーケンスやコマンドなど)の違いがあるのかないのかわからずにいます。

基本的に違いはありません。というか、違いがなかったから spam の問題が出てきた、とも言えます。

大昔は、同じコンピュータにアカウントを持つ別の人にメールを送る、というとこからスタートしていて、この時は SMTP というプロトコルすら必要ありませんでした。つまり、MUA に当たるプログラムが SMTP を話すこともなく、そのコンピュータ上で閉じたメールシステムにメールの送信をお願いするような仕組みでした。

それがやがて、インターネットを介して他のコンピュータへメールを送信できる仕組みができたわけですが、この時も、当初は MUA 自体が TCP/IP で通信するのではなく、MUA は同じコンピュータ上で動いているメールシステムにお願いする形式でした。

SMTP というプロトコルは、上記のようなメールシステムの前提にしていたために、あくまでも「システム間の通信プロトコル」という位置づけで作られました。

やがて PC がインターネットにつながるようになると、そもそも PC 上でメールシステムが動作していることは無かったので、MUA が直接 SMTP を使って送信するようになりました。

元々「システム間の通信プロトコル」だった SMTP を、エンドユーザが利用する MUA が使うようになったことにより、SMTP の「ユーザを認証しない」という仕様が問題になってきて、そこで、POP before SMTP という仕組みや、SMTP AUTH といった拡張がされてきた、というのが歴史的な流れです。

spam が大きな問題になってきたことから、Outbound Port 25 Blocking と、Submission プロトコル(プロトコルの中身は認証必須とした SMTP)というのが、この1年ぐらいの間で ISP 側の対応が取られてきましたが、現在でも「自 ISP が保有している IP アドレスからの SMTP 接続」に関しては、MTA 間と同じ認証なしの SMTP が使われています。

id:HISI

大変わかりやすい説明有難う御座います。

納得です。

2007/05/12 22:19:33

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません