メールが送信できない

僕のサーバーは、mydnsを利用してダイナミックDNSによって公開しているが、プロバイダがOP25B対策をしているため、外部にメールを送信するためにはSubmission Portを利用しなければならない。
mydnsではIPアドレスを定期的に更新している送信元からSubmission Portによるメールリレーサービスがあるので、これを利用させてもらっている。
今日メールを送ろうとしたところ、なぜかメールが送れなかったため、/var/log/maillogを確認して原因を調査したところ
Dec 24 04:28:53 (ホスト名) postfix/qmgr[2240]: 17F8AFC03: to=<(送信元)>, relay=none, delay=16802, delays=16802/0.21/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to auth.gate-on.net[210.197.72.170]: Connection timed out)
というログが出ていることが確認できた。auth.gate-on.netはpingが通ることから、どうやらメールリレーサーバーから接続を拒否されているようだ。
もっと前のログを確認したところ
Dec 23 04:02:39 (ホスト名) postfix/smtp[29536]: 03866F775: to=<(送信元)>, relay=auth.gate-on.net[210.197.72.170]:587, delay=25031, delays=24999/28/0.09/5, dsn=4.0.0, status=deferred (host auth.gate-on.net[210.197.72.170] said: 450 Error: too much mail from 122.20.52.249 (in reply to MAIL FROM command))
というエラーログが確認できた。どうやらメールを送りすぎているらしい。
たしかにmaillogを確認したところログサイズがかなり大きい状態であったため、もしかして不正中継しているのかと思い、RBL.JPによる不正中継テストを実施したところ特に不正中継はできない状態を確認した。
となるとなぜそんな大量のメールを送る必要があるのか・・・・詳しく調べてみたところ管理ドメインではあるが受信を予期していないサブドメインあてのメール(xxx@yyy.development-network.net)が大量に送られており、それが原因でエラーメッセージを大量に送信元に返しているためということがわかった。
確かにダイナミックDNSを利用していると、 development-network.net のMXレコードも yyy.development-network.net のMXレコードも存在するように見えてしまう。実際には、yyy.development-network.netドメインはメール受信できるような設定になっていないので、こんなことが起こってしまうのだ。
これを回避するためには、自サーバーにDNSを立てて、/etc/resolv.confに nameserver 127.0.0.1 を設定する。その上で、development-network.netドメインのみMXレコードを設定し、メールサーバーあてに来たメールの宛先がMXレコードに存在しなければメールを拒否するようにすればよい。また、合わせて送信元のメールアドレスが正しくない(MXレコードが引けない)場合も合わせて拒否するようにした。
そこで、postfixに以下の設定をした。
smtpd_sender_restrictions=
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

smtpd_sender_restrictions=reject_unknown_sender_domain
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,reject_unknown_recipient_domain
ここで設定パラメータの意味をおさらいしてみたい。

reject_unknown_sender_domain MAIL FROM アドレスに DNS A または MX レコードがなく、Postfix がその送信者アドレスの最終配送先ではない場合に、要求を拒否します。
reject_unknown_recipient_domain RCPT TO アドレスに DNS A または MX レコードがなく、Postfix がその受信者アドレスの最終配送先ではない場合に、要求を拒否します。

この設定をすることによって
Dec 31 22:16:05 (サーバー名) postfix/smtpd[24930]: NOQUEUE: reject: RCPT from adsl-ull-139-91.47-151.net24.it[151.47.91.139]: 450 4.1.2 <(送信先)>: Recipient address rejected: Domain not found; from=<(送信元)> to=<(送信先)> proto=ESMTP helo=
というログが記録されるようになり、正しく拒否することによって不用意にリレーさせないようになっていることを確認できた。
この設定の後、Bフレッツを再接続してWAN側のIPアドレスを変更し、mydnsに新しいIPアドレスを通知することで正しく通信できるようになった。
最後になりましたが、mydnsさんへはこの件で大変ご迷惑をおかけしました。この場を借りてお詫びいたします。

フレームワークのあれこれ

Mojavi

非常に古いフレームワーク。これだけではMVCの概念を提供するだけで、機能は自分自身で組み合わせなければならない。ある意味自由度は高いかもしれない。→テンプレートのSmartyとか・・・

Ethna

GREEが使っているとされるフレームワーク。(2006年記述)

Symfony

僕が取り組んでいるフレームワーク。導入実績はこちらで紹介されている。PHP5以上で動作する。使ってみたところ、制約が大きく、やりたいことをするためにまずどうしなければいけないかを調べなければならないため、ハードルがやや高い。あんじーの奮闘記はこちらからどうぞ。

