Postfixのエラー

2010/09/02 | メール

Postfixのエラーが出ている。

“warning: do not list domain ドメイン名 in BOTH mydestination and virtual_alias_domains”

このエラーを出さないためにmydestinationをコメントアウトしたのだが・・・。調べてみるとコメントアウトするだけではなくて、以下の設定が必要っぽい。

mydestination =

=の後には何も記述しない設定。一応エラーは出なくなった。

Postfixで書式に基づいてメールを受信する

2010/08/29 | メール

Postfixの設定メモ。現在開発中のシステムにメールを配信する機能がある。このシステムでメールを送信する際に、中にはエラーとなって戻ってくるメールアドレスも含まれているかもしれない。この時、エラーとなるメールアドレスを識別する手法を考えていた。

最初に考えた方法はErrors-toやEnvelope-fromにエラー受信用のメールアドレス(例えばerror@example.com)を設定しておき、エラーとして戻ってきたメールの本文中に含まれるメールアドレスを抽出して、それを処理する方法だ。しかしこの方法だと、メールアドレスの抽出で一苦労しそう。例えばエラーとなるメールアドレス以外に、相手方メールサーバの管理者のメールアドレス等関係のないメールアドレスが含まれている可能性もある。

そこで考えた方法がErrors-toやEnvelope-fromに以下のようなメールアドレスを設定する方法だ。
error_1q2w3e4r@example.com
1q2w3e4rはメールの宛先ごとに一意となるように設定する。つまり宛先メールアドレスごとにErrors-toとEnvelope-fromに個別のメールアドレスを設定してしまうのだ。これで一意となるキーの部分(1q2w3e4r)と宛先メールアドレスをマッピングしたデータを持っていれば、エラーの宛先を確実に取得することができる。

メールを配信するたびに、エラー受信用のメールボックスを作るわけにはいかないので、何らかの設定をしなくてはいけない。一番簡単に考えられる方法はcatch-allだ。catch-allとして特定のメールアドレスを指定しておけば、とにかくすべてのメールを処理することができる。しかしこの場合だと、なんでもかんでも処理してしまうため(存在しないメールアドレスへのスパムメールとか)、処理に負担がかかる。

そこでメールアドレスに正規表現を施して、処理を分岐する手法だ。いろいろ調べてやっと実現する方法を見つけた。

まずPostfixで単独ドメインでとりあえずメールサーバとしては機能しているという前提にたち、main.cfに設定を加える。末尾に以下の行を追加した。

virtual_alias_domains = example.com
virtual_alias_maps = regexp:/etc/postfix/virtual

上記1行目はバーチャルドメインの設定をしているのだが、このとき、main.cfで既に設定されているmydestinationの設定と同じドメインが設定されているとまずいらしい。なのでmydestinationの行はコメントアウトしてみた。

次に上記2行目にある/etc/postfix/virtualというファイルに、以下の1行を追加した。

/bounce_(.*?)@example\.com/     bounce

上記は宛先メールアドレスとしてbounce_で始まり、@example.comで終わるメールアドレスすべてをシステム内のbounceというメールアドレスに送信するための設定だ。つまり何でもかんでも処理するのではなく、bounce_で始まるメールアドレスのみ処理するように設定している訳だ。これにより大半のスパムメールを除外することができる。

そして以下のコマンドを実行する。

postmap /etc/postfix/virtual

その後Postfixを再起動すればOKだ。

意外とこういうのって調べても見つからなかったりする。数時間も費やしてしまった。

n進数に変換

ユーザに一意な値を割り当てたいときがある。将来永劫にわたって同じ値は使いたくない。こんなとき一番便利なのはmicrotime関数でUNIXタイムスタンプ値を少数単位まで算出してやればだいたい問題なさそう。ただ、整数部分だけでも10桁あり、例えば少数第4位まで使用するにしても、合計で14桁の数値(文字列)を使わなければならない。これではちょっと長すぎて使いづらい。

そこで思いついたのだが、各桁で使用する数字が10種類(0、1、2、3・・・)しかないから14桁も必要になるわけで、使用する文字種を増やしてやればもっと小さな桁数で表現することができる。数字は10種類あるので、これにアルファベット26文字を足せば合計36種類になる。つまり10進数を36進数で表現すれば文字列の桁数を減らすことができる。

進数の変換をするための関数が用意されている。base_convert関数だ。

この関数を使って14桁の数値(10進数)を36進数に変換すると9文字の英数字に変換してくれる。5文字のお得となる訳だ。ただし、base_convert関数は、極端に大きな数を対象とする場合は誤差が生じるらしい。おおむね14桁の精度らしいが、OSに依存するようだ。

変換関数を作らなければならないと思っていたけど、とりあえずこれで使うことにする。

JavaScriptベースのWYSIWYGエディタ

2010/08/14 | JavaScript/Ajax

