More from: sendmail

sendmailが止まってた?

仕事場に着いたら
「メールの送信が出来ない」
との連絡があった。
調べてみると職場内のメール配送を行っているサーバーが他のホストからの接続を拒否していたらしい(サーバー内の配送は出来ていた)。
良く解らないけど、こんな時は配送システム(ウチの場合はsendmail)を再起動。
すると直後からPCからの送信要求が来て無事に配信されたので動作確認が出来た。
他のサーバーも
#sendmail -bp
で確認すると夜の間にキューが溜まっていたので
#sendmail -q
で強制的に配送させて一応対応終了。
今回、配送をさぼっていたサーバーはたまにこのようなことがあるので、crontabかなにかで年に一回くらい強制的にsendmailの再起動をさせたほうが良いかも?

←クリックしてくれると嬉しいです。

サーバ間のメール転送が上手くいかない・・・

メールサーバの移行に伴い、新旧サーバ間でのメールの転送が必要になった。
具体的には新サーバの特定ユーザー宛のメールを旧サーバに転送することになる。
そこで該当ユーザーの”.forward”ファイルに転送先の旧サーバのアドレスを書いたのだけど、
「sendmail deferred connection refused by XXX」(XXXは送信先、要は旧サーバ名)
のエラーとなり送信出来ない。
それもその筈、旧サーバは当初外部からのsmtp接続を受け付ける必要が無かったので、”sendmail.cf”の
「O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA」
という項目がデフォルトのままだったために、外部からのsmtp接続を拒否していた。
ここにもう一行
「O DaemonPortOptions=Port=smtp,Addr=aaa.bbb.ccc.ddd, Name=MTA」(aaa.bbb.ccc.dddは自サーバの実際のIPアドレス)
という行を追加し、sendmailを再起動することで回避出来た。
ところがその後も新サーバ側からメールを送ると、
”553 5.3.5 system config error”
とか
”553 5.3.5 xxx.yyy.zzz. config error: mail loops back to me (MX problem?)”
というエラーが出てやはり送信出来ない(汗)。
これらのエラーは”/etc/mail/local-host-names”ファイルに関係する全てのサーバ名(ホスト名、ホスト名+ドメイン名)を追加で記述しsendmailを再起動することで解消出来た。
また
”Relaying denied”
も出ていたので、これは”/etc/mail/access”ファイルにリレーを受け付けるホスト(要は新サーバ)のIPアドレス+”RELAY”を記述し、makeし直すことで解決した。

上記の設定変更でようやく新サーバから旧サーバへのメールの転送が可能になったので、ようやく落ち着いたよ(汗)。

←クリックしてくれると嬉しいです。

早朝から・・・

昨夜は早くに寝てしまったので今朝は早起き。
は良かったんだけど、そんな時に限ってユーザーからSOSのコール。
いつもならそろそろ起きようかという時間だったけど、今日は早起きしていたので受けたところ、「メールの受信が出来ない」とのこと。
急いで身支度をして職場に駆けつけ問題のメールサーバーをチェックすると/var/の下が満杯orz
すぐに古いログ等を消してディスクを空けて受信は可能になった。
さらに調べると全く使われていないアカウント向けへのメールが大量に残っていることが判明したのでそれも削除。
そのアカウントに配信されるように設定してあるaliasもアカウント自体も削除したので、しばらくは大丈夫な筈。

他のサーバーからの受信も拒否していたので、問題のサーバーに向けてメールを送ろうとしていた他サーバーにはqueueが溜まっていた。
それら溜まっていたqueueを吐き出したところ自分のクライアントで受信が出来たので対応は完了。
sendmailで溜まっているqueueを強制的に吐き出すには
#sendmail -q
でOK。
溜まっているかをチェックするには
#sendmail -bp
を実行し、
Mail queue is empty
と出ればqueueは溜まっていない。
逆に
Mail Queue (1 request)
–Q-ID– –Size– —–Q-Time—– ————Sender/Recipient————
xxxxxxxx 9999999 ”曜日” ”月” ”日” ”時刻” <”送信者”/”送信先”>
のように表示されれば残っているということ。

←クリックしてくれると嬉しいです。

←クリックしてくれると嬉しいです。

負荷が高くてmailが配信されない・・・・・・・・

