概要

uw-imapdの設定は思わぬところでハマります。そこで勘所をちょっとだけ。

c-client.cfについて

あまり表に見せませんが、uw-imapdの設定には、/etc/c-client.cfというファイルをいじってやります。このファイルにいろいろ書いてやることにより、uw-imapdの動作を制御します。

ところが残念なことに、このファイルはDebianを普通にインストールしただけでは作られません。Debianを普通にインストールすると、たいてい設定ファイルを自動的に作ってくれるのが普通ですし、最悪でも雛型ファイルを置いてくれたりするものなのですが、現状のDebian(私はsid)のuw-imapdのパッケージではこのファイルはかけらも置いてくれません。

これは「パッケージャがサボっている」という考え方もありますが、/etc/c-client.cfの書き方について書いてあるdocs/imaprc.txtというドキュメントの記述を読むと、

docs/imaprc.txtの冒頭
*  These files, and this documentation, are for internal UW usage    *
* only.  This capability is for UW experimental tinkering, and most  *
* emphatically *not* for sorcerer's apprentices at other sites who   *
* feel that if a config file capability exists, they must write a    *
* config file whether or not there is any need for one.              *

なんちゅー脅し文句が書いてあったり、

/etc/c-client.cfの記述への注意書き
The very first line of the file MUST start with the exact string "I
accept the risk".  This ensures that you have checked the file for
correctness against this version of the IMAP toolkit.  This enable
string may change without notice in future versions, and the new
string may or may not be accurately described in an updated version of
this file.

なんちゅー言葉が書いてあったりして、なかなかシビレます。つまりまぁ善意に解釈すると、Debianのuw-imapdのパッケージャは「こんなヤバい注意が書かれたファイルは、たとえ雛型でも作りたくないや。なけりゃないでも動くし」と思って配布パッケージの中に入れてないのでしょう(sargeの最近の版では入っているようですが、御丁寧にもupgradeの度に初期化してくれます)。

とは言え、いくつかの問題を解決するには、このファイルをリスク覚悟でいじらなくてはなりません。たとえば普通にLOGIN認証を使おうと思えば、

/etc/c-client.cfの記述
I accept the risk for IMAP toolkit.
set disable-plaintext 0

といったことを書かなくてはなりません。

この例はうち(jh4tjwgw.nurs.or.jp:このサーバ)での記述ですが、たいていのところでは、この2行さえあれば良いでしょう。

さらに詳しいことは、docs/imaprc.txtを 読んで下さい。

mhフォルダを使う

uw-imapdはあまり得意だということにはなっていませんが、uw-imapdでは一応mh形式のメールフォルダを使えることになっています。と言うよりも、私はmh形式フォルダが使いたいがゆえに、uw-imapdを選択しました。そこでmh形式フォルダを使うように設定します。

ところが、uw-imapdにはmh形式フォルダを使うような設定は、ありません。

特別な設定なしでmh形式が扱えます。その代わりクライアント側の設定として、フォルダの指定の時に

#mh/

のように指定してやります。/の前がフォルダのタイプの指定で、uw-imapdでは、

#mh/, #news., #ftp/, #public/, #shared/

といったものが指定可能です。

さらに詳しいことは、docs/naming.txtを 読んで下さい。

一度でもmhを動かしたことのある環境なら、以上の説明で終わりです。しかし、今時mhを動かしたことのあるマシンをサーバにしてmh形式フォルダをimapで操作するという人はレアな人ではないでしょうか。実際には「mh形式が好きだから」といった理由でmh形式を選択しているという人がほとんどではないでしょうか? そして、そんな人は、自分のメールフォルダをサーバの更新の度にバックアップして持ち歩いているのではないでしょうか。そんな時につい忘れてしまうのが、

~/.mh_profileの設定

です。と言うか、正確なことを言えば、mh形式でメールの置いてあるディレクトリは、それ自体は単なるディレクトリに過ぎません。この.mh_profileがあって初めて「mh形式メールフォルダ」になります。ですから、このファイルのことを忘れていると、「mh形式でuw_imapdが動かない」とあわてることになります。

動作確認をする

サーバを設定したら動作確認をします。とってもあたりまえのことですが、面倒臭いのでついクライアントをつないでみたりするのが、IMAPサーバではないかと思います。そして、妙にハマってしまうという罠。

私も実は普段そうやっていたのですが、これではなかなか問題が解決しなかったりします。もし、手元にあるクライアントがいろいろと細かいログを吐いてくれるようなものであれば、いきなりクライアントをつないでしまっても、何とかなると思いますが、そうでないクライアントも少なくありません。そこで手でコマンドを送って確かめてみることになります。

IMAPというプロトコルは、POPや他の多くのインターネットプロトコルと同様に、要求やその返答には、普通にテキストを送るようになっています。ですから、テストプログラムを用意しなくても、telnetでIMAPのポートを指定してやれば、簡単に試してやることが出来ます。

送ってやるコマンドは何の動作確認をするかによって、いろいろですから、適当な文書を調べて下さい。とりあえず生きているかどうかを調べるには、

$ telnet ホスト名 imap
Trying ***.***.***.***...
Connected to ホスト名.
Escape character is '^]'.
* OK [CAPABILITY IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS STARTTLS
AUTH=LOGIN] jh4tjwgw IMAP4rev1 2003.337 at Sat, 17 May 2003 21:42:01
+0900 (JST)
A001 LOGIN ****** ******
A001 OK [CAPABILITY IMAP4REV1 X-NETSCAPE IDLE NAMESPACE
MAILBOX-REFERRALS BINARY SCAN SORT THREAD=REFERENCES
THREAD=ORDEREDSUBJECT MULTIAPPEND] User ogochan authenticated
A002 SELECT "#mh/"
* 2 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1053175399] UID validity status
* OK [UIDNEXT 12] Predicted next UID
* NO [UIDNOTSTICKY] Non-permanent unique identifiers: #mh/
* FLAGS (Answered Flagged Deleted Draft Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
A002 OK [READ-WRITE] SELECT completed
A003 LOGOUT
* BYE jh4tjwgw IMAP4rev1 server terminating connection
A003 OK LOGOUT completed
Connection closed by foreign host.
$ 

のようにしてやると、LOGIN認証とmhフォルダが使えるかどうかはわかります。

参考

他のIMAPサーバとの比較(モロに途中)

以下は私が意識した点についての比較です。それ以上のことは、各自で調べま しょう。

項目 uw_imapd Cyrus IMAP Gnu IMAP Courier IMAP
プロトコル IMAP4rev1 IMAP4rev1 IMAP4rev1 (IPv6, SSLサポート)
フォルダタイプ いろいろ(特にmh) 独自形式 mhはダメ? 拡張maildir
 
MODx Content Manager »

« MODx Parse Error »

MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »
 
PHP error debug
  Error: Cannot modify header information - headers already sent by (output started at /home3/ogochan/public_html/manager/includes/document.parser.class.inc.php:466) 
  Error type/ Nr.: Warning - 2 
  File: /home3/ogochan/public_html/manager/includes/document.parser.class.inc.php 
  Line: 430 
  Line 430 source: header($header);  
 
Parser timing
  MySQL: 0.0758 s s(13 Requests)
  PHP: 0.0318 s s 
  Total: 0.1077 s s