最近はJavaScriptベースのリッチテキストエディタ(Rich Text Editor)が数多く出回っている。HTMLの知識がなくてもウェブページ上でHTMLコンテンツを手軽に生成できるため、とても便利だ。CMSに実装することも多い。しかしどれも一長一短的なところがある。WYSIWYGエディタを調べてみたのでメモしておく。

  • TinyMCE
    http://tinymce.moxiecode.com/
    おそらく現時点で最強のJavaScript WYSIWYGエディタ。世の中のWYSIWYGエディタに実装されている機能は、おそらく全て網羅されているのではないだろうか。カスタマイズにも対応(自作ボタンを用意して自作コマンドを実行することもできる)。jQueryのプラグインとしても動作する。WordPressのエディタとして有名。難点は重いこと。
  • FCKEditor
    http://ckeditor.com/
    今では「CKEditor」と名前が変わっている。FCKEditorのクオリティとインターフェイスを継承している強力なWYSIWYGエディタ。TinyMCEと双璧をなす。
  • WYMeditor
    http://www.wymeditor.org/
    Drupal等のCMSでも採用されいているポピュラーなWYSIWYGエディタ。インターフェイスはやや特殊だが、玄人好み。一般ユーザには使用しにくいかも。
  • nicEdit
    http://nicedit.com/
    軽量のWYSIWYGエディタ。XHTMLに対応。クロスブラウザ対応。
  • jHtmlArea
    http://jhtmlarea.codeplex.com/
    jQueryのプラグインとして動作するWYSIWYGエディタ。 作者曰く「公式にはIE6に対応しない」とのこと。クロスブラウザ対応。
  • jwysiwyg
    http://code.google.com/p/jwysiwyg/
    jQueryのプラグインとして動作するWYSIWYGエディタ。 WYMeditor互換で、機能縮小版。そのかわりに軽量化。
  • markItUp
    http://markitup.jaysalvat.com/home/
    他のエディタと違い、プレビューモードと編集モードが別の場所に表示。一般向けではないように思われる。
  • openwysiwyg
    http://www.openwebware.com/
    XHTML非対応。クロスブラウザ対応だがSafari、Chrome系はNG。

他にもいくつか見つけたが、現状ではこんなところ。

Return-Pathってなんだろう

2010/06/25 | PHPの基本

組み込みのmail関数でReturn-Pathを設定できるということを知らなかったのでメモ。というよりも仕組みを理解していなかったのでメモ。

まずReturn-Pathというヘッダの意味を理解しないといけない。メールソフト等でメールを受信したら生データを確認してみる。そうすると、Return-Pathというヘッダがどこに記述されているかわかるのだが、必ずReturn-Pathヘッダの下にReceivedヘッダの記述があるはずだ。Recivedヘッダは、メールを受信したサーバが順々に付与していくことになるので、複数のメールサーバを経由した場合は、複数のReceivedヘッダがついているはずだ。

Receivedヘッダの記述を見るとわかるが、メール生データの上ほど新しい日時になっているはずだ。つまりメールサーバは、メールを受信するとメール生データの先頭にReceivedヘッダをつけて、次のメールサーバへリレーするようになっている。つまりこれから考えると、Return-PathヘッダはReceivedヘッダが付いた後に付加されたことになる。すなわち、メール作成時にいくらReturn-Pathヘッダ等を指定しても、メールには付与されない。Return-Pathはそもそもサーバが付与するヘッダだからだ。

ではサーバは何を判断して、Return-Pathを設定するのか。

まず根本的なことから考えなくてはいけない。メールには通常作成時にヘッダが付与される。Fromが差出人で、Toが宛先だということは半ば常識的になっている。が、実は本当はそうではない(らしい)。Fromについては御存知の通りで偽装ができるのは有名だ。スパムメールなんてのはFromはたいてい偽装だからだ。しかしToも偽装できる。これがエンベロープアドレスというものだ。

telnetで接続してメールを送信することを考える。この場合、まず差出人と宛先を指定する。しかしこの状態でヘッダを何も指定しないと、subjectもFromもToもないメールが実際に送信される。そもそもメールのヘッダに記載されているFromやToと、実際の差出人や宛先は別個のものなのだ(後者がエンベロープアドレス)。

エンベロープとはすなわち封筒だ。封筒には差出人と宛先の住所を書くだろう。しかし中に各手紙にも「〇〇さんへ」「△△より」と書くだろう。前者がエンベロープアドレス(実際の差出人と宛先)で、後者がメールヘッダだ。

そこでmail関数を考える。引数は5つ。最初の引数は宛先だが、ここは宛先なのだがToヘッダとエンベロープの宛先を兼ねていると考えればよい。2つ目と3つ目のヘッダはタイトルと本文なので説明は省略。

4つ目の引数を考える。ここでヘッダを追加することができるわけだ。Fromを指定することはよくあるだろう。ここで指定するのはメールヘッダのFromだ。ではここにToを指定するとどうなるだろうか。最初の引数で指定する宛先をA、第4引数でToヘッダでBを指定する。どちらのアドレスにもメールは届くのだが、メールを見るとToヘッダが二つ付与されているはずだ(本来は一つのはずなのだが)。

で、第5引数。ここではメール送信プログラムにコマンドラインオプションを渡すことができるのだが、ここでエンベロープの差出人を指定することができる。-fオプションとメールアドレスを指定すればよい。

で、次の問題。この設定はセーフモードが有効になっているPHPでは使えない(第5引数が使えなくなる)。

そして個人的には「どんな設定でも有効になるのかどうか」確たる証拠がない。なんとなくPHPの設定やメールサーバの設定等によっては-fオプションが無効化されている場合もあるような気がする。どんな場合に使えないのか、それともいつでも絶対使えるのか、それがわからないのだ。

以前も同じような記事を書いたが、近頃いろいろ知恵が付いてきたので、それらをからめてメモしておくことにした。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net