システム奮闘記：その32

Postfixでメールサーバー構築

はじめに

　2000年、メールサーバーを構築した時、sendmailを使った。
　でも、Postfixに移行する事になったので、その話を書く琴似しました。

Postfixに移行への経緯

  ウイルスメール。
　うちの会社にも、結構、流れてくるようになった。
  上層部から・・・

　ウイルス対策を立てるように!

　と言われる。だが、費用をかけないようにという条件だった。

　頭を抱えたのだが、そんな時、救いの手が伸びた。
  それは、2004年のSoftwareDesign4月号だった。

  「spamもウィルスもぶっとばせ！ Postfixで作るパーフェクトメールシステム」

　この雑誌なのだが、うちの会社ではsendmailを導入していたので
関係なさそうなのだが、なぜか衝動買いをしていた私。

　自腹だったので・・・

  どうせ読めへんのに、買ってもうた (TT)

  と後悔したのだった。

  しかし、しばらくして、うちもPostfixに乗り換えようかと思った。
  それは、以前から、色々な人が

　Postfixは使いやすい!

　という話や

　sendmailはわからない!

　という話を聞いてた。
　なので、わかりやすい方へ乗り換えた方が賢いかなぁと思った。


  sendmailからPostfixへの乗り換え作業にとりかかる事になった。
  そこで、やらねばいけない壁に打ち当る！

  ついに、メールというパンドラの箱を開けるのか (^^;;

  今まで、sendmailをメールサーバーソフトとして使ってきたのだが、
正直に書きますと、設定に関しては全て

  本の丸写しです！！

  だった (^^;;

  メールの配信の仕組みなどを全く知らないため、
もし、何か障害が発生しても、何が原因か調べられない。
  もちろん、Postfixに切り替え時に、本の丸写しでドツボにハマっても、
抜けられない危険が潜んでいる。
  そこで、ボロ出し大作戦の一環として、開けていなかったパンドラの箱を
開ける事にした。

  ちなみに、ウイルスに関する話は、別の機会に取り上げます (^^)

sendmailについて

  sendmailの設定といえば、sendmail.cfという設定ファイルを
作成する必要がある。

  しかし、その中身を見ると、解読不可能な記号や暗号のような固まりだ。
  オライリ─から「sendmail 第3版 VOLUME 1」と「sendmail 第3版 VOLUME 2」
という本が出ているのだが、

  2冊とも、私の三段腹より分厚い！

  自分の三段腹よりも分厚い本なんぞ、読む気が起こらなくなる。
  そのため、設定を行なう時は、本の丸写しになってしまう (--;;

  2000年、サーバーを構築した当時は、CF-3.7Wpl2というツールを使った。
  そのツールで、sendmail.defファイルを編集を行い、make sendmail.cfで、
設定ファイルが作成される。

  2003年、sendmail.cfの設定を行なった時、sendmail.mcファイルを作成して
m4コマンドを使って、sendmail.cfを生成した。

  sendmail.cfは、呪文そのものなので、直に、そのファイルを触るのには
私の三段腹よりも分厚い本を読破するような凄い人でないと無理だ。

  そのため、編集しやすい、sendmail.mcファイルを編集した後で、
sendmail.cfに書き換えてくれるツールがある。

  だが、それも敷居が高い！

  下手な設定をして、スパムメールにやられては元も子もない。
  スパムにやられた話については、「システム奮闘記：その8」
(セキュリティー、てんやわんや)をご覧ください。


  しかし、Postfixの本を見ると、設定方法がわかりやすい。
  しかも、添付ファイルの拡張子を見て、「pif」や「scr」といった
まさにウイルスメールを破棄してくれる機能があるので、
Postfixに乗り換える事を考えた。

Postfixの設定方法

  さて、水先案内人として次の本を使った。
  「Postfixで作る実践メールサーバー」（秀和システム：Postfix研究会）

  切り替え作業。これに失敗すると、メールサーバーが停止しかねない。
  特に、ドツボにハマると、ニッチモサッチもいかなくなり、
わけがわからなくなり、非常手段の「OSの再インストール」になりかねない。
  そのため、失敗は許されない。

  そこで、実験サーバーで予行演習をする事にした。

  大変な作業になるかなぁと思いきや、SoftwareDesignには、
RedHat7.3以降の場合、意外と簡単にできると書いていた。

  まずは、2つのファイルをインストールする。

  redhat-switchmail-0.5.1-1.noarch.rpm
  redhat-switchmail-gnome-0.5.1-1.noarch.rpm

  そして肝心のPostfixのRPMファイルをインストールする。
  手元にあったのが、Postfix-1.1.7なので、それをインストールする。

  これで準備は完了。
  sendmailからPostfixへの切り替えは、redhat-switchmailコマンドを打てば
次の画面が出てくる。

redhat-switchmailコマンド
この時、使うメールサーバーソフトを選択して「OK」を押す。

  そして、sendmailデーモンを停止してから、Postfixのデーモンを立ち上げると
切り替えは完了する。

  なんて移行が楽なんだ！

  と思った。

  この時、裏では次のようなファイルの関係が形成される。

sendmailとPostfixとのファイルの関係 （あくまでもRedHatでの話です）

 実際に、自分の目で確かめる事にした。

lrwxrwxrwx    1 root     root           21  6月  5 23:24 sendmail -> /etc/alternatives/mta
-rwxr-xr-x    1 root     root       108103  6月  5 17:19 sendmail.postfix
-r-sr-xr-x    1 root     root       451280  4月  8  2002 sendmail.sendmail 

  本に書いてある通り、リンクが張られている。
  切り替えツールのボタン一つで、リンク先さえ変更すれば、移行が楽にできる。
「なるほどなぁ」と思った。

  さて、本やネット上にある設定の方法を丸写しで、ローカル配信を試みた。
 
  ローカル配信は成功！

  次に、外部とのやりとりの試験を行なう所だが、
なにせ、実験サーバーで行なっている上、ローカルネットワークのため、
外部とのやりとりは、できないだろうと思って、試験は省略した (^^;;

  でも、RedHat7.3のCD-ROMにあるPostfixは、Postfix-1.1.7でバージョンが低い。
  そこで、最新バージョンの、Postfix-2.0.20を入れてみる事にした。

  このバージョンは、RPM形式がないためソースからインストールした。
  インストール自体は、非常に簡単だ。
  展開した後、コンパイルするため、makeを行う。
  そして、make installで、インストール作業を行う。
  インストール作業中は、色々な事を聞いてくるが、
全て初期値での設定で問題はない。

lrwxrwxrwx    1 root     root           21  6月  5 23:24 sendmail -> /etc/alternatives/mta
-rwxr-xr-x    1 root     root       402219  6月  5 17:20 sendmail.postfix
-rwxr-xr-x    1 root     root       108103  6月  5 17:19 sendmail.postfix-org
-r-sr-xr-x    1 root     root       451280  4月  8  2002 sendmail.sendmail 

  何気なく、ファイルの大きさを見ると、Postfix-1.1.7は、100Kバイトなのに
Postfix-2.0.20は400Kバイトになっている。
  バージョンが変わると、本体のファイルのサイズが大きくなるのかと思った。

  この時、ファイルの大きさを何気なく見ていたのだが、実は、この違いを
頭に入れていたお陰で、後で、助かった。
  それについては、後述しています。

  そして、ローカル配信を行なった。

  ローカル配信は成功！

  もちろん、この時も外部とのやりとりのテストはしなかった。

  この時、読者の方で「なるほど、この話の筋が読めた。外部とのやりとりが
できなくなった話だなぁ」と想像されると思いますが

  残念でした。別のトラブルが起こりました

  と書く事にします。どんなトラブルかについては、後述しています (^^)

メールの配信と転送

  さて、移行が楽だとわかった所で、善は急げでPostfixへの移行をしたくなるのだが
肝心のメール配信の仕組みを知らないままだと、全く進歩がない！

  その上、下手な設定をして、攻撃対象になるかもしれないし、
もちろん、障害が起こっても、原因がわからず対処ができない場合も出てくる。

  すぐにでも移行したい気持ちを抑えて、じっくりと腰を据えて、
メール配信の仕組みを調べる事にした。


  さて、メール配信の仕組み。
  相手に、どのようにメールが届いているかなど、興味深い。
  メールに関して、知らない事だらけなので、まずは「@IT」のサイトで
メール配信の仕組みの概略について調べる事にしてみた。
  そこで、2つの重要語句がある事を知る。

  「配信」と「転送」

  この2つの言葉を知らないと、話にならないようだ。もちろん、私は・・・

  事務員なので、わかりませーん (^^)

  だった。
  そこで「配信」と「転送」の違いを見てみると、次の通りだった。

「配信」と「転送」の違い
(1)	メールクライアントからメールサーバーへメールが送られる。
(2)	メールサーバーが宛先を見る。
(3)	宛先が自分の所のローカルユーザーでない場合 該当のメールサーバへメールの転送を行なう
(4)	メールを受け取ったサーバーは、自分の所のユーザーの メールボックスにメールの配信を行なう。
(5)	メールの宛先が自分の所のローカルユーザーなので、 該当のユーザーのメールボックスへメールの配信を行なう。
「配信」とは、自分の所のローカルユーザーのメールボックスへ メールを送る事を言う。 「転送」とは、送信先が自分の所のローカルユーザーでない場合、 他のメールサーバーへメールを送る必要がある。他のメールサーバーへ メールサーバーへメールを送る事を「転送」と言う。

  意外と早く、2つの違いを飲み込めた。


  メールの関して調べていると、telnetコマンドを使ってメール送信の話があった。
  すなわち、メールコマンドの使い方の説明だった。

  今まで、telnet XXX.YYY.ZZZ.RRR  smtpを使って、メールコマンドを使う話は知っていた。
 （XXX.YYY.ZZZ.RRRは、メールサーバーのIP）
  しかし、具体的に、どう使うのはまでは知らなかった。
  そこで、今回、どんな使い方をしているのか、自分の目で確かめる事にした。

[suga@server]# telnet XXX.YYY.ZZZ.RRR smtp
Trying XXX.YYY.ZZZ.RRR...
Connected to XXX.YYY.ZZZ.RRR.
Escape character is '^]'.
220 kkkkk.xxxxx.co.jp ESMTP Postfix
HELO qqqqq.xxxxx.co.jp
250 kkkkk.xxxxx.co.jp
MAIL FROM:aaaaa@xxxxx.co.jp 
250 Ok
RCPT TO:suga@xxxxx.co.jp
250 Ok
DATA
354 End data with .
I write mail using "telnet"   
.
250 Ok: queued as A3E17FA84
QUIT   
221 Bye
Connection closed by foreign host.

青い部分は、メールコマンド。
HELO （クライアントのホスト or ドメイン名）の挨拶を行う。
MAIL FROM：（送信元のメールアドレス）を伝える。
RCPT TO：（送信先のメールアドレス）を伝える。
そして、内容を送るという合図でDATAコマンドを送る。

さて、赤い部分はメールの内容だ。この内容を書き込んで、最後にピリオドをつける。

送信作業が終了すれば、QUITコマンドで終了させる。

  なんだか、会話のやりとりだなぁと思った。
  実際に、それでメールが送れているのか、確認してみた所、問題なく送れていた。
  上での一連の流れを図にしてみると、次のようになる。

メール送信の一連の流れ

  普段、OutlookExpressを使って、メールを送信しているが、
裏で、こんな会話が行なわれているとは、考えもしなかった。

  さて、この時、重大な事に気づかなかったのだが、SMTPにアクセスする時

  ユーザー認証を行なっていない！

  だった (^^;;
  なぜ、ユーザー認証を行なっていないのが問題なのかは、後述しています。
  あと、SMTPへの挨拶は、HELOでなく、EHLOコマンドではないかという
突っ込みに対しても後述しています。

popを使ってメールの受信

  さて、次に気になるのは、メールの受信だ。
  もちろん、telnetを使って、メールサーバーへアクセスできる。
  telnet XXX.YYY.ZZZ.RRR pop3コマンドを使えば、POP3でアクセスできる。
 （XXX.YYY.ZZZ.RRRは、メールサーバーのIP）
  そこで、どんな使い方をしているのか、自分の目で確かめる事にした。

[root@server]# telnet XXX.YYY.ZZZ.RRR pop3
Trying XXX.YYY.ZZZ.RRR...
Connected to XXX.YYY.ZZZ.RRR.
Escape character is '^]'.
+OK POP3 kkkkkk.xxxxx.co.jp v2001.78rh server ready
user suga
+OK User name accepted, password please
pass BBBBBB
+OK Mailbox open, 2 messages
list
+OK Mailbox scan listing follows
1 42398
2 1734
.
RETR 2
+OK 1734 octets
Return-Path: 
（途中、へッダーを省略）
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Status:   

本日、N所長　お休みです。

.
quit
+OK Sayonara
Connection closed by foreign host.

青い部分がPOP3のコマンド。
最初にユーザー認証が行なわれるので、user (ユーザーID)を打ち込む。
OKの返事が来たら、次にpass (パスワード)を打つ。
問題がなければ、OKの返答がきて、ユーザー認証が完了する。
listコマンドを使えば、何通メールが来ていて、それぞれのサイズが表示される。
REPT (メール番号)のコマンドで、該当のメールのへッダーと内容が表示される。

終わらせる時は、quitコマンドで終了させる。

赤い部分に注目！  なんとローマ字で「さよなら」ではないか！
もしかして、日本人が改良しているのではないかと思った。

  それにしても「SAYONARA」とは、オモロイ演出してくれるやんと思った。

 ローマ字で「SAYONARA」と書かれると、松本零士オタクの私は
「さよなら銀河鉄道999」をイメージしてしまう。
  テーマソングの名前に「SAYONARA」があるからだ。
  英語の歌だが「SAYONARA  Sweet memory it's good bye ♪」と
「さよなら」だけ日本語で出てくる。

  この「さよなら」には鉄郎に対して、少年の日の終わりを告げる意味がある。
  ナレータの名セリフ「999は鉄郎の心の中を走った青春という名の列車」がある。
  大人になった鉄郎。メーテルと今生の別れをして、地球に帰る姿が印象的だ。

  私も、青春時代に情熱を傾けた物はオープンソースというキザな発言をしてみたい。
  だが、鉄郎の場合、導いてくれる、美人のメーテルがいたが、私にはいない。
  「誰か、私に活力をくれるピチピチギャルを紹介してくれー！」と言いたいが、
そんな発言をすると、青春真っ盛りの人間どころか、エロオヤジ丸出しなので、
「どうせメーテルは、オバはんさ」と自分に言い聞かせる今日この頃 (^^;;

  余談をした所で、話をPOP3に戻します。
  POP3でメールを取り込んだ時、サーバーのメールボックスに保管されている
メールが削除される。
  それは、クライアント側のメーラーがPOPコマンドを使っているからだ。

POP3でメールを取り込むと
(1)	認証を行なう
(2)	メールを取り込む
(3)	サーバーのメールボックスにある取り込んだ分のメールを削除する。

  ちなみに、メール削除のPOPコマンドは、DELE (メール番号)となる。
  裏で、こんな動作が行なわれていたとは全く考えもしなかった。

  POP3以外に、IMAP4というものもある。
  POP3の場合、取り込んだメールの保管はクライアント側で行なうが、
IMAP4の場合は、サーバー側で行なう。それも個々のユーザーが所有する
ディレクトリーに保管される仕組みだ。
  この違いを利用した具体例として、Webメールがある。
  どこからでも、Webでアクセスし、Web上でメールの読み書きができる。
  サーバー側でメールを保管する事によってできる技だ。

  実は、うちの会社でも、Webメールの導入を検討した事があるが、却下になった。
  却下になった理由は次の通りだった

  サーバーに覚えさせたパスワードだと、人間が覚えられない！

  POP3で、しかも、OutlookExpressだと、サーバーに接続するパスワードと
ユーザーがメールソフトを開くパスワードを別々にする事ができる。
「システム奮闘記：その3」(社内でパソコン教室)でも触れたが、
覚えるのが大変なので、自分の名前をパスワードにする人や、
読まれても困らないので、パスワードを設定しない人がいる。
  一般利用者に、パスワードを見破られた時、サーバーが乗っ取られると言っても
ピンと来ないだろうし、踏み台にされる話をしても、理解してくれるとは思えない。
それどころか「うっとおしいなぁ」と思われるのがオチ。

  でも、簡単なパスワードにしてしまう気持ちは、よくわかる。
  ハッキリ言って「覚えられない」からだ！！
  あまり難しいパスワードにすると、今度は、紙に書いてパソコンに張る行動に出る。
  私自身、サーバーのパスワードを紙に書いて、サーバーに張っている。
  うちの会社だと、Linuxを触れる人がいないので、内部犯行はあり得ないので
管理者のパスワードを堂々と紙に書いて張っている。

Postfixの設定ファイル main.cfの設定方法

  メール配信の仕組みが、なんとなく、わかった所で、
sendmailからpostfixへの移行作業を始める事にした。

  まずは、RedHat7.3のCD-ROMに入っている、postfix-1.1.7-2.i386.rpmを
インストールした。
  そして、先ほども紹介した切り替えソフトを使って、Postfixへ切り替えた。

  設定ファイルだが、実に、設定しやすい。
  /etc/postfixにある main.cfを書き換えるだけだ。
sendmailのように、そこから何か生成するわけでもない。
  設定だが、お得意の本の丸写し作戦を敢行した ←　全く進歩があらへん (^^;;

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = AAA.BBB.co.jp  ←　メールサーバーのホストを記述
mydomain = BBB.co.jp ←　ドメイン名を記述
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain $mydomain
mynetworks = (うちの会社のネットワークアドレス), 127.0.0.0/8
alias_maps = hash:/etc/postfix/aliases
header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/header_checks
debug_peer_level = 2
debugger_command =
	 PATH=/usr/bin:/usr/X11R6/bin
	 xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
setgid_group = postdrop
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-1.1.7/samples
readme_directory = /etc/postfix/README_FILES
alias_database = hash:/etc/postfix/aliases

  さて、これで稼働させると

  見事、成功！！  V(^^)V


  これにて、移行作業が終了、「メールの話はおしまい！」といきたい所だが、
何せ、バージョンが、Postfix-1.1.7だ。
  古いバージョンなので、いくらセキュリティーホールが少ないソフトとはいえ、
最新のバージョンに上げておかないと安心はできない。
  そこで、2.0.X系の最新バージョンである、Postfix-2.0.20のインストールを
行なう事にした。

  もちろん、Postfix-2.0.20のRPMファイルは手元にないので、
ソースをダウンロードして、展開して、コンパイルをした。
  そしてインストールして設定ファイルの設定を行なった。
  これで安心だろうと思っていたら・・・

  端末からメールの送信ができへん！！

  思わぬ事態が発生した。
  そこで、慌てて、sendmailに戻そうとするが・・・

  sendmailに戻らへん (TT)

  バージョンアップするのに、全く問題が起こらないと思い込んでいたため、
社内でメールを使う時間帯に作業を行なっていた。
  このまま放置すると、社内から苦情がやってくるのが目に見えている。

  しかし、今までのシステム奮闘記にも書いている通り、散々、障害発生に
出くわしてきた経験もあって、障害に慣れたためか、混乱しなかった。

  まずは冷静に対応した。
  sendmailに戻しても、なぜかPostfixが立ち上がっている。
  そこで、/usr/sbinの中を見てみたら、なんとリンクが張られていない・・・

-rwxr-xr-x    1 root     root       402219  6月  5 17:20 sendmail
-rwxr-xr-x    1 root     root       108103  6月  5 17:19 sendmail.postfix
-r-sr-xr-x    1 root     root       451280  4月  8  2002 sendmail.sendmail 

  これを見た限り、sendmailの本体が居座っている感じがするが、異変に気づいた。
  前述しました通り、Postfix-1.1.7のファイルの大きさは100Kバイト、
Postfix-2.0.20は、400Kバイト。
  なんと、本来ならリンクで、実体のないsendmailが、400Kバイトで、
Postfix-2.0.20の本体になっている上、Postfix-2.0.20のはずの、
sendmail.postfixのファイルが、Postfix-1.1.7の本体のままになっている。

  sendmailの切り替えても、Postfixが立ち上げる理由がわかったので、
リンクの張り替えを行ない、MTAを、Postfix-1.1.7に戻した。

  これで、問題なく復旧した。

  なぜ、そんな障害が起こったのか原因は次のように考えられる。
  Postfix-2.0.20をインストールする際、何も考えずに、初期設定で
良かったものの、Postfixの本に書いているのを、見よう見まねで設定したため
おかしくなったと考えられる。

  Postfix-2.0.20をインストールする際、RPMでPostfixをインストールしていて
しかも、sendmailと切り替え環境の場合、 Postfix-2.0.20のインストール時に、
次のような問い合わせを行うからだ。

Please specify the final destination pathname for the installed Postfix
sendmail command. This is the Sendmail-compatible mail posting interface.
sendmail_path: [/usr/sbin/sendmail.postfix]     

  さて、Postfix-1.1.7で動かす事にしたのだが、問題がある。
  いくらPostfixは、ほとんどセキュリティーホールがないくらい
安全なソフトとはいえ、古いバージョンのソフトのままでは良くない。
  そこで、RPMファイルを探したら、Postfix-1.1.12が見つかったので、
そのバージョンにした。

  それからしばらくの間、Postfix-1.1.12で動かしていた。

  だが、古いバージョンではマズイと思い、Postfix-2.0.20を入れる事にした。

  さて、ソースから入れるのだが、トラブルが起こってはマズイ。
  この当時は、障害が出た原因がわかっていなかったからだ。
  恐る恐る、Postfix-2.0.20のソースを展開して、makeでコンパイル。
  そして、make installでインストール。
インストールの際の問い合わせは、全て初期値の設定のままにした。

  すると、問題なくソースからのインストールが成功した！！


(補足：2005年3月13日)


  上で書きましたPostfix-2.0.20のソースからのインストールを
ご覧になって、「なんで、RPMで古いバージョンのPostfixを入れた後に、
ソースからインストールするのやろ。最初からソースで入れればええのに」と
思われる方がいるでしょう。
  その理由は次の通りだった。

  最初からソースでインストールするとエラーが出るのらー！！

  make installでインストールをする際に、
次のエラーが出ていたからだった。

Please specify the destination directory for the Postfix README
files. Specify "no" if you do not want to install these files.
readme_directory: [no] 
postfix-install: Error: "postfix" needs an entry in the passwd file.
Remember, "postfix" needs a dedicated user and group id.
make: *** [install] エラー 1

Postfixは、Postfixというユーザー権限で実行されるデーモンなので、
ユーザー登録を行う必要がある。しかし、ユーザー登録されていないので
「ユーザー登録が必要やで」というエラー表示だ。

Postfixを動かすには、Postfixというユーザー名と、postdropという
グループ名を登録する必要がある。
ここで、RPMの便利さが感じられる。RPMだと、自動的に行ってくれるため、
本当に何も考えずに済む。
しかし、ソースだとユーザー名とグループ名は手動で登録する必要がある。

  最初にソースからインストールに挑戦した時は、Postfixの事を
詳しく調べる前だった事もあり、Postfixというユーザー登録が
必要だった事を知らず、「エラーが出たから、設定できへん」だった。

  そして、何のエラーが、調べないまま、放置していたのだった。


  しかし、エラーの原因が何であるかが、わかる日がやってきた。
  それは、2005年2月に、メールゲートウェイのサーバーを入れ換えた際、
Postfixを新たにインストールする必要があったからだ。

  この時、インストール作業を慌てる必要がなかったので、
古いバージョンのRPMをインストールしなくても、ソースからインストールが
できるようになろうと考えた。
  この時、選んだのは、2.1.X系で最新のPostfix-2.1.5だ。

  早速、ソースをダウンロードして、インストールを行う。
  何も考えずに、makeを行い、何も考えずに、make installを行う。

  make installで、何も考えずに、デフォルト設定の選択を行っていると
エラーが出た。上で紹介したエラーだ。
  単なる、ユーザー登録のし忘れだった。

  ふと思った。「そういえば、RPMを入れずに、ソースからインストールした時
同じエラーが出たなぁ」だった。
  だが、この時は、Postfixを動かすのに、特定のユーザーとグループ登録が
必要な事は知っている。そのため、この時、全てがわかった。

  初めて、RPMを入れずに、ソースからインストールした時、
ユーザーとグループ登録なんぞしているわけがない。
  そのため、エラーが出たのだ。

  そこで、試しに、ユーザー登録をした後、わざとグループ登録をせずに
インストールを再開した。すると・・・

  予想通りエラーが出た！！

Please specify the destination directory for the Postfix README
files. Specify "no" if you do not want to install these files.
readme_directory: [no] 
postfix-install: Error: "postdrop" needs an entry in the group file.
Remember, "postdrop" needs a dedicated group id.
make: *** [install] エラー 1

  そこで、グループ登録を行い、インストールを再開すると、問題なく完了した。

  さて、ソースからインストールの場合だと、ユーザーとグループ登録が
必要だという事がわかった。
  ふと疑問に思った。RPMの場合は、ユーザーとグループ登録をしなくても
なぜ、大丈夫だったのか。
  そこで、試しに、RPMでPostfixをインストールしてみた。
  すると、自動的に登録される事が確認できた！

  全てが解明できて、万々歳 (^^)V

  さて、ユーザー登録における注意点も書きます。
  Postfixというユーザー名を登録する場合、このユーザー名で
ログインを可能にしてしまうと、メールの権限を奪われる危険性がある。
  そこで、ログインを不可能にする設定を行う必要がある。

  これで、乗っ取られる危険性が減る。めでたし、めでたし！

  あとは、再起動時に、自動的に立ち上がるように処置を行う。

  そして、長い補足を終わります。


Postfixでウイルス対策

  ウイルス対策だが、main.cfに次の部分を追加すればできると
SoftwareDesign2004年4月号には書いていた。

  バージョンの違いで、ちょっと記述が変ってしまう。
  肝心のheader_checksファイルの中身だが

header_checksファイルの中身
↑ 　ここの空白だが、これはスペース1個とタブを入力します。

  これを設定すると、添付ファイルの拡張子が、exe、scr、pifの場合は
ウイルスメールとして受信拒否をしてくれる。
  これら3つは、ウイルスメールの定番拡張子といっても過言ではない。
  もちろん、うちの会社から、上に上げた拡張子の添付ファイルを送ろうとしても
SMTPが拒否してくれる形になる。

  本当に、ウイルスメールを拒否されているのか、ログを見てみる事にした。

May 17 19:03:31 AAAA postfix/cleanup[11448]: B9E2DFA83: reject: 
body ?name="your_text.pif"; from=<XXXXX@AAAA.BBBB.co.jp> 
to=<suga@AAAAA.co.jp>: Message content rejected

  これで、ウイルス騒ぎが起こらないだろうと思っていた数日後、
役員から「変なメールが来とるから、見てくれへんか」と言われた。
  ウイルスメールだった。しかし、拡張子が「zip」には網を張っていなかったため
素通りだった。
  そこで、拡張子が「zip」、「com」も網の対象にした。
  
  拡張子が「zip」の場合、圧縮ファイルの可能性がある。
もちろん「exe」の場合、まともなソフトの実行ファイルの場合だったり、
自己解凍ファイルの場合だって考えられるが、安全性を考えた場合、
これらのファイルも網をかけておいた方が良いと考えている。

Jun 15 16:05:26 kkkk postfix/cleanup[3532]: E799C138E1: reject: header 
Content-Type: application/octet-stream;??name="jennifer the wild girl xxx07.jpg.pif"
from AAA.BBB.ne.jp[XXX.YYY.ZZZ.RRR]; from=<aaaa@bbbbb.co.jp> 
to=<aaaa@fffff.co.jp> proto=SMTP helo=<smtp.fffff.co.jp>: 
Message content rejected
  一見、画像データと思わせるウイルスファイル

Jun 18 15:45:38 kkkk postfix/cleanup[25272]: 470AC138E1: reject: header 
Content-Type: application/octet-stream;??name="postcard.doc                   
                                                .pif" 
from ccc.aaaa.or.jp[XXX.ZZZ.RRR.CCC]; from=<aaaa@bbbb.co.jp> 
to=<nnnnn@aaaa.co.jp> proto=ESMTP helo=<aaaa.co.jp>: 
Message content rejected
  ファイル名と、拡張子の間を長い空白を開けるウイルスファイル
  しかも、ワードのファイルと間違えやすい

  このフィルターをつけてから、ウイルスメールが出た話は聞かなくなった。
  ログを見ていると、結構、網にかかっているのを見て、簡易フィルターだけど
大した物だと感心してしまう (^^)

  逆に言うと、それだけウイルスメールの侵入していた事になる。

main.cfファイルの詳細説明

  これでメールの仕組みと設定方法は理解したと思いたい所だが、
まだまだ知らない事の方が多い。「丸写しでも動けば、ええやん！」と言いたいが
根本的に本の丸写し状態から脱却しないと

  障害発生時には、何も対処できへん！

  そこで、知らない事を潰していく事にした。

  まずは、main.cfの設定ファイルで、わからない部分があった。

  何かの呪文かもしれないが、本を調べると

  もちろん、本の説明を読んだ私は、いつもの如く

  意味が全く理解できへん （ＴＴ）

  だった。

  Webサイトで調べると、メールの受け付けを、ホストやドメインなどで
受け入れの許可・拒否する項目だという。
  メールの中身や特徴などで拒否するのではなく、入口で決めるという話だ。

  それでも、どういう事を言っているのか、まだ、理解できない。
  そこで、実際に、設定の値（ホスト名など）を変えてみて、動作の変化を
調べてみる事にした。
  そこで、次のように設定を変更してみた。

  そして、この設定を反映させるため、/etc/rc.d/init.d/postfix reloadを行なった。
  が、しかし、何も変化がなかった。

  変化しないという事は一体、どういう項目やねんとなる。頭が混乱しそうになるが
幸い、この部分を変更した場合は、一度、Postfixを落とさないとダメだという事が
わかった。
  そこで、/etc/rc.d/init.d/postfix restartを行なった。

  すると、外部からのメールが届かなくなっただけでなく、クライアントからの
メールを送信する際、中継が拒否されるようになった。

  この事から、次のような設定だという事がわかった。

こんな意味の項目だった
この設定は、メールサーバーへやってくるメールの送信元を見て、 受け入れをするかどうかの判定に使われる。 そのため、上のように、localhostという設定にしてしまうと、 自分自身から受け取ったメール以外は、受け入れないという事になり 外部からのメールが到着しなかったり、社内のクライアントのメールが 送信できなかったりする。

  これで1つ、解決した (^^)

VRFYとETRN 不要なメールコマンド

  ところで、main.cfファイルの設定で、不要なメールコマンドの使用防止のため
次の設定を付け加えたら良いと書いているWebサイトなどがある。

  上の方で、メールの送信のやりとりのために、メールコマンドを話を
いくつか書いたが、実は、それ以外にも、結構あるという。

  一体、VRFYとETRNは何やねん！

  そこで調べる事にした。

  VRFYコマンドのように、わざわざ、ご丁寧に、自分の情報を披露してくれる
コマンドがあるとは驚いた。
  もし、「VRFY」コマンドを使わせないようにする設定をしなければ、
次のようになってしまう。

[root@server]# telnet  XXX.YYY.ZZZ.RRR smtp
Trying XXX.YYY.ZZZ.RRR...
Connected to XXX.YYY.ZZZ.RRR.
Escape character is '^]'.
220 kkkk.xxxx.co.jp ESMTP Postfix
VRFY suga
252 suga
VRFY test
450 : User unknown in local recipient table

  そこで、「VRFY」コマンドを禁止の設定にしてみると

[root@server]# telnet XXX.YYY.ZZZ.RRR smtp
Trying XXX.YYY.ZZZ.RRR...
Connected to XXX.YYY.ZZZ.RRR.
Escape character is '^]'.
220 kkkk.xxxx.co.jp ESMTP Postfix
VRFY suga
502 VRFY command is disabled

  もちろん、VRFYコマンドなんぞ、今まで知らなかった。
  sendmailの設定で、設定ファイルを見てみると・・・

  どうやら、丸写ししていたようだった (^^;;

  実は、2003年2月以降は、ADSLルーターのお陰で防御できている。
  ヤマハのRTA55iのルーターには、怪しいメールコマンドを拒否する機能が
ついている。

2004/06/07 04:22:21: TCP SYN and FIN        XXX.YYY.ZZZ.RRR  > AAA.BBB.CCC.DDD  
 2004/06/07 11:32:39: SMTP VRFY command      XXX.YYY.ZZZ.RRR  > AAA.BBB.CCC.DDD
 2004/06/08 17:39:04: ICMP too large         XXX.YYY.ZZZ.RRR  > AAA.BBB.CCC.DDD  

  いかにも、ルーターを設定した時から、メールコマンドの問題を
知っていたかのように文章を書いていますが、実は・・・

  この奮闘記を編集するまで知りませんでした (^^;;

  そうなのです。この奮闘記を書いて、初めて、この機能が付いていた事を
知ったのです。
  幸い、2003年2月にルーターを設定した時に、セキュリティーを
向上させるために、不正アクセスを破棄する設定を行なった。
  この時、たまたまメールコマンドが含まれていたため、知らぬ間に、
キチンと設定していた事になっていた。

  だが、2003年2月以前は、不正なメールコマンドを破棄する
ルーターを設置していなかった。
  sendmailの設定も、2003年2月以前は、VRFYコマンドを拒否する
設定は全くしていなかった。

  つまり、情報が漏れていたのだった (^^;;

  だが、人類は過去を引きずってはいけない。前進してこそ、進歩なのだ。
というわけで、前進するために、過去の失敗談から、話をそらしまーす (^^)

  ETRNコマンドについてだが、サーバーからクライアントへ
メールを転送させるコマンドだが、始め、何の事か理解できなかった。
  しかし、調べていくと「なるほど」と思った。

ETRNコマンドの役目
自宅サーバーのメールが、プロバイダーのMTAサーバーを経由させる場合がある。 自宅から外部へメールを送信する場合は、ダイヤルアップさせて送信すれば、 良いのだが、外部から自宅サーバー宛の場合、プロバイダーから送信する方法がない。 そこで、自宅サーバーがプロバイダーへダイヤルアップした時に、 プロバイダーのMTAに溜まったメールを、自宅に転送してもらうように 指示を出す必要がある。 この時、指示を出すために、ETRNコマンドを使うという。

  常時接続が当たり前の時代に、こんな場合は稀だと思うし、使う事はないので、
ETRNコマンドは使えなくするのが無難だと思う。

  これに似たコマンドで、TURNコマンドがある。
  これはETRNコマンドと違って、セキュリティーに配慮していないから
ETRNへ切り替えた方が良いみたいだ。

  TURNとETRNは、両方とも使わないから、私は深くは取り上げません。
  だって、詳しく調べるのが面倒だもーん (^^)


  他にも、メールコマンドがあるのだが、あまり使われない、使わないため
省略をしまーす。
  省略すると「手を抜くな！」と言われそうなので、堂々と反論します。

  だって、使わないもーん！！ (^^)

  そうなのです。事務員の私が複雑なメールサーバーを組めるわけないのです。
  というわけで、とっとと逃げる事にします。

メールの中継と不正中継(セキュリティー)の話

  ところで、メールの設定を行なう際、必ず、不正中継防止の話が出てくる。

  不正中継とは、外部の悪い奴が、メールサーバーへ接続して、
勝手にメールを送る行為を言う。
  大量にスパムメールを配信されると、送信元は、乗っ取られたサーバーなので
送信元に苦情がやってくる。

  不正中継ができる理由だが、元々、SMTPにはユーザー認証がないからだ！

  メールの受信の場合、POPがユーザー認証を行なってくれるため、
IDとパスワードがバレなければ大丈夫なのだが、SMTPの場合、
SMTPコマンドでメールを送信する実験で行なった通り、認証を行なわない。
  そのため、何も対策を立てなければ、簡単に不正中継をされてしまう。

  対策の一つは、設定ファイルの記述にある。
  必要なホストだけ中継を認める設定ができる。

  今でこそ、上の設定の意味が、どのホストからのメールの中継を認めるかどうかの
設定だという事を理解しているが、最初、この設定の意味がわからなかった。
  ここで暴露します！

  クライアントからメールサーバーへメールを送る事を、メールの中継とは
全く思っていませんでした (^^;;

実は、これもメールの中継だったとは知らなかった (^^;;

  メールの中継といえば、下図のようなメールサーバー同士での
バケツリレーを連想してしまう。

こういうのがメールの中継と思っていた (^^;;

  そのため、なぜ、メールサーバーの設定で、自分の所のメールの中継を
許可するのか理解できなかった。
  幸い、設定時は、本の丸写しをしたお陰で、メールの送信ができないトラブルが
起こらなかった (^^;;
  この原稿を書く時、メールの中継について、調べている間に、クライアントから
メールサーバーへメールを送信する事も、メールの中継に含まれる事を知り、
ようやく合点がいった。

  
  自分の無知さを暴露した所で、不正中継の話に戻します。
  不正中継の方法は以下の図のようになっている。

メールの不正中継の概略

  「だったら、メールを中継できるホストの制限をすれば、ええやん」となる。

  全てのクライアントが社内にあり、特定のネットワークアドレスに該当すれば、
そのネットワークアドレス内からのメールの中継を許可すれば良いのだが、
例えば、モバイルで外からネットをつないだ時、IPアドレスが自動取得の場合
どのIPアドレスがわからないため、メールの中継の制限ができなくなる。

  必然的に、全てのホストからのメールの中継を許可せざる得なくなる。
  これからの時代、モバイルが増えるだろう。

  そこで、認証を組み込めば良いという発想で、POPを使った認証がある。
  通称、POP before SMTPという物だ。

  それと、もう一つ、SMTP認証というのがある。

POP Before SMTPとは何か
メールサーバーに接続して、メールを送信する前に、 POPの認証機能を使って、ユーザー認証を行なう。 認証が成功すれば、正規のユーザーが接続した事になり、 そこから、メールの中継を行なうようにしている。
SMTP認証とは何か

  うちの会社には、今の所、必要ないので、話はこれぐらいにします。
  こんな事を書くと「手を抜くな！」と言われそうなので、反論しますと

  泥沼にハマった割りには、成果があらへんかった （ＴＴ）

  実は、色々なWebサイトの設定方法を見て、真似したりしたのですが、
全く設定ができなかったのです！！

  しかも、泥沼にハマッて、気が変になった後で、POP Before SMTPは、
OutlookExpressでは、使えない事を知りました。
  無駄な時間を潰してしまった事に、ショックと疲労に襲われました (--;;

  それが尾を引いたのか、SMTP認証についても、少し設定に挑戦したが、
あまりやる気が起こらずに、すばやく切り上げました。

  SMTP認証だが、クライアント側には特殊なメーラーが必要かと思いきや
Windowsマシンで身近な、OutlookExpressでも簡単に設定ができる。

OutlookExpressでの、SMTP認証の設定
この時、赤く囲んだ部分に印を入れて、「設定(E)」を押す

  そして、次の設定を行なう。

utlookExpressでの、SMTP認証の設定
この時、受信サーバーと同じにするか、別のIDとパスワードで 認証を行なうかを聞いてくるので、サーバーの設定によって決まるみたい。

  「サーバーの設定によって決まるみたい」と、あやふやな事を書いていながら、
なぜ、SMTP認証の設定ができると書けるのか。
  これに関しては、後述にしています。

  今回、この設定の失敗で、大きな打撃を食らっただけに、
2度と、設定する機会に出くわさない事を願うばかりだ。

メールゲートウェイ

  さて、メールの中継といえば、メールゲートウェイがある。
とわかった風に書いているが、今回の編集で知った知識である事は言うまでもない (^^;;

メールゲートウェイとは
既存のメールサーバーと、インターネットとの間に 1つ、中継のためのメールサーバーを挟む事がある。 このサーバーの事をメールゲートウェイという。

  どんな風に使われるかというと、SoftwareDesignに載っていた。

メールゲートウェイの使われ方
メールゲートウェイに、ウイルスフィルターを入れる使い方がある。 既存のメールサーバーにウイルスフィルターを入れると、設定変更などで メールサーバーに影響を及ぼす事があるが、メールゲートウェイに入れると 既存のメールサーバーとは独立しているため、最小限の設定で良い。

  なるほど、そんな使い方があるのかと感心してしまった。
  ネットなどで調べていると、違った意味でのウイルスフィルターの使われる方が
ある事を知った。

メールゲートウェイの使われ方：その2
大手企業やブロバイダーのように、いくつかのメールサーバーがある場合、 個々のサーバーにウイルスフィルターを入れると、メンテナンスが大変な事から メールゲートウェイを設けて、メールの通り道を一本化して対応する場合がある。 この場合だと、1台のメールゲートウェイのメンテだけで済むという。

  なるほど、そういう使い方もあるのか。
  今の会社にいる限り、複数のメールサーバーを設ける事はあり得ないが、
仮に、どこかの大手企業のシステム部門に転職した場合は、こういう場合と
巡り合えると思う。
  まぁ、大規模ネットワークの構築経験がないと、転職しようにも
全く相手にされないけれど・・・ (^^;;

メールゲートウェイの使われ方：その3
DMZにメールゲートウェイを置いて、LAN内に既存のメールサーバーを置く事により 例え、メールゲートウェイが攻撃されても、既存のメールサーバーが攻撃されない限り ユーザー情報などが守られる。 メールゲートウェイは、一種の防波堤の役目を担ってくれる。

  メールゲートウェイの使い方を見て、これは使えると思った。

  何せ、設定の失敗談なら、天下一品の私なので、もし、ウイルスソフトを入れて
ドツボにハマって、メールサーバーを止める事態になってたら大変な事になる。
  設定変更等の影響を最小限に押さえる事ができる上、防波堤としての役目としての
メールゲートウェイの活用もできる。

  導入価値は充分ある！

  そう判断した私は、早速、メールゲートウェイの設定を行なおうと思った。
  だが、既存のメールサーバーを下手に触って、動かなくなるトラブルが
発生してはマズイ。
  メールは止められない通信基盤になっているため、システム管理者の勝手な都合で
止めるわけにはいかないからだ。

  そこで、安全に実験(?)を行なうため、次のような実験を行なう事にした。

メールゲートウェイ構築のための実験
既存のメールサーバーを、運用したまま、サブドメイン（dummy）への メールの中継を行なうようにした。 これだと、既存のメールサーバーの変更は最小限で済むと考えた。 この方法を覚えれば、メールゲートウェイの構築方法を 習得したのと同じと言える。

  さて、Postfixの本などを見ながら、設定（本の丸写し）を行なう事にした。
  まずは、DNSの設定を行なう。そうでないと、

xxxx.co.jp.         IN      MX      10      mail.xxxx.co.jp.
dummy.xxxx.co.jp.   IN      MX      10      mail.xxxx.co.jp.

  これで、実験サーバー（dummy）宛のメールは、既存のメールサーバーを通過する。

  次に、実験サーバーの方の設定だが、極めて簡単だった。
  単に、設定ファイルの一ヶ所だけ、設定を行なうだけだからだ。

  kizon.xxxx.co.jpは、既存のメールサーバーのアドレスだ。
  この設定は、実験サーバーから発信されるメールは、既存のメールサーバーを
中継させるという意味だ。

  ここで、実験サーバーから、外部へメールを送信する事にした。結果は

  見事、成功！  V(^^)V

  実際に、無事、既存のメールサーバーを中継しているのかどうか、
既存のメールサーバーのログを見てみる事にした。

Jun 22 16:05:01 aaaa postfix/pickup[2807]: 9CEDB805E1: uid=1000 from=<maro>
Jun 22 16:05:01 aaaa postfix/cleanup[2822]: 9CEDB805E1: 
                message-id=<20040622070501.9CEDB805E1@aaaa.xxxx.co.jp>
Jun 22 16:05:01 aaaa postfix/nqmgr[2595]: 9CEDB805E1: from=<maro@dummy.xxxx.co.jp>, 
                size=322, nrcpt=1 (queue active)
Jun 22 16:05:01 aaaa postfix/smtp[2829]: 9CEDB805E1: to=<sugachan77@hotmail.com>, 
                relay=bbbb.xxxx.co.jp[XXX.YYY.ZZZ.RRR], delay=0, 
                status=sent <250 Ok: queued as 48983138DC>

  さて、次に、実験サーバーが外部からのメールを受信できるかだ。

  ここで、また、いつもの失敗談の生産が始まった！！
  

  その次に、transportファイルの設定を行なう。
  ここで、記述間違いをしてしまった！！

dummy.xxxx.co.jp       aaaa.xxxx.co.jp

  この時点で、記述間違いをしている事に気が付かなかった。
  なぜなら、この時点では、正しいと思って設定しているからだ (^^;;

  そして、transportファイルから、データベースファイルを作るため

　postmap /etc/postfix/transport

　コマンドを使う。
  すると、/etc/postfix/transport.dbファイルが作成される。

  最後に、Postfixを再起動をかける。

  さて、実験サーバーから外部へメールを送ろうとしたのだが・・・

  全く送信できへん (TT)

  困ったもんだ。
  なぜ、送信できないのか、理由が全く見当できなかった。

  色々、本やネットを見て、原因を探っていくと、transportファイルの
記述間違いが原因だとわかった。

dummy.xxxx.co.jp       smtp:[aaaa.xxxx.co.jp]

  これで大丈夫だろうと思い、postmap /etc/postfix/transportコマンドを使おうとするが、
transportなどの「port」の綴りばかり見ていたためなのか、

  postmapを打つ所を、portmapと打ってしまった (^^;;

  しかし、その時は、間違いに気づくわけがない。
  そして、Postfixを再起動させて、外部から実験サーバーにメールを送ってみた。

  全く送信できへん (TT)

  そこで、また、本などを見て、設定の不備などを探すが見つからない。
しかも、portmapが正しいと思い込んでいるため、何度も同じ事を繰り返しては

  全く送信できへん (TT)

  だった。

  そこで、視点を変え、サーバーのログを見てみる事にした。

Jun 22 14:13:12 bbbb postfix/trivial-rewrite[19527]: warning:
                database /etc/postfix/transport.db is older than source file
                /etc/postfix/transport
Jun 22 14:13:12 bbbb postfix/nqmgr[19525]: warning: connect to transport 
                bbbb.xxxx.co.jp: No such file or directory

  これを見て、transportからtransport.dbが生成されるのに、
なんで、transportファイルの方が新しいねんと思った。
  ls コマンドで見てみると、transportファイルの方が新しい。
  つまり、transport.dbが生成されていない事を意味する。

  そこで、調べていくと、綴り間違いに気がついた。
  この瞬間、メチャクチャ力が抜ける。他の要因で設定がうまい事いかない場合は、
「大変だったが、新しい発見」となるが、綴り間違いだと時間の無駄以外の
何者でもないだけに、凄く疲れる (--;;

  そして、今度こそと思い、Postfixを再起動して、外部からメールを送信すると

  見事、成功！  V(^^)V

  実験サーバー宛のメールを中継する既存のメールサーバーのログを見てみる事にした。

Jun 22 15:44:28 bbbb postfix/smtpd[20523]: 
                connect from sea1-f133.sea1.hotmail.com[207.68.163.133]
Jun 22 15:44:28 bbbb postfix/smtpd[20523]: 7708E138DC: 
                client=sea1-f133.sea1.hotmail.com[207.68.163.133]
Jun 22 15:44:29 bbbb postfix/cleanup[20525]: 7708E138DC: 
                message-id=<Sea1-F133l8dUhn226C0005b665@hotmail.com>
Jun 22 15:44:29 bbbb postfix/nqmgr[20519]: 7708E138DC: 
                from=<sugachan77@hotmail.com>, size=1152, nrcpt=1 (queue active)
Jun 22 15:44:29 bbbb postfix/smtp[20616]: 7708E138DC: 
                to=<maro@dummy.xxxx.co.jp>, 
                relay=aaaa.xxxx.co.jp[XXX.YYY.ZZZ.RRR], delay=1, 
                status=sent (250 Ok: queued as CECB4805E0)
Jun 22 15:44:29 bbbb postfix/smtpd[20523]: 
                disconnect from sea1-f133.sea1.hotmail.com[207.68.163.133]

  これで、メールゲートウェイの構築方法がわかった！！

  そこで、応用編を考えてみた。
  既存のメールサーバーをNATの中、すなわち、LANの中に入れてしまい、
メールゲートウェイを完全にダミーのマシンとして見せる技である。

メールゲートウェイ構築のための実験：その2
実験サーバーをLANの中に入れて、完全に外から見えないようにした。 そして、実験を行なった。

  この時、NAT越えを行なうため、少し工夫が必要になる。
  ここで私が泥沼にハマっていくのを楽しみにしている方がおられると思います。

  そう期待された方、申し訳ありませんが、簡単に設定ができました。

  まずは、既存のメールサーバーから実験サーバーへ転送するための処理だが、
taransportファイルの記述に工夫している。

dummy.xxxx.co.jp       smtp:[nat.xxxx.co.jp]

  そして、NATを越えるのだから、iptablesの設定も必要。

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to 192.168.XXX.YYY
iptables -A FORWARD -i eth0 -p tcp --dport 25 -d 192.168.XXX.YYY -j ACCEPT 

  あとは、DNSの設定だが、

xxxx.co.jp.         IN      MX      10      mail.xxxx.co.jp.
dummy.xxxx.co.jp.   IN      MX      10      mail.xxxx.co.jp.

  この3点セットの設定を変更するだけで簡単にできた (^^)V

  いつも失敗談を生産している私だが、たまには簡単に設定ができる事もあります。
  NATは「システム奮闘記：その21」、DNSは「システム奮闘記：その22」で
泥沼にハマッたため、そう簡単には泥沼にはハマらなくなった (^^)V


  メールゲートウェイの考え方。使えると確信した。
  ユーザー管理をしているマシンを、NATの中に入れる事により、
少しでも安全性を高める事ができるからだ。

  ウイルスゲートウェイのソフトと、メールゲートウェイを組み合わせて
しっかりとした門番を作ろうと思った。

  この話は、実現するのに、予算の関係等で、時間がかかると思うので
別の機会に取り上げたいと思います。
  ボツになっている場合もありますので、あしからず。

BITNETの話

  さて、メール中継の話。わかれば、意外と話は簡単だなぁと思った。
  ところで、Postfixの本を見ると、興味深い事が書いていた。

  BITNETの話だ。
  4年前に、sendmailの設定（本の丸写し）をした時に出てきた話だが、
この時は、何の事か、わからなかった。本を読むと、学術ネットの事だという。
  以前は、学術ネット上は、非私的、非商用のメールしか送信できなかったため、
私的メールや商用メールなどは迂回する必要があったという。

  現在は、その心配はないため、BITNETの設定は必要ないが、
当時は、あったという。
  メールの中継の問題も、昔は、今より複雑だったんだなぁと思った。

  インターネットが爆発的に普及する前を、少し知っているだけに、
色々な事があったんだなぁと、染々、思う今日この頃。

メール中継に関する私の勘違い

  中継の方法を覚えて、ようやくメールの送信の話が理解できたと思う (^^;;

  ここで暴露しまーす！

  2年前までは、メールが相手先に届くまで、いくつかのメールサーバーを
中継して届くと思っていた。

2年前ぐらい前まで思っていた、メールが届くまでの道程
sendmailの設定で、不正中継などの話が出てくる。 その時、「中継」という言葉を混同しため、メールは、相手に届くまでに、 バケツリレーのように、何台ものメールサーバーを、中継して届くと思った。 しかも、パケット送信の際、ルーターやサーバーを経由するのと同じく、 各ネットワークの中継地点ごとにメールサーバーがあり、メールは、 そこを中継する物と思っていた。

  だが、この奮闘記を書く際に「この考えは、おかしいぞ」と思った。
  「メールの中継」の話を理解する前に、次のように結論づけたのだった。

相手にメールが届くまでの道のりを、下図のように考えた

  メールの送信をする際、自分の所のメールサーバーが相手のメールサーバーへ
直接、メールを送ってやりとりすると結論づけた。
  もちろん、奮闘記の編集当初は、メールの中継の話を取り上げる予定がなかったので
送信元と送信先のメールサーバー以外は、メールの送信に関与（中継する事）はないと
結論づけようとした

  しかし、後になり、いくつか中継されているケースもある事を知った。
こんな感じなので、メールのお勉強には時間がかかる・・・ (--;

メール中継とmain.cfの設定

  メールの中継の話が出てきた所で、メール中継の制御に関する main.cfの設定の
話をしたいと思います。
  Webサイトなどに不正中継防止のため。HELO（EHLO）のコマンドを
使わずに中継する場合を拒否する方法や、接続元のIPが逆引きできない場合を
拒否する場合などの方法などが書かれている

  しかし、残念ながら、個人の方が公開されておられるWebサイトなので、
詳細などが書かれていない場合が多く、丸写しにならざる得ない。

  ここで暴露しまーす！！

  私自身、Webサイトに載っている設定を、意味を理解せずに丸写ししていました。
  しかも、丸写しした部分は、上手に避けようと思っていました (^^;;

  「なんて奴だ、手を抜くな！」と言われそうなのですが、
奮闘記のネタが多いため、できるだけ早く編集を終わらせて、次へ行きたいため、
いつも耳元で「手、抜いても、ええやないの」という悪魔のささやきが聞こえてくる。
  そのため、誘惑に非常に弱い私は、次のネタを書くために、
「事務員だから、わかりませーん」で逃げようと考えていました (^^;;

  しかし、逃げようとしても、丁度、良い時期に、わかりやすい本が
見つかるため、逃げれなくなったので、正直に、知らなかった部分を
暴露しながら、取り上げていきます。

  さて、良い本とは、次の本だ。

  「入門 Postfix」（野村 直：ASCII）

  この本を頼りに、main.cfに関して、詳しい設定を見てみる事にした。  

  さて、私が丸写しにして、そのまま取り上げずに逃げようと考えた
設定部分を紹介します。

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetwork , reject_invalid_hostname , reject_unknown_client
smtpd_sender_restrictions = reject_unknown_sender_domain

  まずは、1行目の設定を見ていくことにする。
  メールの中継制御で、HELO（EHLO）のコマンドを要求する設定だ。

smtpd_helo_required = yes

HELO（EHLO）のコマンドを使用しない場合は拒否する設定。
  人間社会で言えば「挨拶ができへん奴の言う事なんぞ聞くか！」と同じ。
  恐いお兄さん達の世界では「われー、挨拶もできへんくせして、
いっぱしの口、きくんか！ われ、出直してこんかい！」という感じです。
  まぁ、まともなMTAやメーラーなら、キチンと挨拶するので、
怪しいメール（SPAMなど）を防止するのに、YESにしておきましょう。

  HELOの挨拶に関連する設定で、次のような設定がある。

smtpd_helo_restrictions = permit_mynetwork , reject_invalid_hostname , reject_unknown_client

  HELOの挨拶に関した設定と、わかった風な事を書いたが、
実は、この設定、Webサイトに載っていた設定方法の丸写しで、
具体的に、どういう設定かは、奮闘記を編集するまで、よくわからなかった。
  そこで、本を調べてみる事にした。

メールサーバーに接続した際に、HELO（EHLO）の後ろに接続元の
ドメイン名を記入して、挨拶するのがルールなのだが、SPAMなどでは
テキトーなホスト名を書いたりする。そこで、おかしなホスト名などを
チェックするための項目だという。

permit_mynetwork は、$mynetwork に当てはまるホストは許可。
reject_invalid_hostname は、おかしな構文のホスト名は拒否。
reject_unknown_client は、DNSで名前が引けないホスト名は拒否

  この設定をすれば大丈夫かと思えば、思わぬ所に落とし穴があった！！

  取引先からメールが来ない （ＴＴ）

  なんと、取引先からメールが届かなくなった。
  この設定をして、翌日、どれだけ網にかかっているだろうかと
メールのログを見た所、目を疑った。
  取引先のドメインのアドレスを拒否している！！

Jun 22 14:46:25 kkkk postfix/smtpd[19859]: E001C138DC: 
reject: RCPT from unknown[XXX.YYY.ZZZ.RRR]: 
450 Client host rejected: cannot find your hostname, [XXX.YYY.ZZZ.RRR]; 
from=<ttttt@aaaa.com> to=<xxxx@xxxx.co.jp> 
proto=ESMTP helo=<cccc.yy.aaaa.com>

  DNS検索で、helo=<cccc.yy.aaaa.com>の書かれている
アドレス検索を行なったら、DNS検索ができなかった

  その取引先のDNSの設定がいい加減なのか、おかしなホスト名と認識されてしまい
メールが拒否されるようになった。

  勇気を持って、取引先に確認をお願いしようと思ったのだが、
何せ海外の取引先。相手に、わかりやすく英語で説明できるほどの語学力がないため
渋々、この設定を外す事になった (--;;


  閑話休題。メールのチェック項目は、まだある。
  メールコマンドで、HELO（EHLO）の挨拶の後、送信先を知らせるため
「MAIL FROM」コマンドがある。
  これは、メールの差出人のアドレスを知らせるコマンドだ。

  やってきたメールの「MAIL FROM  コマンド」（差出人）の確認も
できるというのだから、芸が細かいと思ってしまう。

smtpd_sender_restrictions = reject_unknown_sender_domain

  これは、見せかけの送信元のアドレスでメールが届いた場合の確認になる。
見せかけのメールアドレスは、何も悪いわけではない。
  返信先を、別のアドレスにいたい場合には、見せかけのアドレスを
その返信先のアドレスにすれば、便利に使える。

  だが、いたずらメールや、ウイルスメールなど、送信元が実際に存在しない
アドレスの所になっている場合がある。
  そういうメールは拒否すれば良いので、上のような設定を行なえば良いのだ。


  これ以外に、メール中継の制御といえば、次の設定がある。
  先ほど紹介した2つの制御を組み合わせた物がある。

  これ以外にも、他にもあるが、書くと大変なので、割愛します。
  詳しくは、次のURLをご覧ください。
  http://www.asi.co.jp/techinfo/unix/postfix.html


  この辺の設定は、むやみやたらと厳しくできる物ではない。
  相手先のDNSの設定が、いい加減だったりすると、不正なメールとして
処理されてしまうからだ。
  安全性と利便性を天秤にかけるのは難しいと思う今日この頃 (--;;

main.cfの設定 HELOとEHLOの違い

  さて、メールコマンドで、HELO（EHLO）と書いている。
  ところで、HELOとEHLOの違いは何と聞かれると私は、こう答えます

  わかりませーん (^^)

  すげー、開き直りの精神でいる私だった。
  調べてみると、この違いは次の通りだ。

  さて、ESMTPって何という疑問が出てくる。

  ESMTPとは、SMTPの機能を持った上で、拡張機能がつけた物になる。
  具体的には、ETRNコマンドが使えたり、SMTP認証（SMTP-AUTH）が
使えるようになったりする。
  それ以外にも、メールは7ビット文字で送信するのが原則だったが、
ESMTPだと、8ビット文字でも送信可能になっている。
  ただし、「システム奮闘記：その14」で触れたが、ESMTPの実装が
いい加減なサーバーがあるため、8ビット文字で送るのは、避けた方が良いみたい。

  つまりセキュリティー的に向上させた上に、7ビット文字制限を解消させる
役目があるという。

  調べていくと、@ITのページで、次のような事実を発見した。
  公開と隠ぺいのジレンマ「SMTP〜後編」

  すでに、EHLOコマンドは必須！

  でも、思った。
  最初の方でメールコマンドを使った実験で、EHLOコマンドが必須なら、
HELOコマンドを使えなくしても、おかしくはないはず。
  でも、問題なくHELOコマンドが使えている。
  そこで、詳しく知るために、RFC2821を読んでみる事にした。

   A client SMTP SHOULD start an SMTP session by issuing the EHLO
   command.  If the SMTP server supports the SMTP service extensions it
   will give a successful response, a failure response, or an error
   response.  If the SMTP server, in violation of this specification,
   does not support any SMTP service extensions it will generate an
   error response.  Older client SMTP systems MAY, as discussed above,
   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
   support the HELO command and reply properly to it.  In any event, a
   client MUST issue HELO or EHLO before starting a mail transaction.

  RFC2821を読んで、納得した。
  それにしても日本語訳がないので、読むのが面倒くさい。
  でも、考え方を変えたら、英語なだけマシかもしれない。
  これが、ドイツ語やフランス語だったら辞書すら調べる気が起こらないからだ。

Postfixの各種デーモン

  ふぅ、これで、Postfix関係を、一通り調べたと書きたい所だが、
実は、もう一つ設定ファイルがある。master.cfファイルだ。
  編集している時、わざと取り上げないで逃げようと考えたのだが、
100%、突っ込みが来るのが予想されるので、軽く取り上げる事にした。

  この設定ファイルは、Postfixの各種デーモンを起動させるための
設定ファイルだという。

  Postfixは、sendmailと違って、メールの配信など複数のデーモンの連携で
動かしている。
  偶然、メールの送受信をしている最中のプロセスを得る事ができた。

[server]# ps aux | grep postfix
postfix  26689  0.0  0.4  2452  928 ?        S    Jun23   0:05 nqmgr -l -n qmgr 
postfix   3289  0.0  0.4  2308  836 ?        S    16:37   0:00 pickup -l -t fifo
postfix   3451  0.0  0.4  2308  840 ?        S    16:57   0:00 proxymap -t unix 
postfix   3457  0.0  0.5  2548 1116 ?        S    16:57   0:00 trivial-rewrite -
postfix   3508  0.0  0.6  2616 1248 ?        S    17:00   0:00 smtpd -n smtp -t 
postfix   3546  0.0  0.6  2616 1236 ?        S    17:04   0:00 smtpd -n smtp -t 
postfix   3547  0.0  0.5  2384  960 ?        S    17:04   0:00 cleanup -z -t uni
postfix   3548  0.0  0.5  2508 1128 ?        S    17:04   0:00 local -t unix

  メールの送受信の最中のためか、「デーモンの合唱」になっている。
  普段は、こんなにデーモンが出ていない。

  ここで注目すべき点は、Postfixの場合、デーモンは管理者権限ではなく、
Postfixというユーザー名の権限で動いている事だ。
  これはセキュリティーの問題につながってくる。
  よく、sendmailはセキュリティー的に問題があると言われるのは、
全ての作業を一つのデーモンで行なうため、1カ所でもセキュリティーホールが
存在すると、乗っ取られる可能性がある上、管理者権限で動いているため
乗っ取られると、好き放題される危険性がある。

  しかし、Postfixのデーモンの1つにセキュリティーホールがあったとしても、
Postfix全体が乗っ取られるわけでない上、管理者権限で動いていないので、
すぐに好き放題される心配はないという。


  さて、デーモンは複数ある事がわかったが、一体、どんな働きをしているのか
見てみたくなるのが人間の好奇心。
  そこで、調べてみると、次の事がわかった。

Postfixで登場するデーモンと、その働きについて
（相当、大雑把に描きました）
smtpd	外部からやってきたメールを受け取り、cleanupへ渡す
pickup	ローカルから発信したメールを受け取り、cleanupへ渡す
cleanup	smtpdやpickupから受け取ったメールを、incomingという箱に入れる
qmgr/nqmgr	incomingに入ったメールを、activeという箱に移して、配信準備を行なう。 配信できなかったメールは、deferredの箱へ置く。 qmgrとnqmgrとでは違いがあるが、それは後述しています。
smtp	外部へメールを送信する時に働く
local	ローカルのメールボックスに配信する時に働く
postmaster	上に挙げたデーモン全体を制御するための調整役(?)として働く

  相当、大雑把な概略図なので、正確性に欠ける所は否めないが、
これで、一応、デーモンの働きは、把握したと思う (^^;;

  ここでは、incoming、active、deferredの事を『箱』と書いたけど、
正確には「キュー」と言う。
  キューとは何か。そう聞かれると・・・

  私も、わかりませーん (^^)

  なのだ！  ←　自慢して、どーする！

  「キュー」とは、正ちゃんと仲良しの、オバケの事である ←　そりゃ、オバQ
  「キュー」とは、マラソン選手である ←　そりゃ、Qちゃん（高橋尚子選手）

  くだらんオヤジギャグは、これくらいにして、辞書で調べる事にした。
  英語のスペルは「queue」なので、英和辞典で調べてみた。
  すると、名詞では「弁髪」、「おさげ（頭）」、「（順番を待つ）列」で、
動詞では「列をつくる」の意味がある。

  なんと、「キュー」は、おさげの女の子の意味があったのだ！！
  おさげの女の子といえば、「らんま1/2」で出てくる主人公・早乙女乱馬の
女バージョンをイメージしてしまう。
  他には、「天空の城・ラピュタ」のヒロインのシータが出てくる。

  
  おっとっと。話が脱線してしまったので、まともな方向に戻すと、
  「キュー」とは「メールを保管する場所」を意味するという。
  「（メールの順番の）列」から、「列」を置く場所になったと思う。
  つまり「箱」という表現は間違いではなかった (^^;;


  さて、メールデーモンの働きを知ると、メールのログを見るのが楽しくなる。

Jul 12 00:10:30 kkkk postfix/smtpd[23666]: 
                connect from cc.aa.xxxx.ne.jp[AAA.BBB.CCC.DDD]
cc.aa.xxxx.ne.jpから、接続される

Jul 12 00:10:30 kkkk postfix/smtpd[23666]: 3CD72138E2: 
                client=cc.aa.xxxx.ne.jp[AAA.BBB.CCC.DDD]
cc.aa.xxxx.ne.jpから来たメールを受け取る。

Jul 12 00:10:30 kkkk postfix/cleanup[23668]: 3CD72138E2: 
                message-id=<000701c46758$f045b660$3d9b8bd2@oemcomputer>
外部から来たメールを、incomingへ送る。

Jul 12 00:10:30 kkkk postfix/nqmgr[20452]: 3CD72138E2: 
                from=<aaaa@fff.ggg.ne.jp>, size=1156, nrcpt=1 
                (queue active)
activeにメールが送り込まれる

Jul 12 00:10:30 kkkk postfix/smtpd[23666]: disconnect 
                from cc.aa.xxxx.ne.jp[AAA.BBB.CCC.DDD]
cc.aa.xxxx.ne.jpからの接続が切れる。

Jul 12 00:10:30 kkkk postfix/local[23671]: 3CD72138E2: 
                to=<aaaaa@xxxxx.co.jp>, relay=local, delay=0, 
                status=sent (mailbox)
メールは、ローカル内のメールボックスに保管される

  一連の流れが見えてくる感じがする。
  今まで、ログを、こんな風に見た事がないので、やってきたメールの
振る舞いが見えて楽しくなる。

  とこで、これらのデーモンの設定は、master.cfファイルで行なう。

# ==========================================================================
# service type	private	unpriv	chroot	wakeup	maxproc	command + args
# 		(yes)	(yes)	(yes)	(never)	(50)
# ==========================================================================
smtp	inet	n	-	y	-	-	smtpd
#smtps	  inet	n	-	n	-	-	smtpd
#  -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission	inet	n	-	n	-	-	smtpd
#  -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628	  inet	n	-	n	-	-	qmqpd
pickup	fifo	n	-	y	60	1	pickup
cleanup	unix	n	-	y	-	0	cleanup
#qmgr	  fifo	n	-	n	300	1	qmgr
qmgr	fifo	n	-	y	300	1	nqmgr
#tlsmgr	  fifo	-	-	n	300	1	tlsmgr
rewrite	unix	-	-	y	-	-	trivial-rewrite
bounce	unix	-	-	y	-	0	bounce
defer	unix	-	-	y	-	0	bounce
flush	unix	n	-	y	1000?	0	flush
smtp	unix	-	-	y	-	-	smtp
showq	unix	n	-	y	-	-	showq
error	unix	-	-	y	-	-	error
local	  unix	-	n	n	-	-	local
virtual	unix	-	n	y	-	-	virtual
lmtp	unix	-	-	y	-	-	lmtp
#
# Interfaces to non-Postfix software. Be sure to examine the manual
 pages of the non-Postfix software to find out what options it wants.
# The Cyrus deliver program has changed incompatibly.
#
cyrus	  unix	-	n	n	-	-	pipe
  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
uucp	  unix	-	n	n	-	-	pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail.postfix ($recipient)
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
relay	  unix	-	-	n	-	-	smtp
proxymap  unix        -       -       n       -       -       proxymap

  この部分で、デーモンの設定を行なう事ができる。
  しかし、最適化(チューニング)や特殊な設定を行なう以外は、触らない方が無難みたいだ。

  ここで、変更をすると言えば、一つめは、qmgrとnqmgrの交換だ。
  この2つの違いを説明すると、次のようになる。

  さて、上の設定を見れば、nqmgrが動いているので、問題なしと思った。

  その次に設定を行なうといえば、chrootの設定だ。

  chrootって何？

  だった (^^;;;;;;;;

  この概念は、別の例だと、ftpに使われる。
  ftpでログインした人に対して、ログインしたディレクトリーが、
ルートディレクトリーになるように設定して、ログインしたディレクトリー以外の
ディレクトリーへ移動できないようにして、セキュリティーを高める役目がある。

  Postfixの場合、デーモンが乗っ取られても、必要以外のディレクトリーへ
侵入できないようにするための設定だという。

  RedHatの場合、初期設定で、chrootの設定はされているという。

  それ以外にも、同時稼働プロセス数の最大値を変更したりするのがあるが、
中小企業には必要ないので、手を出さない事にした。
  要するに、面倒くさいから、手を出さない事を意味する (^^;;;


  さて、メールのキューが出てきた所で、キュー管理のコマンドがある事を知る。
  キュー管理とは、オバケのQ太郎の管理をするのではなく、
メールのキューの状況を見たり、操作したりするコマンドだ。

  一般ユーザーが使えるのは、mailqコマンドがある。
  これを使うと、キューの状態を表示できる。

[server]# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
9D7E8138E2      320 Wed Jun 30 11:18:19  suga@xxxx.co.jp
      (connect to kkkk.xxxx.co.jp[XXX.YYY.ZZZ.RRR]: Connection refused)
                                         aaaa@dummy.xxxx.co.jp

-- 0 Kbytes in 1 Request.

  他にもあるのだが、私は使わないので、これぐらいにします。


  Postfixの管理者用の管理コマンドとして、postsuperコマンドがある。
  これを使うと、送信できずに溜まっているメールを削除したり、凍結したりする事が
可能になる。

  postsuper -d キューIDをすれば、該当のキューIDのメールが削除できる。
  postsuper -h キューIDをすれば、該当のキューIDのメールが凍結できる。

  「へぇ〜」と思った。
  しかし、使い道がないので、深くは調べる事はしなかった。
  「キチンと調べろ！」という声には、次のような反論をします。

  だって、そこまで高度な事はしないもーん (^^)

  事務員は、そんなに高度な事はできないのである。
  そこで、軽く触れた程度で、さっさと逃げるのである (^^)

Windowsの無償のメールサーバーソフト

  「Linux + Postfix は、わかりやすい」と思っていたら、競合ソフトがある事に発見した。

  それは、Windows + ArGoSoft Mail Serverだ！！

  ArGoSoft Mail Serve とは、無償のメールサーバーだ。
  現在、Windows95/98/NT/2000 に対応している。
  http://www.argosoft.com/からダウンロードできる。

  なぜ、それを競合と思った理由だが、設定が手軽だからだ。
  さっそく、実験サーバー（Windows2000Pro）を使って、下のように
メールサーバーを構築してみる事にした。

Windowsでメールサーバー構築

  さて、設定方法は、非常に簡単。

  GUIの設定。マウス操作で設定できるので、簡単にできる。
  ここが、Windowsの恐い所でもある。マウス操作で設定できるので、
Windowsは簡単だという誤解に陥りやすい。
  私の場合、この設定を行なう前に、散々、Postfixで七転八倒したため、
免疫ができ、簡単そうに感じたが、全くメールの知識がない人にとっては、
この設定でも難しいと思う。

ArGoSoft Mail Server の設定方法

  次に、メールアドレスのドメイン（「@」マークよりも左側の部分）を
記入する。（上図を参照）

ArGoSoft Mail Server の設定方法

  次に、SMTP認証の設定を行なう画面がある。
  ちなみに、POP Before SMTPの設定があるが、無償版は使えない。
  Linuxでは今回、諦めたSMTP認証が簡単にできる！！
  もちろん、この設定を行ない、上の方で紹介したクライアント側の設定を
行なった。先に結果を出すが、実験は成功した。

ArGoSoft Mail Server の設定方法

  次にユーザー登録。
  Windows2000Proだと、OSの方でユーザー登録を行なっているが、
私が設定を行なった限りでは、OSでのユーザーと、このメールサーバーに登録する
ユーザーは独立した物の感じがする。
  ただし、確証がありませんので、鵜呑みにしないでくださいね (^^;;

ArGoSoft Mail Server の設定方法 ユーザー登録の画面

  これで簡単に、メールサーバーが構築できてしまう。

  試しに、OutlookExpressを使って、メールの送受信を行なった所、問題なく使えた。
  小規模なサーバーだと、これは使えると思った。

  感心したのは、不要のメールコマンドが使えない事。
  VRFYコマンドを使うと、「そんなコマンドは知らん」というエラーが出た。
  安全性に関して、対応しているソフトだと感心した。


  今回、Windows2000Proで実験を行なったのだが、実は、問題がある。
それはOSのライセンスの問題があるからだ。
  実は、WindowsのクライアントOSを使った、サーバー利用には制限がある。
Windows9X系は制限はないが、WindowsNTのクライアント版はサーバー利用禁止だ。
  Windows2000Pro、WindowsXPは、グレーゾーンになっている。

  ライセンスを見るため、EULAを読もうとするが、禅問答のような感じで
わかったような、わからんような書き方で、理解が困難だ。
  ただ、言えるのは、デフォルトで付いているソフトの場合、
Windows2000Proなら、同時アクセスが10までならOKだという。
  しかし、サーバー利用については明確に「禁止」が書いていないため、
思わず、使ってしまう可能性がある。

  私の場合、実験が終わったら、すぐに利用を止めた。
  こんな事で、ライセンス違反と言われは困るからだ。

  揚げ足取りで、罰金をせしめる悪どいMSのライセンスには困ったものだと思う。

  まぁ、個人利用の場合だと、MSも目くじらを立てないかもしれないが、
法人が使う場合は、ライセンス違反に問われる可能性があるかもしれないので、
クライアントOSを使ったサーバー利用は、気をつけた方が良いかもしれない。


  話は元に戻して、ArGoSoft Mail Serve は、なかなかの出来だ。

  でも、できない事もある。メールゲートウェイの構築はできない。
  そこまでの機能がないからだ。有償版ならできるかもしれないが、
使った事がないので、コメントする事ができない。
  しかし、メールゲートウェイなんど、使う機会は少ないと思う。

  ところで、デフォルトで付いているIISで、メールサーバーを構築しようとは
思わないが、このソフトだと、手っ取り早いメールサーバーとして使えると思う。

  私は、Linuxを推進している立場だが、ライバルの出現に対して、
歓迎している。良い意味での競争をして欲しいと思うからだ。

(2006/10/25 に追加)

  2003年に、メールサーバーにsendmailを消さずに、Postfixを入れたのだが、
2006年10月に「sendmailなんて不要だから消してしまえ」と思って
rpm -e sendmail で、sendmailを消した。

  すると・・・

  メールの配信ができへんようになった （ＴＴ）

  だった。
  原因を見るため、メールのログを見たら、以下のログがあった。

Oct 25 10:02:38 server postfix/smtpd[17270]: fatal: open database /etc/aliases.db: No such file or directory
Oct 25 10:02:39 server postfix/master[10220]: warning: process /usr/libexec/postfix/smtpd pid 17270 exit status 1
Oct 25 10:02:39 server postfix/master[10220]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling
Oct 25 10:03:39 server postfix/smtpd[17271]: fatal: open database /etc/aliases.db: No such file or directory
Oct 25 10:03:40 server postfix/master[10220]: warning: process /usr/libexec/postfix/smtpd pid 17271 exit status 1
Oct 25 10:03:40 server postfix/master[10220]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling

  sendmailがインストールされた際に、置かれたファイル /etc/aliases.db が
Postfixでも使われているようだ。

  そこで、慌てて sendmail を RPMで入れて、そして、ソースコンパイルで
Postfixを入れ直したら、障害が解消した。

最後に

  Postfixの導入をキッカケに、メールについて知らなかった事が噴出。
  できる限り、知らない部分を潰していく事にしました。

  sendmailは、設定ファイルが呪文で難しいのですが、Postfixは、わかりやすいです。
  わかりやすいお陰で、今回の奮闘記を書く事ができました。
  sendmailだと、私の3段腹より分厚い本を読む必要が出てくるので、
100%、読破する前に、討ち死にしているのは間違いなかったでしょう。

  qmailに関しては、今回、触る機会がなかったので、何も言えません (^^;;

   編集している間も、知らない事がゴロゴロ出てきて、
「今まで、よっぽどメールの話を知らなかったなぁ」と思わず感心してしまいました。

  メールの仕組みや、メールセキュリティーの話など、まだまだ知らない話が
多いだけに、奥の深さを実感しています。
  機会を見つけては、色々な使い方に挑戦したいなぁと思っています。