職場のmailサーバに外からのmailが届いていないが何かあったのか?
という問い合わせがあった。
調べてみるとサーバの負荷が高くてsendmailが配信をストップしていた模様・・・・・・・

sendmailはデフォルトでシステム負荷(Load Average)の数値が12を超えると接続を拒否する仕様になっている。
これは外部からのmailbombによる攻撃でシステムが止まる事を防ぐためで、この数値の設定はsendmailの設定ファイルであるsendmail.cfで変更可能だ。
sendmail.cf内に
# load average at which we refuse connections
#O RefuseLA=12
という行があるので、2行目の行頭の#を外して行末の数字を書き換えて保存し、sendmailのプロセスを再起動するか、kill -HUP ”sendmailのプロセス”で初期化すればOK。
sendmailのプロセスNoは
ps ax | grep sendmail
とでもすれば判る。

それにしても今まで負荷が高くて配信が止まる事は殆ど無かったのに今日になって起きるなんて不思議だ・・・・・
もしかして攻撃されているのか?(笑)
#直接外部に晒していないから大丈夫だとは思う。

←クリックしてくれると嬉しいです。

またまたsendmailの設定を見直した

2008年11月18日の記事「sendmail」ではsendmailにDNSサーバを参照させない方法を書いた。
たまたま別のサーバのメンテをしていて、root宛のメールが大量に滞留していたので見てみると宛先のサーバ名が引けないで送信できずに残っているものだった。
しかもこのサーバではsendmailを始めとするMTAが動作しておらず、メールを出そうとしても送信queueに溜るだけだったorz

そこで送信先のサーバ名を/etc/hostsファイルに追加して(ローカル環境なのでhostsファイルに書けば十分)、MTAとなるsendmailにDNSサーバを参照させないように
hosts files
の一行だけを書いた
/etc/service.switch
ファイルを準備し、sendmail.cf内の
#O ServiceSwitchFile=/etc/service.switch
の行頭の”#”を削除(コメントアウトを外)して有効化し、sendmailを再起動した。
これで件のサーバが出力するメールは無事に目的のサーバに届くようになった筈だったが、最初は正しく設定したはずが何故かきちんと配送されずに「???」だった。
そこでsendmail.cfを見直すとservice.switchファイルの場所を間違って記述していた。
再度sendmail.cfを修正してsendmailを再起動したところ無事に届くようになった。

←クリックしてくれると嬉しいです。

vacationが動かないぃーーーーーー!!!

職場のメールサーバにvacationプログラムを入れたが、いくら試しても自動返信がされない。
maillogを見ると
“attempt to use “vacation -r 0 hoge” (stat failed)”
と出ている。
デーモンから来たメールには
“smrsh: “vacation” not available for sendmail programs (stat failed)”
となっているので、これをヒントに調べたら”smrsh”で動作を許可するプログラムを置いておくディレクトリにvacationプログラムが入っていなかったのでsmrshがファイルを見つけられなかったためと判明した(このため”stat failed”が出ている)。

職場で使っているサーバではsmrshで動作を許可するディレクトリは
/etc/smrsh
だったので、そこにvacationを置いたところ無事に動作した。
実際はvacationプログラムの本体をそこに入れるのも何なので、
ln -s /usr/sbin/vacation /etc/smrsh/vacation
でシンボリックリンクを張った。

プログラムを入れるディレクトリは環境によって異なるみたいで、
/usr/adm/sm.bin (smrshのソースに付いてくるREADMEファイルに書かれているのはここ)
/usr/libexec/sm.bin (man smrshに書かれているディレクトリはここ)
とかがあるみたいだ。
今回は
#man smrsh
で出てくるのと違うディレクトリだったので見つけるまで時間がかかったよー!

←クリックしてくれると嬉しいです。

メモ:aliasのチェック

sendmailでaliasを使用している場合の設定のチェック方法のメモ。
#sendmail -bv alias名
これを実行すると指定したalias名がどのように展開されるかが分かる(-bvはベリファイモードの指定)。
aliasesファイル内に記述してあっても、上記コマンドで出て来ない場合は
#newaliases
でエイリアスデータベースを作り直してみる。

←クリックしてくれると嬉しいです。

SPAM

SPAMと言えばポークランチョンミートの缶詰の商品名の一つ。
自分的にはTULIPのほうが好みだなぁ。