Zend Framework

まだ完成度は低いもののデファクトスタンダードと期待されている。参考:公式サイト IT Pro

その他ではこんなものもあります・・・
cake
prado
Django

Postfixにスパムメールフィルターを入れる

Webサイトを公開していると公開ドメインの特定のアカウントに対してスパムメールが送られてくることも珍しくなく、僕の場合には、1日当たり200通くらいスパムメールが来る。そこで、spamassasinというソフトウエアを組み込むことで簡単にスパムメールフィルターを実装することができたので紹介する。
ちなみにインストールにあたってLinuxで自宅サーバーさんのサイトが役に立った。動作する概要を知るにはとても役に立つのでご一読いただきたい。また以下のインストール手順も多くは参考に記載しているものであることをお断りしておく。
Fedora Core 6上にPostfixが稼働している環境にspamassasinを以下の手順でインストールした。
1.yum install spamassasin コマンドを実行するとspamassasin以外にperlモジュールをたくさん入れる必要があることが分かるので、yを押す。
2.rpm -qi procmail を実行し、procmailコマンドがあることを確認する。ただし、設定ファイルである/etc/procmailrc がないため、 vi /etc/procmailrc として以下を記述する。

# パスを設定
PATH=/bin:/usr/bin:/usr/local/bin
# メールボックスの設定
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
# Procmailのログファイル出力先を指定
LOGFILE=$MAILDIR/procmaillog
# ロックファイルのパスを指定
LOCKFILE=$HOME/.lockmail
# メールヘッダー中に「 X-Spam-*** 」の記述がなければ spamassassin を起動します
:0fw
*!^X-Spam.*
|spamassassin
# メールヘッダー中に「 X-Spam-Status: Yes 」の記述があれば、「 .Spam 」ディレクトリにメールを格納します(ただし、POPサーバーで受信しているケースがある場合には、この設定をするとスパム扱いされたメールが確認メールソフトからできないので注意)
:0
* ^X-Spam-Status: Yes
$MAILDIR/.Spam/

※.Spamディレクトリは/home/XXX/Maildir以下に作成しなければならないようだが、みている限りでは、上記設定をすることでメールの受信が始まると勝手に作ってくれるようだ。
4.Postfixでメールを受信をした際にprocmailで処理させるために以下の記述を/etc/postfix/main.cf に記述する

mailbox_command = /usr/bin/procmail

5.spamassasinサービスを自動起動させるために以下のコマンドを実行する。
/sbin/chkconfig –level 35 spamassassin on
6.spamassasinサービスの起動&postfixの再起動を行う
/etc/init.d/spamassasin start
/etc/init.d/postfix restart
7.postfixで配送を管理しているドメインあてにメールを送ってヘッダーに以下の情報があることを確認する。

X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on
(サーバー名)
X-Spam-Level:
X-Spam-Status: No, score=0.5 required=5.0 tests=NO_REAL_NAME,NO_RELAYS
autolearn=no version=3.1.9

もしスパムメールを受け取った場合には、.Spamというフォルダに移動され、以下のようなヘッダーが付け加えられる。

X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on
(サーバー名)
X-Spam-Level: ******************
X-Spam-Status: Yes, score=18.2 required=5.0 tests=ALL_TRUSTED,
FORGED_MUA_OUTLOOK,INVALID_MSGID,REPLICA_WATCH,URIBL_JP_SURBL,URIBL_OB_SURBL,
URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=no version=3.1.9
X-Spam-Report:
* -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP
* 2.3 REPLICA_WATCH BODY: Message talks about a replica watch
* 1.1 URIBL_SBL Contains an URL listed in the SBL blocklist
* [URIs: prnewperiod.net]
* 3.4 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
* [URIs: prnewperiod.net]
* 1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
* [URIs: prnewperiod.net]
* 2.6 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
* [URIs: prnewperiod.net]
* 3.6 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
* [URIs: prnewperiod.net]
* 1.7 INVALID_MSGID Message-Id is not valid, according to RFC 2822
* 3.4 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

8.定期的に学習させるためにcronへ登録する。vi /etc/cron.d/spamassasin を実行し、以下のを記述する。

0 1 * * * /usr/bin/sa-learn –spam /home/*/Maildir/.Spam/cur > /dev/null
0 1 * * * /usr/bin/sa-learn –ham /home/*/Maildir/cur > /dev/null

