これはちょっと、面白い話だなーとおもったので・・・・たまには・・・
なぜか、新しいものを取得しようと思えば思うほど、古きにたどり着く。という事を最近実感しており、
そのためか、C言語も真面目に始めたのだが、何かC言語関連でおもしろい本がないかなーと探していたら・・・・
という本を読んでいました。
ただし、今回はプログラムとも、技術とも全く関係がありません。
この本の中で、余談として、赤ちゃんが「ンマ、ンマ」と声にしているのを聞いて、
ほんとどの国がそれを「お母さん」としたと。
ママ、ママン、マーマと、
しかし、日本だけ(たぶん)は、それを「ご飯(マンマ)」ととらえたと・・・・
日本文化は携帯などでも「ガラパゴス」って特殊扱いされているけど、
単なる置かれている環境の違いじゃないんじゃないかなー
と、この話を聞いて思ったりする。
ある意味、国際社会でKYとしての素質を日本人はDNAレベルで持っているということじゃないかな。
ただ、こんな、ちょっとした視点の違いってグローバル化されていけば、いくほど、面白いんじゃないかなー。と・・・
右向け右の社会で、左を向きましょうということだ。
それが、「ガラパゴス島を立派な観光ビジネス」に仕上げることになるんじゃないかな。
以前、「指定したドメインのメールを受け取る」という話で、
個別に指定したドメインは自分で受け取ってしまうということをやったが、
これの応用版として、「指定したドメイン以外はすべて自分で受け取る」
これは、よく大量メールの配信テストなどをしているときに、適当にメールアドレスを作って、
仮に、本当にそのドメインがあったとしても、外にメールが飛ばないということができる。
このような完全一致ではなく、あるパターンに一致したときには・・・となると、
設定に正規表現を使う方がよりスムーズだ。
そのために、Postfixで正規表現が使えるかを確認しよう。
確認方法
#postconf -m btree cidr environ hash ldap nis pcre proxy regexp static unix
のように、regexpやpcreが表示されれば問題ない。
(これからの例はregexpなので、pcreを使う場合の正規表現は別の形になるかもしれない。)
では、具体的に、あるメールアドレスがPostfixはどのように処理されるのだろうか?
http://www.postfix-jp.info/trans-2.2/jhtml/transport.5.html
を見ると、どのようにメールの配信方法が決定されるかがわかる。
以前は、このmydestinationを使ってしまったので、
非常に簡単にまた、直観的に設定できた。
今回は、virtual_mailbox_domainsを使って、
その設定に正規表現を使うようにする。
まず、正規表現を使う場所を決める。
つまり、どの処理から分岐をするか?ということだ。
そこには、そのまま、virtual_mailbox_domains に、 virtual_mailbox_mapsを使うことにした。
まず、以下のファイルを作成する。
/etc/postfix/virtual_mailbox_maps.regexp
/(.*)/!/(coltware.com)$/ /dummy/Maildir/
(ファイル名にルールはありません。)
これで、coltware.comというサーバ以外のサーバは、/dummy/Maildir/というディレクトリにMaildir形式で保存される。
自分サーバ向けは、mydestinationで指定されているので、このように、すべてに一致(.*)で、
かつ(coltware.com)以外ということにした。
本当に設定する前に、正しく正規表現が動くのかテストしましょう。
postmap -q "テストする文字列" regexp:/etc/postfix/virtual_mailbox_maps.regexp
で、結果(/dummy/Maildir/の文字列)が返ってきます。
もちろん、coltware.comのドメインの場合には、何も帰ってきません。
では実際の設定です。
virtual_mailbox_base = / virtual_mailbox_maps = regexp:/etc/postfix/virtual_mailbox_maps.regexp virtual_mailbox_domains = $virtual_mailbox_maps virtual_uid_maps = static:89 virtual_gid_maps = static:89
ここで、virtual_mailbox_baseは、先ほど、/dummy/Maildir/と指定したときに前に、このパスがつくのだが、
私は設定時に今後も完全にパスを指定したかったので”/”としました。
また、
virtual_uid_maps = static:89 virtual_gid_maps = static:89
は、メールファイルが保存されるときの、uidとgidなので、好きなuid,gidを設定してください。
で、この後に、postfixを再起動してください。
とこのようにすることで、自宅内にたてたテストメール配信サーバも、間違っても自分のサーバにしか飛ばないというわけです。
また、いろいろと正規表現をカスタマイズしていくことで、いろいろと出来てきます。
また、今回は、virtual_mailbox_domainsを使いましたが、あるドメインの配信先をsmtpからlocalに変えるという概念のほうが、よりわかりやすいので、transport_mapsを使ってもいいのですが、自分宛にメールが送られてから、そのメールをどのようにするか?
という設定を含めると、自分的には面倒なので使いませんでした。
余談:
これは本文とはまったく関係がないのですが、クラウドなどでよりサーバの設計はアプリケーションエンジニアのほうに仕事が移ってくるでしょう。
それに、このような要件は、サーバ構築で発生するわけではなく、機能定義で出てきます。
したがって、アプリケーションエンジニアがミドルウェアがどの程度までできるか?ということを把握することは非常に大切です。
また、これらの要件がまっさらから作ろうとすると非常に多くのコストがかかってしまいます。
クラウド時代の到達とともに、アプリケーションエンジニアが、サーバ構成・システム構成から設計できることは、スピードとコストを最大限にするためにも、今後ますます重要になってくるのではないでしょうか?
airxmailを使っていただいている方からのご協力もあり、いくつか修正することにしました。
http://code.google.com/p/airxmail/downloads/listの
r44が最新になっています。
1.送信が成功したときにSMTPEvent.SMTP_SENT_OKのイベントを発行するようにしました。
これを使えば、現在、x/n送信中なんて感じのだせるようになると思います。
2.Socket周りのエラーイベントはもともとあったイベントを使用するようにしました。
これは、おもに原因の切り分けのためです。SMTPやPOP3で通信していると、TCP/IPレベルでのエラーなのか、
SMTP/POP3のプロトコルレベルのエラーなのか、エラーイベントで揺れがありましたが、これらを統一するようにしました。
3.TLS/SSLが必要にも関わらず、Plainな通信を使ってしまうと固まってしまう問題の修正。
これは、ステータスがかえってくるのをずーとまってしまうという問題がありましたが、接続時にTCP/IPで接続ができた後に、
プロトコル上でのサービスの準備完了になるまでのタイムアウト値(現在5秒)を設けました。
4.接続のときに何か間違い(ID・パスワードの間違いとか・・・)、再接続したときに、以前のコマンドがクリアされずにいたために、
再度、処理が進まなかった問題を修正しました。
とこんな感じで、修正しました。
エラー周りなどは、もともと、あるアプリケーションのためにライブラリ化したので、その使い方をこえると、
考慮されていなかったり、ポリシーがぶれていたりするのですが、やはり、第三者の目が入るのはいいです。
airxmailを使って、gmailの「接続エラー」と「正常」のテストを何度かしていた。
そしたら、何度か、なぜか正しくやっているはずなのに、接続できないことが発生してきた・・・・
きちんと、airxmailでその時のメッセージを取得し、表示してみると
[PASSWORD]:535-5.7.1 Username and Password not accepted. Learn more at [PASSWORD]:535 5.7.1 http://mail.google.com/support/bin/answer.py?answer=14257
で、http://mail.google.com/support/bin/answer.py?answer=14257を見てみると、
「メール クライアントで新着メールのチェック間隔が短すぎないことを確認します。 メール クライアントで新着メールをチェックする間隔を 10 分以内に設定している場合は、ユーザー名とパスワードを入力するよう何回も要求されます。」
とのことでした。
ちょっと、びっくりしてしまいました。
さて、いきなり、反論も出るかとも思うが、私が思うのは、個人の消費と比較してだ。
私事ながら、数年前にマンションを買った。
マンション。それは、個人にとって大きな買い物だ。
だから、いろいろ調べたし、ほかの物件なども見た。
それにも、まして、勢いも必要だ。
でも、それでも、ある部分自分の判断を信じない部分もある。
それが、専門的な評価部分だ。
柱がどうだとか、耐震構造がどうだとか?
あとは、部屋の受け渡しでのチェック。
これは、素人目でもおかしいというところもあるだろうが、
やはり、プロの目から、仕上がりをきちんとチェックしてもらうことにした。
トイレなどの水回りの配管なども調べてくれるからだ。
こういった部分は、おかしなものを見せられ、そして説明を受けたら、おかしいとわかるが、
ただみて、それがおかしいのか、おかしくないのか?はよくわからない。
もちろん、業者はすべて、それが安全とか、問題ないということを言ってくる。
でも、結局は他との比較論であったり、コストとの相対論であったりする部分もあるので、
すべてが完璧とはいかないし、求めてもいない。
なので、やはり、プロのチェックが必要になり、お願いしたのだ。
このように、個人の消費でさえ大きなものは、そのように、消費者の立場のチェックはもとより、
プロの目から、提供者の立場(論理)からのチェックもしているのだ。
もちろん、そのためのコストも別に支払っている。
いわば、判断に対する保険料だ。
では、システムの発注の場合どうだろうか?
システムの発注者と、受注者の間にプロの目をいれないのはなぜだろうか?
「信じている」というとは、ここでいう、心理的なことを言っているのではなく、
契約的というか、手続き的というかの問題であるが、結果的に「信じている」と思う。
仮に、RFPの作成時と納品時を抑えられたら、防げるようなこともたくさんあることも見てきた。
なんで、こんなことも考えられていないの?というシステムが多すぎるからだ。
よくよく聞いたら、そんなことをお願いしていないとか、必要だと認識がなかったとか・・・
いい加減に結果が納品されてきたが、そこを説明された時に納得してしまったとか・・・
たとえば、自動車を個別に開発を仮に依頼するとしたら、仮にお客さんがブレーキの機能を求めなかっとしても、
絶対ブレーキの値段を入れてくるだろう。
ただ、システムの場合には、ブレーキがない時に、それをおかしいといってくれるかどうかは微妙だ。
ブレーキの機能が顧客側の運用側にある場合もあるので、システム提供側はそこまで教えてもらえなければ、
いらぬお節介をするかどうかになってしまうからだ。
でも、そのために、その後、膨大なコストをどちらかが背負うことになったり場合がよくある。
システムの発注と受注の間にも、そのようなシステムのプロの第3者の目が入ったほうがいいと思ったりするのだが、
どうしてそのようなサービスがないのだろうか?
顧客側に立った、システムのプロの目であれば、顧客も意見を言いやすいだろうし、
受注側も、自分たちに有利なようにごまかしているわけでなく、
本当にあるべき姿というのを言いやすくもなるだろうし・・・・
こういった、サービスが見つからないのはなぜなんでしょうか?
契約金のn%で請け負います。ってのがあってもいい気がするのですが・・・
と、たまに知人からの相談を受けていると、こういうのがきちんとサービスとしてあったほうが、
双方のメリットがあり、業界全体がよくなるのではないかと思うのでした・・・・