ってな話ではなく、日本語で言うところの「迷惑メール」の話。
職場で受信するSPAMが5000通/日にもなるというので、ブロックするためのアドレス収集を再開した。
2週間程ほぼ毎日受信メールから送信元アドレスを抜き出して/etc/mail/accessに追加する作業をした結果、5000通→1500通程に減少した。
これはsendmailの場合の対処法で、qmail等他のMTAでは別の方法となる。
実際のアドレス収集は自動で行い、その中から受信が必要なアドレスを例外アドレスとして別途収集し、残りを上記のファイルに追加している。
/bin/grep ^From: ”メールスプールファイル名” | /bin/grep @ | /bin/sed “s/^From:.*</From:/” | /bin/sed “s/>//” | /bin/sed “s/ //g” | /bin/sed “s/(.*)//” | /bin/sed “s/$/ DROP/” | /bin/sort | /usr/bin/uniq | /bin/grep -v -f ”例外アドレスを列記したファイルを指定”
上記のようなスクリプトを組んで自動収集をしている。泥臭いやり方だがこれでもアドレスの収集が出来ていて、実際に効果があがっている。
このスクリプトでやっているのは、
1.受信したメールが入っているスプールファイルから送信者のメールアドレス(From行)を切り出す。
2.余分な単語を削除(sedコマンドの繰り返し)した後に行末に”DROP”の文字列を追加。
3.アルファベット順への並び直し(sortコマンドの実行)。
4.同一のアドレスがある場合は一つのみ切り出す(uniqコマンドの実行)。
5.例外アドレスを列記したファイル中にあるアドレスを”grep -v -f”で除去。
これで得られた文字列(”From:hogehoge@geshogesho.com DROP”)をファイルに書き出し新たに例外に追加するアドレスが無いかをチェックした後に/etc/mail/accessファイルに追加してmakeを実行してaccess.dbに反映している。
行の最後を”REJECT”ではなく”DROP”にしているのは余計なトラフィックを発生させないため。
また、たとえREJECTでエラーメールを送り返そうとしても、返す先のアドレスが実在するかどうかが不明で、もしも実在しないアドレスだった場合(むしろそのほうが可能性が高い)にエラーメールが返って来るのを防ぐため。
それにしても相変わらず迷惑メールが多いなぁ。法律が制定されてから初めて適用されたのがつい最近っていうもどうかと思う。
受信者の同意無しに無差別に送るメールにはSubjectに「未承諾広告」と入れなくてはならない筈なのに、最近はそのようなメールを見かけない。
一見まともな内容に見えるメールでも、このような基本的なルールが守られていない。もっと取締りを強化して貰いたいものだ。

←クリックしてくれると嬉しいです。

sendmail

久しぶりにメールサーバの設定の見直しをした。というのも詳細は書けないが、元々ローカルのみで配送していたサーバを外部と接続したせいで、見直しが必要となったからだ。
配送自体はローカルネットワークのみで行いたいので、外部への転送は必要無い(というか配送されると困る)。
最初は送信先のホストを限定しようとしたが、上手い方法が見つからない。
sendmail.cfの記述で可能だとは思うが、どのサイトを見ても直接sendmail.cfを編集するのではなく、CFもしくはm4を使っている。
私も最初だけはm4を使った覚えがあるが、その後は直接sendmail.cfを編集している。おかげでCFやm4の設定ファイルの書き方を忘れてしまった。
さらに直接編集しているので元となった設定ファイルは古すぎて今となっては使えない。
まぁいろいろ調べているうちにsendmailにDNSを使わせない手段を発見した。これを最初から知っていれば苦労してネームサーバなんぞを立てる必要無かったのに。
他のサーバからの名前解決要求が来るのでnamed自体を止めることは出来ないが、sendmailがDNSを使わなくなれば、配送先のMXレコードを引くことも出来なくなって、結果的に外部への配送が失敗することになりそうだ。
実際に/etc/service.switchを作成して試してみると、ローカルの配送は今までどおりに行き、外部への配送は失敗した。
これでこのサーバを使っての外部へのメール送信は出来なくなった。今日はこれに半日かけてしまった、、、、

BGM:最強○×計画、切情!佰火繚乱、妄想ブレイク    って、いったい・・・・・・

←クリックしてくれると嬉しいです。