以上で設定完了だ。
なお、.Spamに移動したファイルは通常は読み取りできないので、もしsquirrelmailを使っているようであれば、フォルダメニューで.spamを登録すれば読み取りできるようになる。

ファイルが大量すぎて削除できない場合には

特定のディレクトリにファイルが大量にありすぎてrmコマンドで rm * などとしても
bash: /bin/rm: Argument list too long
と出てしまう場合には、(該当のディレクトリに移動して)
find ./ -exec rm {} \;
と実行し、1ファイルずつに対してrmコマンドを実行するようにすれば削除できる。

Web Application Stress Tool

Microsoftが提供しているフリーのトラフィックジェネレータ。
ブラウザで操作したとおりにトラフィックの設定がされるので、非常に簡単。
ただ、負荷をかける対象のサーバーは設定で簡単に変更できるのに、ポート番号を変更するとなるとリクエスト単位で設定を変更しなければならないというのがおかしな仕様だと個人的に思った。
使い方は、Web Application Stress Tool を使い倒そう!がとても詳しいので参考になると思う。
ちなみに紹介サイトではダウンロード先がリンク切れしてしまっているので、こちらからダウンロードして欲しい。

仕事納まらず

みんな、仕事納めの日記が多いようですが、僕は仕事が納まりませんでした。
お客さんのところに最後に訪問する日が27日で28日は事務作業と掃除をするはずでしたが、27日の夜遅くに帰宅してから体の調子がおかしくなって28日は寝込んでしまう羽目になってしまいました。
ふと気を抜いたのが原因なのかもしれません。今週は月曜日も休みだっただけに最後の最後にダウンしてしまったのはなんともふがいないですね。
日経NETWORKの今月号を見ていたらUSB3.0の記事がありました。USB3.0は速度を上げるためにピン数を増やす一方で、下位互換をサポートするためにインターフェイスが特殊な形になるみたいですね。
まだ仕様は確定しておらず、製品が出るのは2009年ということのようですが、通信速度は5Gbps以上になるようです。(USB2.0は480Mbps)
SDカードも最近32GBとかもうわけが分からない大容量のものが出てきました。多くのUSBディバイスはUSB2.0の通信速度でまったく問題ないわけですが、ストレージ系は、480Mbpsでも遅くなってきているのが事実ですね。
もしUSB3.0ができれば、大容量ストレージも問題なくサポートしていけるので、きっと明るい未来が待っているんでしょう。(32GBも今まで10分くらいかかるところが50秒で転送できるようになりますから)
来年はどんな一年になるんですかね?
とりあえずJ-SOX施行によって仕事の要求レベルがさらにあがることは間違いなさそうです。
今までは個々の頭の中にあればよかった操作などはすべてドキュメントに起こして、誰もがおなじ作業をできるようにしなければなりません。
それは俗人化(その人でなければできない作業)を避け、操作する者によって品質が変わることがないようにする重要なステップだったのかもしれませんが、忙しいとかコストが無駄にかかる等の理由の元で実践されてこなかったわけです。
当たり前を当たり前のようにこなさなければならなくなる世の中はちょっとやりづらくなるかもしれませんね。

sendmailではまる

最近はSMTPサーバーにsendmailを利用せず、いきなりPostfixやqmailに置き換えすることが多いので、なかなかsendmailに触れる機会も減ってきた。とはいってもデフォルトでインストールされているので、そのまま利用しなければならないケースもまれにある。
今回は、sendmailについて無知だったために送信ができなかったケースだ。
たとえば、abc.hogehoge.com というホスト名においては、送信するドメインがデフォルトでは @abc.hogehoge.com になってしまう。ただ、多くの場合、abc.hogehoge.comはMXレコードに登録されておらず、このまま送信しようとしても、多くの送信先では送信元のMXレコードをチェックしていることが多いためはじかれてしまう。
実は、MASQUERADE_ASオプションというのがあり、sendmail.cfにて
MASQUERADE_AS(`hogehoge.com’)
とすれば送信元ドメインを変更することができる。

Javaで日本語をUnicode処理する

Javaの内部エンコードがUnicodeになっているため、日本語を扱うためにはUnicode処理しなければならない。
たとえば、日本語をUnicode処理して出力する場合、以下のようなコマンドになる。
native2ascii application.txt application.properties
-reverseオプションを利用すれば逆にUnicode処理されたものから日本語得られる。
詳しくは、Javaの道を参考にすると良い。