The IMAP Connection
ttp://http://www.imap.org/ RFC3501:INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
ttp://http://rfc.net/rfc3501.html ■オープンソースの定番サーバ
IMAP Information Center: UW IMAP Server (mbox, MH, →パッチ適用で Maildir 可)
ttp://http://www.washington.edu/imap/ Cyrus IMAP Server (独自スプール形式)
ttp://http://asg.web.cmu.edu/cyrus/imapd/ Courier-IMAP (Maildir)
ttp://http://www.courier-mta.org/imap/ Binc IMAP (Maildir)
ttp://http://www.bincimap.org/ Dovecot (mbox, Maildir)
ttp://http://dovecot.procontrol.fi/ ※これ以外にもいくつかあるので IMAP Connection で検索すべし
■過去ログ
IMAP Serverとしてどちらがお勧め (UW or Cyrus)？
ttp://cocoa.2ch.net/test/read.cgi?bbs=unix&key=998711145 〓〓〓次世代メールプロトコル、IMAP〓〓〓
ttp://pc8.2ch.net/test/read.cgi/unix/989592181/ わざわざドキュメントやソース調べたり再現させようと同じ手順でインスコしてみた者の身にもなってくれ。
でなきゃ二度と質問するな。死ね。
こういう手合いには、思いつきででたらめな回答を返す奴が相手をするのが適している。
そのことを一目で判断して、触らないようにするんだ。
ﾜﾛｽ(*ﾟ∀ﾟ)ww
ﾔｻｼｽ(*´ω`)
それと、は不幸になりますように。
お前はもう来なくていいよ。
僕がどう解決したか聞きたいの？僕がどう答えようが自由でしょ？
しかも、聞きたいならそれなりの聞き方していただけませんか？
こっちだって必死に質問してるのに
こっちの質問無視して「次の方どうぞ」とか「中学生〜」
とか言われたら答える気にはなりませんよ。
だから「もういいです。解決しました。」と発言しました。
そのあとだってそう。普通にどう解決したのと聞いてくれたら答えたけど
死ねとか言われて答える気になる？
あまり粘着するのは好きじゃないので、言われた通りもうここへはきません。
だからあなたに会うことも一生ないです。
このコメントにレスは必要ないです（もうこないから）。では失礼します。
=341さんへ
2chにただベタ書きしてるようじゃ、厨房認定されるのもあたりまえ。
まともな技術系MLで質問しても、言葉遣いは違おうが同じように返されるのが関の山。
まあ、ようするに コ ン ピ ュ ー タ に 向 い て な い ということだ。
初っ端の質問からプンプンしてんだから、
黙ってスルーしようぜ。
自体に答え書いてあるわけだし。
ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
uw-imap使ってたころ、メール消失したことある
SMTPがメールボックスいじると消失とかある？
ストレージ上のメール箱にロックファイルとか
作ってくれる鯖もあるっぽいので、そういうので
排他しようかと思います。
Maildir ならOKかも。
「IMAP でログインしてるときに」って意味だよね?
それも実装の問題だろう。
でもそんなダメな実装はない、と信じたいなぁ。
実際、thunderbird は1クライアントで複数接続する。が、
>ストレージは外部に一元化させて、フロントの imap 鯖を LB とかで単純に
>負荷分散構成にしちゃって良いものかどうか考え中なのですけど。
これって同じメールボックスにアクセスする imap サーバが複数あるということ？
さすがにそれは保証できんだろ。外からは同じに見えても内部的には別なんだから、
それはクライアントとサーバの間の問題ではなく、複数のサーバがひとつの
メールボックスを同時アクセスするときの制御の問題になる。
別ホストで動いているプロセス間で情報をやりとりする仕組みを備えている
実装でないかぎり（そんな実装があるのかどうか知らん）、
同時ログインしたらぶっこわれる可能性が高い。
>Maildir ならOKかも。
maildir が保証するのはあくまでメールの中身だけ。それ以外の管理情報は
別のところに置く実装が多いので、メールと管理情報の不整合が起きる可能性がある。
たとえば、ファイルの実体がサーバ上に残っていても、もし imap サーバがそれを
認識できなくなったとしたら、ユーザからすればメールが消えたのと同じ。
お、そうなんですか。情報ありがとうございます。
>これって同じメールボックスにアクセスする imap サーバが複数あるということ？
はい。ご指摘の通り、異なるホスト間でセッション情報を共有するような
ソフトは恐らくないかと思いますｗ ただ、RDBMS にセッション情報を
置くとか、ファイルシステム上にロック情報を置くとかして代替する
ことは出来るかなぁと思ってます。前者は SQL でフラグを参照するように
出来ればいけそうですし、後者は実装済みのものがありそうです。
# どっちもデッドロック発生の可能性を秘めていますが・・・ｗ
ttp://www.dbmail.org/ ほとんどない。こんなものなのかな？
IMAPがこんなものなのか、サーバーがしょぼいのか、メールクライアント
（Becky）が負荷高いのか。。
ただし同時アクセス時の"Message State"についてはRFC 4551でやっと規定されたので、そこら辺のインターオペラビリティは芳しくない。
同期を簡単に確実に早くする方法を定めている。
IMAP的には、複数クライアントの同時アクセスは保証していない。
2本目が来たときに、2本目を拒否するか、1本目を切断するサーバもある。
アクセスしたほうがスケーラブルな感じがしません。Atom Publishing Protocolとか。
あ、そりゃGMailか、今のところFeedだけだけど、AtomPubで操作ができたら最強だよね？
で、AtomPubのdraftを書いてる人がGoogleに転職したみたいだからあり得るよね？
のサポートしない理由ってのスケールしないって所にあるのかも。
スレ違いですまない。次世代のメールプロトコルってことで。
というかあの規模のユーザ数でそれは現実的に無理かと。
POP3とかHTTPなら繋いで取得したらポンと離れちゃうから…
# GMailってcometみたいなHTTP繋ぎっぱしてるんでしたよね？(でも200秒ぐらいで切ってる)
スレ違いかもしれないけど、このまま続けて良い？
んじゃ、このまま、
GET /userID/inboxとかでメール取得とか
POST /userID/sendとかで新規作成=送信も？
PUT /userID/foo/bar/folder/message-idとかで既読設定とか
DELETE /userID/foo/bar/folder/message-id とかで削除
表現=REpresentationはAtom形式
たとえば、GoogleのGData API が既存のサービスにどんどん対応している。
足りないのはGMailの操作系のAPI ってことでそのうち対応するんじゃないのかな？とか。
ttp://http://code.google.com/apis/gdata/index.html Internet Mail System 総合スレ 3
ttp://pc11.2ch.net/test/read.cgi/unix/1128256415/ AtomPubはブログに限らないWebリソースを出版編集するためのプロトコル。
すでにメールボックスなんてWebメーラが流行ってる通りWebリソース。
IMAPをWebメーラでかぶせるの逆、最初っからWebで取得／操作。
もちろん専用クライアントがないけどね。
でも、実装はメールクライアントにRSS/Atomリーダなんかがくっついてるやつ(Thunderbirdとか)なら
そこらへんが応用できるから、IMAPよりシンプルに実装出来そうですよね？？？
多分2008-2010年ぐらい？のメールアプリ予想。
と、素人が妄想してみました。
ごめん。それ知らんかった。ゆるして。
つづき(があるなら)そっちで。
なんか雰囲気ちがうっぽいのであっちにも書かないでおく。
頭からながめて行ったら
ttp://pc11.2ch.net/test/read.cgi/unix/1128256415/187 は俺だったw
「いつまでも次世代IMAP」だと思ってたらWebベースのプロトコルが流行っちゃうんじゃないかな？
という意味でIMAPがらみということでゆるして。（なんどもすまん）
それじゃ困ることが山ほどあるから、今のIMAPになったの。
そう言う訳じゃないけど、ごめんごめん。
具体的には？
過疎ってるけどこっちに行ってみるよ。
ttp://pc11.2ch.net/test/read.cgi/blog/1101813178/ そこをちゃんと分析しておかないと、簡単なプロトコルを作ったつもりが、
いつの間にか IMAP と同じ道を歩むことになるぞ。
といっても、には理解不能なんだろうな…
ある用途ではRESTfulなWeb Serviceでのメールボックアクセスの方法もアリじゃないの？
と言ってみただけです…。
SOAP vs RESTみたいな話になっちゃうからやめときます。
だから、その「ある用途」っていうのの定義をだな、しっかりしておけ、
と言っているのだよ。そうしておかないとプロトコルが定まらないよ、と。
そしてスレ違い。
Webﾒｰﾙｵﾝﾘｰの時代が来たらもうIMAP(=POPｼﾎﾞﾝ)なんだろうか
接続が切れることもなく、しかも安価、バッテリー切れにもなかなかならない、
というような時代になればIMAPが来るんじゃないかと思う。
LEMONADE でがんばってますよね。
その間にこれを使って欲しいんだ…
P-IMAP って、IMAPの拡張の1つよね。
大多数が使ってるプロバメールでIMAP専用って無いよね
フリーメールでもUIは専用Web中心でIMAPは無い
POP3ではなく敢えてIMAP4を使うなら「メールはサーバに置いて、自分でﾌｫﾙﾀﾞ整理して使う」
形が主だと思うんだけど昨今のアクセスラインの高速化、PC＆サーバHDD容量の拡大などにより
余りアドバンテージが無くなってる希ガス
むしろ「IMAPがこの先生き残るには？」とか考えちゃう
今思いつく一般ライトユーザ向けメリットは「サーバでspam分類サービスしてて、それで保留になっ
たメールフォルダをあとで自分で確認＆訂正できる」くらい？
本当にIMAPの時代は来るのだろうか。
電話嫌いで使う必要性も無い人に携帯電話を持たせてもしょうがないとか、
音楽を聴くのが好きじゃない人に携帯オーディオプレイヤーを持たせてもしょうがないとか、
そんなようなもん。
企業ではIMAPとか、IMAPと同様にサーバサイドにメールを抱えるプロプライエタリ製品
（こっちのが断然多いけど）を使ってるところがよくあるよな。
IT投資をあまりやる気がない（仕事の内容や従業員の傾向としてやっても意味がない）
ような企業ではPOPを使ってるけど。
場合じゃないと思う。
広く受け入れられなくていいんだ、というなら止めませんが・・・
ってのが一番だと思いますよ。
関係データベースにアクセスするのにSQLを使うように、
メールストレージにアクセスするのにIMAPを使う、そんなものです。
全員が使わなきゃならないものじゃない。
リレーショナルDBで管理してなくて、表計算ソフトで管理しているデータなんて
山ほどあるでしょ？
「POP3に代わる次世代プロトコル」という認識が、そもそも間違い。
無理にSQLにたとえるなら、主キーでselectすることとdeleteすることしか出来ないのがPOP、
いろいろ出来るように機能が拡張されているのがIMAP、というところか。
前者しか使わないアプリケーションで何の不満も無く業務をこなしてる人のところに、
後者を使った高機能のアプリケーションを持っていって意味があるか？
やろうとしてることが別。
ｽﾚﾀｲ嫁
ただのオナニー規格じゃないところを見せて欲しい
「次世代」って何のこと？逆に言えば「前世代」って何？
/var/(spool/)mailを直接アクセス☆
同時アクセスの排他制御はどうするんだよ？とか、
いろいろ面倒なので、スプールにアクセスするプロトコルを規定した。
それだけのこと。
クライアントからサーバにメールを戻せるのは
便利だと思うけどなぁ。
一知半解の素人で、相手をしてもしょうがないんだよなあ
POP3は必要最低な条件は満たしている。
それは「スプールに届いたメールを取り出す」というな。
POP = スプールからメールを取り出すプロトコル
IMAP = スプールのメールを操作するプロトコル
いい加減、理解しろよ。
GMailがIMAP対応始めたみたいね…
HotMailのHTTPMailがそんな仕様だったような（遠い記憶）
ttp://http://www.washington.edu/imap/ いつになったら2007になるんだ?
2年に一度、メジャーバージョンアップ。
Fcc:なんかでimapに放り込めばいいじゃん、という話ではない?
Courier には、特定のメールボックスにメッセージを置くと、
外に配送される機能があったような。
おれあんまりIMAP詳しくないから外れてるかも心内。
SMTPサーバでSenderのところへ自動的にBCCってのも手なのだが、
マルチアカウントになってくると、本当にそれでいいのか、とか。
A001 COPY 548 INBOX.Trash
* NO Invalid message sequence number: 548
A001 OK COPY completed.
タグなしNOは警告であって、コマンドが成功する場合もあるし、失敗する場合もある。
この場合、明らかにコピーに失敗しているのにタグ付き応答でOKが返ってくる。
コピーに成功したと思ってコピー元を削除するとメール消失になっちゃうよ。
削除することも出来そうに見えないが。
ああ、確かにこれはUID COPYとすべきところを間違えてCOPYにしてたので発見したことなのです。
まぁ、言いたかったことは、仕様ではない動作をしているんじゃないかということです。
それで実害が生じるケースというのがちょっと思いつかない。
わりとどうでもいいことのような。
このタグベースのフォルダ分けってすごく便利ですね。
すでに溜め込んでいるメールに対して、フィルタの条件を変えたり加えたりするだけで、
そくざにフォルダを作れる。(メールに、メタ情報の属性付け)
POP + MUA だと、フォルダに自動振り分けしても、振り分け済みのメールを別の切り口で
整理したかったら、refile しないといけない。
Gmail IMAP のような、タグベースのフォルダわけができるような imapd ってないですか？
ximapd なんてのもあったけど、開発止まってるね。
良く分かってないんだけど imapd 側でやるの?
MUA でフィルタ適用みたいな機能ってあると思うけど
サーバ側で実装するメリットってどの辺でしょう?
検索とかが(通信コストなしに)サーバ側負担で実施できるとかかな?
日本人の人が作っているんですね。
サイトを見たところ、まだ安定版まで入っていないようですが、
Software Design 2006年2月号 に記事を掲載、とあるので、家にある雑誌を掘り出してみよう。
サーバ側で、と考えています。
でも自分の望んでいることは、MUA側で
・物理的なメールボックスを持たない
・メールにタグ付けしておき、任意の切り口で、好きなときに閲覧できる
ことができればいいので、ローカルで RDB にメールを突っ込んだりしてもいいことに気がついた。
そういうMUA はいまのところありませんが・・・・(sylpheed +
そういう意味で、imap サーバ側でこういった機能を実装しておけば、
既存の MUA でもメリットを享受できてよいかな、と思いました。
あと、サーバ側に実装するメリットとしては、通信コストもあるけどCPU負荷、I/O負荷の軽減です。
ローカルでビルドとかしているときに、メールの抽出でガリガリいってほしくない。
dbmail ではできないのかな。
filter extension でフィルタ条件を覚えておく、って感じかな。
将来的には。まだID。
view とか window extension は亡きものになったんだろうか。
百歩譲ってAPPEND&削除するとしてもUIDPLUS拡張がないとローカルと対応とれないし。
ヽo,´-'─ 、 ♪
r, "~~~~"ヽ
i. ,'ﾉﾚノﾚ!ﾚ〉 ☆ 日本の核(武装)は早急に必須です ☆
__ '!从.ﾟ ヮﾟﾉﾙ 総務省の『憲法改正国民投票法』のURLです。
ゝﾝ〈(つY_i(つ
ttp://http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html ｀,.く,§_,_,ゝ,
~i_ﾝｲﾉ
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
NMAEZENIXV
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
CBOGI
