From deisui ＠ bug.org  Thu Nov  2 00:37:27 2000
From: deisui ＠ bug.org (Daiki Ueno)
Date: 02 Nov 2000 00:37:27 +0900
Subject: proposal for new SASL client APIs
Message-ID: <m28zr3itzc.fsf@gg.bug.org>

上野です。;; ほとんど私信ですが...

新しい SASL client API の実装案として、幾つかの module を
deisui-1_14 枝に commit しました。

[注意事項]

(1) あくまで案なので、あまり期待しないで下さい。
(CRAM-MD5 以外の認証はできません。)
(2) 特に、SLIM の API とは完全に互換性を欠くので注意して下さい。
(3) draft-weltman-java-sasl-03.txt - "The Java SASL Application Program
Interface" を参考にしています。

[利用方法]

主要な API は sasl-find-authenticator と sasl-evaluate-challenge
の二つだけで、ひたすら continuation を渡しながら challenge/response を行います。

例:
(let ((authenticator
       (sasl-find-authenticator '("CRAM-MD5")))
      (response
       (sasl-evaluate-challenge
	authenticator principal)))	;initial response
  (smtp-send-command process (format "AUTH CRAM-MD5" mechanism))
  (catch 'done
    (while t
      (setq response (smtp-read-response process))
      (when (= (car response) 235)
	;; the authentication process is finished.
	[...])
      ;; retrieve next response
      (setcar (cdr sasl-response) (nth 1 response))
      (setq sasl-response
	    (sasl-evaluate-challenge
	     authenticator principal sasl-response))
      (smtp-send-command process sasl-response))))

;; 詳細は smtp.el の smtp-primitive-auth を見て下さい。

;; P.S.

;; 暗号関連のアルゴリズム全般を JCA (Java Cryptographic Architecture) の
;; ような形(あまり好きではないけれども)に分離したいところなのですが、
;; ご興味のある方はおられますか？
-- 
Daiki Ueno



From deisui ＠ bug.org  Thu Nov  2 18:34:58 2000
From: deisui ＠ bug.org (Daiki Ueno)
Date: 02 Nov 2000 18:34:58 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <m28zr3itzc.fsf@gg.bug.org>
 (Daiki Ueno's message of "02 Nov 2000 00:37:27 +0900")
References: <m28zr3itzc.fsf@gg.bug.org>
Message-ID: <871ywuson1.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00643] 
>>>>>	Daiki Ueno <deisui ＠ bug.org> wrote:
> 新しい SASL client API の実装案として、幾つかの module を
> deisui-1_14 枝に commit しました。

> (1) あくまで案なので、あまり期待しないで下さい。
> (CRAM-MD5 以外の認証はできません。)

とりあえず、DIGEST-MD5 と PLAIN を追加しました。
;; SCRAM-MD5, LOGIN の実装は未定です。

(setq smtp-use-sasl t
      smtp-sasl-mechanisms '("CRAM-MD5" "DIGEST-MD5")
      ;;smtp-sasl-principal-realm "bug.org"
      ;;smtp-sasl-principal-name "ueno")

などとしておくと、T-gnus 等の本体を変更せずに SMTP AUTH を使うことができます。:-)
;; たぶん、WL でもそのまま使えると思います。
-- 
Daiki Ueno



From okada ＠ opaopa.org  Mon Nov  6 16:33:20 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Mon, 06 Nov 2000 16:33:20 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <871ywuson1.fsf@gg.bug.org>
References: <m28zr3itzc.fsf@gg.bug.org>
	<871ywuson1.fsf@gg.bug.org>
Message-ID: <sgitq1eerj@opaopa.org>

おかだです。

呼ばれていたのに、こちらでの返事が遅れてすみません．
;; わたしへの私信ではないと思い込もうとしていたのですが…

In the message "Re: proposal for new SASL client APIs"
               <871ywuson1.fsf ＠ gg.bug.org>
Daiki Ueno <deisui ＠ bug.org> wrote:

> >>>>> In [emacs-mime-ja : No.00643] 
> >>>>>	Daiki Ueno <deisui ＠ bug.org> wrote:
> > 新しい SASL client API の実装案として、幾つかの module を
> > deisui-1_14 枝に commit しました。

上野さんとこっそり議論を進めていたのですが、
SLIMのAPIよりはよさそうです．
FLIMのSASL APIとして、Deisui-1_14枝のSASL APIを
使用すること支持します．

;; SLIMは、とりあえず動くことを目標に作っただけなので、
;; APIなんて、なんも考えてませんでした．:)
;; きりのいいところで、flim-1_14枝に統合してしまうのが
;; いいのではないでしょうか．

;; smtpmail.el variant などともAPIを統合したいところです．

> T-gnus 等の本体を変更せずに SMTP AUTH を使うことができます。:-)
> ;; たぶん、WL でもそのまま使えると思います。

SMTP AUTHだけでなく、WLのIMAP, POPとかも、
flim-1_14に統合したあたりで、APIを変更してしまっても
いいのではないでしょうか．

;; その暁には、本家Gnusも変更してしまってください．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From deisui ＠ bug.org  Mon Nov  6 22:25:55 2000
From: deisui ＠ bug.org (Daiki Ueno)
Date: 06 Nov 2000 22:25:55 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <sgitq1eerj@opaopa.org> (=?ISO-2022-JP?B?GyRCMixFRBsoQiA=?=
 =?ISO-2022-JP?B?GyRCN3IwbBsoQg==?= / Kenichi OKADA's message of "Mon, 06
 Nov 2000 16:33:20 +0900")
References: <m28zr3itzc.fsf@gg.bug.org> <871ywuson1.fsf@gg.bug.org>
 <sgitq1eerj@opaopa.org>
Message-ID: <87k8ahmduk.fsf@gg.bug.org>

上野です。

deisui-1_14 枝を flim-1_14 枝に merge しました。
より aggressive な開発は、引き続き deisui-1_14 枝でやりましょう。

>>>>> In [emacs-mime-ja : No.00645] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> > > 新しい SASL client API の実装案として、幾つかの module を
> > > deisui-1_14 枝に commit しました。

[...]

> SMTP AUTHだけでなく、WLのIMAP, POPとかも、
> flim-1_14に統合したあたりで、APIを変更してしまっても
> いいのではないでしょうか．

これは、現状の API の評価を兼ねて、岡田さんにお願い致します。

> ;; その暁には、本家Gnusも変更してしまってください．

本家 Gnus は、GSSAPI の認証に imtest (Cyrus のツール / IMAP SASL profile
依存) を利用しているので、そう簡単にはいかないと思います。
sasl.el native で GSSAPI の認証に対応する良い方法を思い付く方は教えて下さい。

;; また starttls のような外部プログラムを作らなければならないでしょうか。
;; corba.el や XEmacs Java binding を使うという手も考えられますが…。
-- 
Daiki Ueno



From okada ＠ opaopa.org  Tue Nov  7 22:52:14 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Tue, 07 Nov 2000 22:52:14 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <87k8ahmduk.fsf@gg.bug.org>
References: <m28zr3itzc.fsf@gg.bug.org>
	<871ywuson1.fsf@gg.bug.org>
	<sgitq1eerj@opaopa.org>
	<87k8ahmduk.fsf@gg.bug.org>
Message-ID: <sgpuk7evox@opaopa.org>

おかだです。

In the message "Re: proposal for new SASL client APIs"
               <87k8ahmduk.fsf ＠ gg.bug.org>
Daiki Ueno <deisui ＠ bug.org> wrote:

> deisui-1_14 枝を flim-1_14 枝に merge しました。
> より aggressive な開発は、引き続き deisui-1_14 枝でやりましょう。

まだ SASL APIは変更の可能性はありますか？
可能性が低くなったら教えてください．

> > SMTP AUTHだけでなく、WLのIMAP, POPとかも、
> > flim-1_14に統合したあたりで、APIを変更してしまっても
> > いいのではないでしょうか．

> これは、現状の API の評価を兼ねて、岡田さんにお願い致します。

とりあえず、それらしいことをしてみました．

参考コード:
ftp://opaopa.org/pub/elisp/elmo-imap4-deisui.patch

本体にマージするにはあまりにも気の引けるコードなので、
とりあえず、パッチの形にしています．
;; かなり汚ないコードになってしまったので、
;; また書き直します．

一つ思ったのが、IMAP,POPに固有の問題ですが、
IMAP にはLOGIN認証(not-sasl)があり、
POP にはPOP,APOP認証があります．

わたしの参考コードでは、かなり汚ない方法で対処しています．
LOGIN認証をSASL-IMAP4-LOGIN認証としてでっちあげて、
sasl.elの枠組みの中で扱おうとしています．
SASL以外の認証方式を sasl.el で簡単に扱えたら
嬉しいかなと*少し*思いました．
;; もちろん、そんなものは SASLじゃないので、
;; client側(elmo-imap4.elなど)で対処ればいいと言われれば
;; それまでなんですが．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From okada ＠ opaopa.org  Tue Nov  7 23:02:28 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Tue, 07 Nov 2000 23:02:28 +0900
Subject: sasl-login (Re: proposal for new SASL client APIs)
In-Reply-To: <sgpuk7evox@opaopa.org>
References: <m28zr3itzc.fsf@gg.bug.org>
	<871ywuson1.fsf@gg.bug.org>
	<sgitq1eerj@opaopa.org>
	<87k8ahmduk.fsf@gg.bug.org>
	<sgpuk7evox@opaopa.org>
Message-ID: <sgofzrev7v@opaopa.org>

おかだです．

別件です．

sasl-login-response-{1|2}で、(sasl-step-data step)をチェックしていますが、
これは必要ですか？
imap-2000では、"User Name\0", "Password\0" というのを返すようです．

とりあえず、
(string-match "^user ?name." (sasl-step-data step)
(string-match "^password." (sasl-step-data step))
にしておきました．

;; commit した後ですが、該当部分をcomment-outするだけでよかった気が
;; しています．:)

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From suimin ＠ bug.org  Wed Nov  8 00:01:14 2000
From: suimin ＠ bug.org (Daiki Ueno)
Date: 08 Nov 2000 00:01:14 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <sgpuk7evox@opaopa.org> (=?ISO-2022-JP?B?GyRCMixFRBsoQiA=?=
 =?ISO-2022-JP?B?GyRCN3IwbBsoQg==?= / Kenichi OKADA's message of "Tue, 07
 Nov 2000 22:52:14 +0900")
References: <m28zr3itzc.fsf@gg.bug.org> <871ywuson1.fsf@gg.bug.org>
 <sgitq1eerj@opaopa.org> <87k8ahmduk.fsf@gg.bug.org> <sgpuk7evox@opaopa.org>
Message-ID: <87itpz7rnp.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00647] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> > deisui-1_14 枝を flim-1_14 枝に merge しました。
> > より aggressive な開発は、引き続き deisui-1_14 枝でやりましょう。

> まだ SASL APIは変更の可能性はありますか？
> 可能性が低くなったら教えてください．

それは岡田さんの仰る、実地での利用にもとづく評価次第なのですが。^_^;;
ひとまず個人的には FLIM 1.14 に merge した時点で、freeze したつもりです。
;; これにより、現状の SLIM の、肥大化した API は obsolete としたいです。

;; 次期 deisui は、可能な限り luna に癒着したかたちで、完全に OO したも
;; のになると思います。Dia で描いたクラス図(もどき)を以下に置きますので、
;; 興味のある方は御覧下さい。ほとんど elisp ではありませんが。

;; http://www.unixuser.org/~ueno/junk/sasl.eps

;; 当面の目標としては、akr さん御提案の同期型 API を、現状の非同期 API の
;; 上に載せること、sasl-step から data slot を除去すること等が挙げられます。

> 一つ思ったのが、IMAP,POPに固有の問題ですが、
> IMAP にはLOGIN認証(not-sasl)があり、
> POP にはPOP,APOP認証があります．

> わたしの参考コードでは、かなり汚ない方法で対処しています．
> LOGIN認証をSASL-IMAP4-LOGIN認証としてでっちあげて、
> sasl.elの枠組みの中で扱おうとしています．
> SASL以外の認証方式を sasl.el で簡単に扱えたら
> 嬉しいかなと*少し*思いました．
> ;; もちろん、そんなものは SASLじゃないので、
> ;; client側(elmo-imap4.elなど)で対処ればいいと言われれば
> ;; それまでなんですが．

あくまで個人的な予想ですが、これが汚い方法と考えられる理由としては、
そもそも layer が異なる sasl-mechanism への直接の組み込みを前提にして
いるからでしょうか。

簡単に済ませるなら、上記クラス図の sasl-synchronous-client の親クラスに
Adapter を簡単に定義できるような界面を用意しておくとか。

いずれにしても sasl.el に kludge を入れずに済ませるには、裏に更なる抽象
化が必要なので、できれば次期 deisui の実装を待ったほうが良いと思います。
-- 
Daiki Ueno



From suimin ＠ bug.org  Wed Nov  8 00:10:45 2000
From: suimin ＠ bug.org (Daiki Ueno)
Date: 08 Nov 2000 00:10:45 +0900
Subject: sasl-login (Re: proposal for new SASL client APIs)
In-Reply-To: <sgofzrev7v@opaopa.org> (=?ISO-2022-JP?B?GyRCMixFRBsoQiA=?=
 =?ISO-2022-JP?B?GyRCN3IwbBsoQg==?= / Kenichi OKADA's message of "Tue, 07
 Nov 2000 23:02:28 +0900")
References: <m28zr3itzc.fsf@gg.bug.org> <871ywuson1.fsf@gg.bug.org>
 <sgitq1eerj@opaopa.org> <87k8ahmduk.fsf@gg.bug.org> <sgpuk7evox@opaopa.org>
 <sgofzrev7v@opaopa.org>
Message-ID: <87d7g77r7u.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00648] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> sasl-login-response-{1|2}で、(sasl-step-data step)をチェックしていますが、
> これは必要ですか？
> imap-2000では、"User Name\0", "Password\0" というのを返すようです．

;; ありゃ、IMAP 2000 release されていたのですね。^_^;;

> とりあえず、
> (string-match "^user ?name." (sasl-step-data step)
> (string-match "^password." (sasl-step-data step))
> にしておきました．

> ;; commit した後ですが、該当部分をcomment-outするだけでよかった気が
> ;; しています．:)

ありがとうございます。

この部分は Cyrus SASL の login plugin の挙動を真似たのですが、
LOGIN mechanism に関しては仕様がないので、どちらでも良いと思います。

;; 純正品(?) ということから言うと、IMAP 2000 を信じるのが、
;; 恐らく正しいのでしょう。
-- 
Daiki Ueno



From okada ＠ opaopa.org  Wed Nov  8 13:04:47 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Wed, 08 Nov 2000 13:04:47 +0900
Subject: sasl-login (Re: proposal for new SASL client APIs)
In-Reply-To: <87d7g77r7u.fsf@gg.bug.org>
References: <m28zr3itzc.fsf@gg.bug.org>
	<871ywuson1.fsf@gg.bug.org>
	<sgitq1eerj@opaopa.org>
	<87k8ahmduk.fsf@gg.bug.org>
	<sgpuk7evox@opaopa.org>
	<sgofzrev7v@opaopa.org>
	<87d7g77r7u.fsf@gg.bug.org>
Message-ID: <sgk8afhzxc@opaopa.org>

おかだです。

In the message "Re: sasl-login (Re: proposal for new SASL client APIs)"
               <87d7g77r7u.fsf ＠ gg.bug.org>
Daiki Ueno <suimin ＠ bug.org> wrote:

> >>>>> In [emacs-mime-ja : No.00648] 
> >>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> > sasl-login-response-{1|2}で、(sasl-step-data step)をチェックしていますが、
> > これは必要ですか？
> > imap-2000では、"User Name\0", "Password\0" というのを返すようです．

> ;; ありゃ、IMAP 2000 release されていたのですね。^_^;;

最近のものでは、STARTTLSやimapsとかが使えるようになりました．

;; 全経路(SMTP,POP,IMAP,NNTP)を暗号化できて幸せです…
;; あとは、INN+cyrus-saslなコードを書けば完成かな…

> > とりあえず、
> > (string-match "^user ?name." (sasl-step-data step)
> > (string-match "^password." (sasl-step-data step))
> > にしておきました．

> この部分は Cyrus SASL の login plugin の挙動を真似たのですが、
> LOGIN mechanism に関しては仕様がないので、どちらでも良いと思います。

> ;; 純正品(?) ということから言うと、IMAP 2000 を信じるのが、
> ;; 恐らく正しいのでしょう。

[emacs-mime-ja: 00090]で書きましたが、確か、IMAP 2000よりも、
Microsoft Exchange Server
Netscape Messenger
が初めに実装したんだと思います．

sasl.elの実装の際に参考にしたWebがあったのですが、
今はなくなっているようです．

まあ、問題が発生したら修正するというとこで…

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From okada ＠ opaopa.org  Wed Nov  8 16:47:25 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Wed, 08 Nov 2000 16:47:25 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <87itpz7rnp.fsf@gg.bug.org>
References: <m28zr3itzc.fsf@gg.bug.org>
	<871ywuson1.fsf@gg.bug.org>
	<sgitq1eerj@opaopa.org>
	<87k8ahmduk.fsf@gg.bug.org>
	<sgpuk7evox@opaopa.org>
	<87itpz7rnp.fsf@gg.bug.org>
Message-ID: <sglmuuvraq@opaopa.org>

おかだです。

In the message "Re: proposal for new SASL client APIs"
               <87itpz7rnp.fsf ＠ gg.bug.org>
Daiki Ueno <suimin ＠ bug.org> wrote:

> > > deisui-1_14 枝を flim-1_14 枝に merge しました。
> > > より aggressive な開発は、引き続き deisui-1_14 枝でやりましょう。

> > まだ SASL APIは変更の可能性はありますか？
> > 可能性が低くなったら教えてください．

> それは岡田さんの仰る、実地での利用にもとづく評価次第なのですが。^_^;;
> ひとまず個人的には FLIM 1.14 に merge した時点で、freeze したつもりです。
> ;; これにより、現状の SLIM の、肥大化した API は obsolete としたいです。

当面は、Wanderlust, (T-Gnus?) あたりが利用するだけなので、
APIの変更に伴なうバージョンアップを強いてもいいかなとも思っていたりします．
;; あんまり変更が激しくてユーザから敬遠されるのも悲しいですが．

とりあえず、wl-2_5ができて暫くしたら FLIM 1.14のsasl.elを利用するように
変更してみようと思います．
古いSLIMでも動くような配慮も、余裕があればやろうと思います．
;; しなくてもいいかな．

;; ところで、NTLMとか実装すると嬉しい人はいるんでしょうか．
;; Deisui APIでは、client側の変更なしに新しいmechanismを
;; 導入できるので、急いで実装するつもりもないですが．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From ueno ＠ bug.org  Mon Nov 13 05:49:52 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 13 Nov 2000 05:49:52 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <86puk2zg9u.wl@dolphin.be.to>
 (OKAZAKI Tetsurou's message of "Sun, 12 Nov 2000 00:21:01 +0900")
References: <m28zr3itzc.fsf@gg.bug.org> <871ywuson1.fsf@gg.bug.org>
 <sgitq1eerj@opaopa.org> <87k8ahmduk.fsf@gg.bug.org> <sgpuk7evox@opaopa.org>
 <868zqtt0ex.wl@dolphin.be.to> <86puk2zg9u.wl@dolphin.be.to>
Message-ID: <87wve8vrtb.fsf@gg.bug.org>

>>>>> In [Wanderlust : No.06154] 
>>>>>	OKAZAKI Tetsurou <okazaki ＠ be.to> wrote:

> しばらくこの環境で使っていたのですが、SMTP 経由で mail を
> 送信できなくなることがありました。Backtrace を取る前に環境を
> 戻してしまったので、はっきりとは言えないですが、^g で送信処理を
> 中断した後の "*trace of SMTP session to ..." バッファを見ると、
> smtp.el の smtp-send-data のあたりで止まっている様に思えました。

申し訳ありません。僕の miss です。先程修正しました。

sasl.el のほうに気を取られていて書き忘れていましたが、
実は smtp.el も、ほぼ完全に書き直されています。

事後報告になりますが、変更点を以下にまとめておきます。

今迄 1 関数で閉じていた処理を、多重度の異なる 3 つの class に分離しました。

(1) SMTP protocol command
(2) process / process-contact (smtp-connection)
(3) RFC1869 (Section 3) で述べられる envelope と content の対 (smtp-package)

;; 古い QMTP の文書と JavaMail API に少しだけ影響を受けています。
-- 
Daiki Ueno



From ueno ＠ bug.org  Sat Nov 18 19:51:48 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 18 Nov 2000 19:51:48 +0900
Subject: proposal for new SASL client APIs
In-Reply-To: <sglmuuvraq@opaopa.org>
References: <m28zr3itzc.fsf@gg.bug.org> <871ywuson1.fsf@gg.bug.org>
	<sgitq1eerj@opaopa.org> <87k8ahmduk.fsf@gg.bug.org>
	<sgpuk7evox@opaopa.org> <87itpz7rnp.fsf@gg.bug.org>
	<sglmuuvraq@opaopa.org>
Message-ID: <877l61k0xn.fsf@gg.bug.org>

上野です。

>>>>> In [Wanderlust : No.06127] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> > それは岡田さんの仰る、実地での利用にもとづく評価次第なのですが。^_^;;
> > ひとまず個人的には FLIM 1.14 に merge した時点で、freeze したつもりです。
> > ;; これにより、現状の SLIM の、肥大化した API は obsolete としたいです。

> 当面は、Wanderlust, (T-Gnus?) あたりが利用するだけなので、
> APIの変更に伴なうバージョンアップを強いてもいいかなとも思っていたりします．
> ;; あんまり変更が激しくてユーザから敬遠されるのも悲しいですが．

API の『変更』というのは SLIM という岡田さんの個人枝を利用していた場合に生じる
ものなので、強いる必要もないと思います。

そもそも、SLIM が Wanderlust に完全に組込まれる以前から、toplevel API の
欠如は示してきましたし、仮に SASL 機能の一部を利用できたとしても、あくまで
実験的なものであるということは、何度となく言ってきたつもりですが？

;; Gnus では digest-md5.el 以外利用しないように (つまり SLIM が必要な
;; sasl.el を require しないように) あえて頼んであります。

> とりあえず、wl-2_5ができて暫くしたら FLIM 1.14のsasl.elを利用するように
> 変更してみようと思います．
> 古いSLIMでも動くような配慮も、余裕があればやろうと思います．
> ;; しなくてもいいかな．

しなくても良いと思います。むしろ、しないでください。

本当に善意で、ソフトウェアの寿命を延ばそうという意思があるのなら、
Wanderlust のコードを新しい API を利用するように変更した上で、
SLIM の API を現状の FLIM に合わせれば済むことではないかと思います。
-- 
Daiki Ueno



From okada ＠ opaopa.org  Mon Nov 20 04:03:52 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Mon, 20 Nov 2000 04:03:52 +0900
Subject: sasl-digest-md5
Message-ID: <sghf53rdgn@opaopa.org>

おかだです．

flim-1_14 の sasl-digest.el において、サーバからのqopを
そのまま利用していますが、

> qop 
>   Indicates what "quality of protection" the client accepted. If 
>   present, it may appear exactly once and  its value MUST be one of the 
>   alternatives in qop-options. If not present, it defaults to "auth". 
>   These values affect the computation of the response. Note that this 
>   is a single token, not a quoted list of alternatives. 

ということだそうです．
qop="auth,auth-int,auth-conf" でなく、qop="auth" とか、みたいです．

SLIM版では、サーバからのqopは捨てていたために、問題が露呈しなかっただけ
のようです．

あと、

> If the "qop" value is "auth-int" or "auth-conf" then A2 is: 
> 
>   A2       = { "AUTHENTICATE:", digest-uri-value,  
>            ":00000000000000000000000000000000" } 

だそうですが、auth-int のみしか :00000..0 にならないようです．

ただ、わたしが sendmail-8.11.1 +SMTP AUTH で試したところ、
"auth"のみ動いて、"auth-int" "auth-conf"では認証が失敗するようです．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From okada ＠ opaopa.org  Mon Nov 20 07:54:01 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Mon, 20 Nov 2000 07:54:01 +0900
Subject: sasl-digest-md5
In-Reply-To: <sghf53rdgn@opaopa.org>
References: <sghf53rdgn@opaopa.org>
Message-ID: <sghf53h8ty@opaopa.org>

おかだです。

In the message <sghf53rdgn ＠ opaopa.org>
okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> flim-1_14 の sasl-digest.el において、サーバからのqopを
> そのまま利用していますが、

> > qop 
> >   Indicates what "quality of protection" the client accepted. If 
> >   present, it may appear exactly once and  its value MUST be one of the 
> >   alternatives in qop-options. If not present, it defaults to "auth". 
> >   These values affect the computation of the response. Note that this 
> >   is a single token, not a quoted list of alternatives. 

> ということだそうです．
> qop="auth,auth-int,auth-conf" でなく、qop="auth" とか、みたいです．

修正ありがとうございます．DIGEST-MD5で認証できるようになりました．

あと、qopはpropertyで指定できるようになりましたが、
サーバの返す qop-options に含まれるか確認することが必要だと思います．

;; わざわざ qop を指定する人もいないと思いますが…

> > If the "qop" value is "auth-int" or "auth-conf" then A2 is: 
> > 
> >   A2       = { "AUTHENTICATE:", digest-uri-value,  
> >            ":00000000000000000000000000000000" } 

> だそうですが、auth-int のみしか :00000..0 にならないようです．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From okada ＠ opaopa.org  Mon Nov 20 09:01:01 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Mon, 20 Nov 2000 09:01:01 +0900
Subject: sendmail user-name
Message-ID: <sg7l5zh5qa@opaopa.org>

おかだです．

sendmail + cyrus-sasl で、sasldb を使っている場合、
DIGEST-MD5 以外の認証方式を使う場合は、username として
"kokada ＠ domain" のような形式を使う必要があります．
DIGEST-MD5 では、usernameとして"kokada"、realmに"domain"を設定する
必要があります．
以前は、smtp.el で対処していましたが、現在はどこで対処するべきでしょうか？

案
1. username, realm はユーザがメカニズムごとに指定する．
2. ユーザ設定は"username ＠ domain"として、DIGEST-MD5の場合のみ
   smtp.elに渡す前に realmを抽出する．
   (現在のwl-draft.elはこうなっています)
3. smtp.elで2のような対処をする．

;; sendmail以外と共存することを考えると 1 なのかな．
;; 設定項目が増えてしまいますが．

ちなみに、生のsmtp.elを使って、SMTP AUTHする際には、

(setq smtp-use-sasl t
      smtp-sasl-mechanisms '("CRAM-MD5")
      smtp-sasl-principal-name "kokada ＠ inari")
や
(setq smtp-use-sasl t
      smtp-sasl-mechanisms '("DIGEST-MD5")
      smtp-sasl-principal-name "kokada"
      smtp-sasl-properties '(realm "inari"))
とする必要があるようです．

;; Claus Assmann さんに質問したら、SASLよくわからんと言っていたので、
;; sendmailの実装は間違っているのかもしれません．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From ueno ＠ bug.org  Mon Nov 20 12:58:17 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 20 Nov 2000 12:58:17 +0900
Subject: sasl-digest-md5
In-Reply-To: <sghf53h8ty@opaopa.org>
References: <sghf53rdgn@opaopa.org> <sghf53h8ty@opaopa.org>
Message-ID: <87k89zuwfa.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00656] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> あと、qopはpropertyで指定できるようになりましたが、
> サーバの返す qop-options に含まれるか確認することが必要だと思います．

> ;; わざわざ qop を指定する人もいないと思いますが…

ありがとうございます。

実はまだ一貫性/機密性保護のコードを用意していないので、auth 以外の
qop が指定された場合には、とりあえずエラーを返すようにしておきました。
-- 
Daiki Ueno
The large print giveth and the small print taketh away.



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 14:08:53 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 14:08:53 +0900
Subject: mailcap.el
In-Reply-To: Daiki Ueno's message of "13 Nov 2000 05:49:52 +0900"
Message-ID: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>

mailcap.el が Gnus のとぶつかるという問題ですが、

(a) Gnus の mailcap.el と FLIM の mailcap.el を一本化して、同じものを
    両者で使う

(b) FLIM の mailcap.el を別の名前にする

(c) Gnus の mailcap.el を別の名前に変えてもらう :-)

という解決法が考えられますが、とりあえず (b) で行こうかと思うのですが
いかがでしょうか？その上で、(a) の方策を検討してみたいと思います。

(b) の場合、どういう名前にするかが問題となりますが、とりあえず

  (b-1) mime-conf.el

を提案します。

御意見お待ちしております。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From yamaoka ＠ jpl.org  Fri Nov 24 14:19:09 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 24 Nov 2000 14:19:09 +0900
Subject: mailcap.el
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <yosu8zqahrqq.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00659] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

守岡さん> mailcap.el が Gnus のとぶつかるという問題ですが、

守岡さん> (a) Gnus の mailcap.el と FLIM の mailcap.el を一本化して、
守岡さん>     同じものを両者で使う

守岡さん> (b) FLIM の mailcap.el を別の名前にする

守岡さん> (c) Gnus の mailcap.el を別の名前に変えてもらう :-)

守岡さん> という解決法が考えられますが、とりあえず (b) で行こうかと思
守岡さん> うのですがいかがでしょうか？

賛成です。
T-gnus には長い間 gnus-mailcap.el に改名したものを無用の長物として納め
ていましたが、ずっと気になっていました。

守岡さん> その上で、(a) の方策を検討してみたいと思います。

守岡さん> (b) の場合、どういう名前にするかが問題となりますが、とりあえ
守岡さん> ず
守岡さん>   (b-1) mime-conf.el
守岡さん> を提案します。

よろしいのではないでしょうか。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 15:25:08 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 15:25:08 +0900
Subject: mailcap.el
In-Reply-To: Katsumi Yamaoka's message of "24 Nov 2000 14:19:09 +0900"
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
Message-ID: <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> In [emacs-mime-ja : No.00660] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

守岡>> (b) の場合、どういう名前にするかが問題となりますが、とりあえ
守岡>> ず
守岡>>   (b-1) mime-conf.el
守岡>> を提案します。

山岡さん> よろしいのではないでしょうか。

この案で行く場合に、現行 mailcap.el の API である

	関数 mailcap-parse-buffer (&optional buffer order)

	利用者選択肢（変数） mailcap-file

	関数 mailcap-parse-file (&optional filename order)

	関数 mailcap-format-command (mtext situation)

をそれぞれ

	関数 mime-parse-mailcap-buffer (&optional buffer order)

	利用者選択肢（変数） mime-mailcap-file

	関数 mime-parse-mailcap-file (&optional filename order)

	関数 mime-format-mailcap-command (mtext situation)

に変更し、また、当面、新しい API に対する obsolete-alias として
mailcap-parse-buffer, mailcap-parse-file, mailcap-format-command を提
供する mailcap.el を設けようと思いますがいかがでしょうか？

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From yamaoka ＠ jpl.org  Fri Nov 24 15:38:12 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 24 Nov 2000 15:38:12 +0900
Subject: mailcap.el
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosu8zqahrqq.fsf@jpl.org>
	<htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <yosuofz5ho2z.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00661] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

守岡さん> (b-1) mime-conf.el
守岡さん> を提案します。

山岡> よろしいのではないでしょうか。

守岡さん> この案で行く場合に、現行 mailcap.el の API である

[...]

守岡さん> をそれぞれ

守岡さん> 関数 mime-parse-mailcap-buffer (&optional buffer order)
守岡さん> 利用者選択肢（変数） mime-mailcap-file
守岡さん> 関数 mime-parse-mailcap-file (&optional filename order)
守岡さん> 関数 mime-format-mailcap-command (mtext situation)

守岡さん> に変更し、また、当面、新しい API に対する obsolete-alias と
守岡さん> してmailcap-parse-buffer, mailcap-parse-file,
守岡さん> mailcap-format-command を提供する mailcap.el を設けようと思
守岡さん> いますがいかがでしょうか？

ぼくは異存ありません。

;; 問題は、すでに多くのユーザのみなさんの site-lisp/flim/ などに古い
;; (または現行の) FLIM がインストールされているし、パッケージで供給さ
;; れていたりもすることですね。(^^;;)
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 15:48:38 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 15:48:38 +0900
Subject: mailcap.el
In-Reply-To: Katsumi Yamaoka's message of "24 Nov 2000 15:38:12 +0900"
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
 <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuofz5ho2z.fsf@jpl.org>
Message-ID: <htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> In [emacs-mime-ja : No.00662] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡さん> ;; 問題は、すでに多くのユーザのみなさんの site-lisp/flim/ な
山岡さん> ;; どに古い(または現行の) FLIM がインストールされているし、
山岡さん> ;; パッケージで供給されていたりもすることですね。(^^;;)

これは新しい mailcap API を使った SEMI (1.14?) が古い FLIM 実装で動か
ないという問題ですよね？

それは API が違う以上仕方がないことだと思います。

ただ、今回の提案をうまく実装すれば、古い mailcap API を使った SEMI を
新しい mailcap API を実装する FLIM のもとで動かすことができるというこ
とになります。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From yamaoka ＠ jpl.org  Fri Nov 24 15:58:36 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 24 Nov 2000 15:58:36 +0900
Subject: mailcap.el
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosu8zqahrqq.fsf@jpl.org>
	<htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosuofz5ho2z.fsf@jpl.org>
	<htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <yosuitpdhn4y.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00663] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

山岡> ;; 問題は、すでに多くのユーザのみなさんの site-lisp/flim/ などに
山岡> ;; 古い(または現行の) FLIM がインストールされているし、パッケー
山岡> ;; ジで供給されていたりもすることですね。(^^;;)

守岡さん> これは新しい mailcap API を使った SEMI (1.14?) が古い FLIM 
守岡さん> 実装で動かないという問題ですよね？
守岡さん> それは API が違う以上仕方がないことだと思います。

それもそうなんですが、今まで Emacs 20 を使っている人が、例えばメールの
読み書きは cmail で、ニュースは Emacs 20 に付属している Gnus を使って
いたとします。その人が Emacs を 21 に上げたとたんに load-path の順序に
よっては cmail 側の SEMI が Gnus の mailcap を使ってしまうかもしれない
し、逆に Gnus が (旧) FLIM の mailcap を使ってしまうために起きる障害を
懸念しておりました。

;; 懸念と言うよりは、確実に FAQ になりそうな気がします。(^^;;)
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 16:23:18 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 16:23:18 +0900
Subject: mailcap.el
In-Reply-To: Katsumi Yamaoka's message of "24 Nov 2000 15:58:36 +0900"
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
 <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuofz5ho2z.fsf@jpl.org>
 <htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuitpdhn4y.fsf@jpl.org>
Message-ID: <htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> In [emacs-mime-ja : No.00664] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡> ;; 問題は、すでに多くのユーザのみなさんの site-lisp/flim/ などに
山岡> ;; 古い(または現行の) FLIM がインストールされているし、パッケー
山岡> ;; ジで供給されていたりもすることですね。(^^;;)

守岡>> これは新しい mailcap API を使った SEMI (1.14?) が古い FLIM 
守岡>> 実装で動かないという問題ですよね？
守岡>> それは API が違う以上仕方がないことだと思います。

山岡さん> それもそうなんですが、今まで Emacs 20 を使っている人が、例え
山岡さん> ばメールの読み書きは cmail で、ニュースは Emacs 20 に付属し
山岡さん> ている Gnus を使っていたとします。その人が Emacs を 21 に上
山岡さん> げたとたんに load-path の順序によっては cmail 側の SEMI が 
山岡さん> Gnus の mailcap を使ってしまうかもしれないし、逆に Gnus が (
山岡さん> 旧) FLIM の mailcap を使ってしまうために起きる障害を懸念して
山岡さん> おりました。

山岡さん> ;; 懸念と言うよりは、確実に FAQ になりそうな気がします。(^^;;)

FLIM 1.14 としては、

・Emacs 21 が使われている

とか

・load-path 上にmailcap.el{c} が存在する

という場合に mailcap.el を install しない とか、古い emacs において 
mailcap.el を install する場合には version specific load path に入れる
という方法が考えられますが、これでは不十分でしょうか？もっと良い方策が
あったら教えてください。

なお、過去の FLIM に関してはいかんともしがたいです。かつて、Emacs 20.1
の時に Emacs 21 の etc/NEWS に SEMI に関する注意を記載してもらったよう
に、Emacs 21.1 の etc/NEWS に site-lisp 上の FLIM の mailcap.el{c} を
消すというような注意書きを入れてもらうことはできるのではないかと思いま
すが。

また、Debian GNU system では Emacs 21 が FLIM/SEMI 1.13 実装と
conflict するようにしてもらえれば、問題は起きないでしょう。

また、SEMI 1.14 を入れれば mailcap.el は読まないはずです。


でも、とりあえずここでは FLIM/SEMI API や実装で実現可能な方策に限定し
て議論して頂けると幸いです。

;; FAQ の作成は皆様にお任せ致します。(^_^;;;

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From yamaoka ＠ jpl.org  Fri Nov 24 16:36:37 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 24 Nov 2000 16:36:37 +0900
Subject: mailcap.el
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosu8zqahrqq.fsf@jpl.org>
	<htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosuofz5ho2z.fsf@jpl.org>
	<htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	<yosuitpdhn4y.fsf@jpl.org>
	<htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <yosuem01hldm.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.00665] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

山岡> ;; 懸念と言うよりは、確実に FAQ になりそうな気がします。(^^;;)

守岡さん> FLIM 1.14 としては、

守岡さん> ・Emacs 21 が使われている
守岡さん> とか
守岡さん> ・load-path 上にmailcap.el{c} が存在する

守岡さん> という場合に mailcap.el を install しない とか、古い emacs 
守岡さん> において mailcap.el を install する場合には version specific
守岡さん> load path に入れるという方法が考えられますが、これでは不十分
守岡さん> でしょうか？もっと良い方策があったら教えてください。

いえ、それで十分だと思います。

守岡さん> なお、過去の FLIM に関してはいかんともしがたいです。

[...]

守岡さん> でも、とりあえずここでは FLIM/SEMI API や実装で実現可能な方
守岡さん> 策に限定して議論して頂けると幸いです。

はい、すみませんでした。
本題に関して言えば、守岡さんのご提案内容で十分に合理的だと思います。

守岡さん> ;; FAQ の作成は皆様にお任せ致します。(^_^;;;

;; ぼくが横道に逸れて問題にしている内容は、かなり前にここで提起したこ
;; とでした。しかし、今の今まで自分では何もしなかったのが悔やまれます。
;; たまに Gnus 5.8/5.9 も使っているぼくにとってはあまりに日常的に起き
;; る問題だったので、load-path の入れ替えをプログラムで行なってしまい、
;; 事の重要性を認識できなくなっていました。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From handa ＠ etl.go.jp  Fri Nov 24 16:46:42 2000
From: handa ＠ etl.go.jp (Kenichi Handa)
Date: Fri, 24 Nov 2000 16:46:42 +0900 (JST)
Subject: mailcap.el
In-Reply-To: <htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	(tomo@kanji.zinbun.kyoto-u.ac.jp)
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
 <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuofz5ho2z.fsf@jpl.org>
 <htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuitpdhn4y.fsf@jpl.org> <htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200011240746.QAA00931@etlken.etl.go.jp>

tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) writes:
> なお、過去の FLIM に関してはいかんともしがたいです。かつて、Emacs 20.1
> の時に Emacs 21 の etc/NEWS に SEMI に関する注意を記載してもらったよう
> に、Emacs 21.1 の etc/NEWS に site-lisp 上の FLIM の mailcap.el{c} を
> 消すというような注意書きを入れてもらうことはできるのではないかと思いま
> すが。

現在 etc/NEWS には以下のようなパラグラフがあります。

*** Gnus is now a MIME-capable reader.  This affects many parts of
Gnus, and adds a slew of new commands.  See the manual for details.
Separate MIME packages like RMIME, SEMI, mime-compose etc., will
probably no longer work; remove them and use the native facilities.

ちょっとあんまりな文章なので、これへの修正を下さい。日本語で
も結構です。

−−　けんちゃん＠ＥＴＬ
      handa ＠ etl.go.jp



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 17:03:51 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 17:03:51 +0900
Subject: mailcap.el
In-Reply-To: Kenichi Handa's message of "Fri, 24 Nov 2000 16:46:42 +0900 (JST)"
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
 <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuofz5ho2z.fsf@jpl.org>
 <htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuitpdhn4y.fsf@jpl.org>
 <htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <200011240746.QAA00931@etlken.etl.go.jp>
Message-ID: <htxbsv57q54.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> [emacs-mime-ja : No.00667] にて
>>>>> “Handa”= Kenichi Handa <handa ＠ etl.go.jp> さま曰く:

Handa> > なお、過去の FLIM に関してはいかんともしがたいです。かつて、
Handa> > Emacs 20.1の時に Emacs 21 の etc/NEWS に SEMI に関する注意を
Handa> > 記載してもらったように、Emacs 21.1 の etc/NEWS に site-lisp 
Handa> > 上の FLIM の mailcap.el{c} を消すというような注意書きを入れて
Handa> > もらうことはできるのではないかと思いますが。

Handa> 現在 etc/NEWS には以下のようなパラグラフがあります。

Handa> *** Gnus is now a MIME-capable reader.  This affects many parts of
Handa> Gnus, and adds a slew of new commands.  See the manual for details.
Handa> Separate MIME packages like RMIME, SEMI, mime-compose etc., will
Handa> probably no longer work; remove them and use the native facilities.

Handa> ちょっとあんまりな文章なので、これへの修正を下さい。日本語で
Handa> も結構です。

まだ、FLIM/SEMI 1.14 の release は行ってないので、むしろ、Emacs 21 の
都合に合わせて修正できます。もし、私が現在提案している案で行くならば

Emacs 21 を使う場合は、FLIM/SEMI 1.14 以降を使い、site-lisp 上の FLIM
の mailcap.{el|elc} を消すこと

というような感じになると思います。


もっとも、Emacs 開発者側が SEMI 何かいらないし、共存するつもりもないと
いう立場ならそれでも構わないんですが。

私としては MIME-RMAIL の開発を止めているつもりはないのですが、その場合、
RMAIL 関連の開発は中止します。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━



From handa ＠ etl.go.jp  Fri Nov 24 17:26:30 2000
From: handa ＠ etl.go.jp (Kenichi Handa)
Date: Fri, 24 Nov 2000 17:26:30 +0900 (JST)
Subject: mailcap.el
In-Reply-To: <htxbsv57q54.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	(tomo@kanji.zinbun.kyoto-u.ac.jp)
References: <htxhf4ydkii.fsf_-_@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosu8zqahrqq.fsf@jpl.org>
 <htxem01evjv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuofz5ho2z.fsf@jpl.org>
 <htxitpdkgqh.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <yosuitpdhn4y.fsf@jpl.org>
 <htxu28xal5l.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 <200011240746.QAA00931@etlken.etl.go.jp> <htxbsv57q54.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200011240826.RAA00987@etlken.etl.go.jp>

tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) writes:
Handa>  現在 etc/NEWS には以下のようなパラグラフがあります。

Handa>  *** Gnus is now a MIME-capable reader.  This affects many parts of
Handa>  Gnus, and adds a slew of new commands.  See the manual for details.
Handa>  Separate MIME packages like RMIME, SEMI, mime-compose etc., will
Handa>  probably no longer work; remove them and use the native facilities.

Handa>  ちょっとあんまりな文章なので、これへの修正を下さい。日本語で
Handa>  も結構です。

> まだ、FLIM/SEMI 1.14 の release は行ってないので、むしろ、Emacs 21 の
> 都合に合わせて修正できます。もし、私が現在提案している案で行くならば

> Emacs 21 を使う場合は、FLIM/SEMI 1.14 以降を使い、site-lisp 上の FLIM
> の mailcap.{el|elc} を消すこと

> というような感じになると思います。

では、以下のような修正の提案をすれば良いですね？

*** Gnus is now a MIME-capable reader.  This affects many parts of
Gnus, and adds a slew of new commands.  See the manual for details.
Separate MIME packages like RMIME, mime-compose etc., will probably no
longer work; remove them and use the native facilities.

If you have already installed FLIM/SEMI of the version 1.13 or the
earlier, you must remove mailcap.el[c] which was installed by
FLIM/SEMI.  And to use FLIM/SEMI on Emacs 21, you must install the
version 1.14 or the later.

ところで、 FLIM/SEMI 1.13 以前のものを Emacs 21 でも使い続けようと思っ
たら、mailcap はどうせ site-lisp にあるやつが優先されるので、何もしな
いで良いのですよね？

> もっとも、Emacs 開発者側が SEMI 何かいらないし、共存するつもりもないと
> いう立場ならそれでも構わないんですが。

> 私としては MIME-RMAIL の開発を止めているつもりはないのですが、その場合、
> RMAIL 関連の開発は中止します。

すでに Emacs 21 のプリテストが始まってしまったので、相当緊急に
rmail-mime が完成しないと、 21.1 に入れての出荷は無理です。開発のスケ
ジュールはどうでしょうか？もちろん 21.1 には間に合わなくとも、21.2 に
は間に合うので、是非完成はさせて欲しいのですが。

−−　けんちゃん＠ＥＴＬ
      handa ＠ etl.go.jp



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Nov 24 21:45:57 2000
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 24 Nov 2000 21:45:57 +0900
Subject: semi-1_14
In-Reply-To: tomo@kanji.zinbun.kyoto-u.ac.jp's message of "25 Oct 2000 15:00:45 +0900"
Message-ID: <htxwvdth722.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

semi-1_14 枝を作りました。

今の所、remi-1_14 枝の最終版の中身が入っています。

commiter の皆様、今後は semi-1_13 枝、remi-1_14 枝に代わり、semi-1_14 
を公式開発枝として使ってください。


ところで、SEMI 1.14 から、配布 package は APEL, FLIM を含めたものにし
ようかなと思っているのですが、どう思われますか。御意見お聞かせください。

;; FLIM 1.14 の方の御意見もお待ちしております。

;;; とりあえず、試作は行いました。commit は御意見待ちです。
-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From ichikawa ＠ eitc.epson.com  Sun Nov 26 15:25:22 2000
From: ichikawa ＠ eitc.epson.com (Tatsuya Ichikawa (Tim - Itchy))
Date: 25 Nov 2000 22:25:22 -0800
Subject: smtp.el in slim-1_14 branch on Meadow.
Message-ID: <wkpujji71p.fsf@meadow.erc.epson.com>

市川です。

  User-Agent 環境で SLIM 1_14 を使用し、T-gnus の message.el から call
  されている smtp.el の smtp-send-buffer 関数が常に nil を返すために
  smtp 経由での送信に成功しても、下記のコードのため

    (if recipients
	(let ((result (static-if (fboundp 'smtp-send-buffer)
			  (smtp-send-buffer user-mail-address recipients
					    (current-buffer))
			(smtp-via-smtp user-mail-address
				       recipients
				       (current-buffer)))))
	  (unless (eq result t)
	    (error "Sending failed; " result)))

  (error "Sending failed; " result) が評価されます。
  従って、送信に成功しても必ず Sending failed が表示され、一見送信に失敗
  してしまったかのような風に見えてしまいます。

  追いかけ行くと、smtp.el の smtp-close-conection 関数の delete-process
  が Meadow の場合ですと(といっても、他の Platform はわかりませんが) nil
  を返して来るのが原因のようです。
  ただし、ここで常に t を返してしまっていいものかどうかの判断が…はっき
  り言って私にはつきません。(現状は smtp-submit-package 関数の最後で t
  を返すようにしています)

  私だけの環境の問題なのか、それとも User-Agent 環境では発生するものなの
  かがいまいち、確定できません。

  他の Platform の方は、いかがでしょうか??

-- 
  Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From okada ＠ opaopa.org  Sun Nov 26 16:06:04 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Sun, 26 Nov 2000 16:06:04 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <wkpujji71p.fsf@meadow.erc.epson.com>
References: <wkpujji71p.fsf@meadow.erc.epson.com>
Message-ID: <sg1yvzkyar@opaopa.org>

おかだです。

In the message <wkpujji71p.fsf ＠ meadow.erc.epson.com>
Tatsuya (Tim - Itchy) Ichikawa <ichikawa ＠ eitc.epson.com> wrote:

>   User-Agent 環境で SLIM 1_14 を使用し、T-gnus の message.el から call
>   されている smtp.el の smtp-send-buffer 関数が常に nil を返すために
>   smtp 経由での送信に成功しても、下記のコードのため
..
>   (error "Sending failed; " result) が評価されます。
>   従って、送信に成功しても必ず Sending failed が表示され、一見送信に失敗
>   してしまったかのような風に見えてしまいます。

わたしの環境でも nil を返します． FLIM-1_14, DEISUI-1_14 に共通した
仕様だと思います．

(if recipients
    (let ((result (static-if (fboundp 'smtp-send-buffer)
		      (condition-case error
			  (progn
			    (smtp-send-buffer user-mail-address recipients
					      (current-buffer))
			    t)
			(error
			 (format "%d %s"
				 (car (cdr error)) (cdr (cdr error)))))
		    (smtp-via-smtp user-mail-address
				   recipients
				   (current-buffer)))))
      (unless (eq result t)
	(error "Sending failed; %s" result))))

とかでしょうか．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From ichikawa ＠ eitc.epson.com  Sun Nov 26 17:06:46 2000
From: ichikawa ＠ eitc.epson.com (Tatsuya Ichikawa (Tim - Itchy))
Date: 26 Nov 2000 00:06:46 -0800
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <sg1yvzkyar@opaopa.org> (=?ISO-2022-JP?B?GyRCMixFRBsoQiA=?=
 =?ISO-2022-JP?B?GyRCN3IwbBsoQg==?= / Kenichi OKADA's message of "Sun, 26
 Nov 2000 16:06:04 +0900")
References: <wkpujji71p.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
Message-ID: <wkn1eni2cp.fsf@meadow.erc.epson.com>

>>>>> In [emacs-mime-ja : No.00672]
>>>>>  okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> >   User-Agent 環境で SLIM 1_14 を使用し、T-gnus の message.el から 
> >   call されている smtp.el の smtp-send-buffer 関数が常に nil を返す
> >   ためにsmtp 経由での送信に成功しても、下記のコードのため
> ..
> >   (error "Sending failed; " result) が評価されます。
> >   従って、送信に成功しても必ず Sending failed が表示され、一見送信に
> >   失敗してしまったかのような風に見えてしまいます。

> わたしの環境でも nil を返します． FLIM-1_14, DEISUI-1_14 に共通した
> 仕様だと思います．

> (if recipients
>     (let ((result (static-if (fboundp 'smtp-send-buffer)
> 		      (condition-case error
> 			  (progn
> 			    (smtp-send-buffer user-mail-address
> 			recipients (current-buffer))
> 			    t)
> 			(error
> 			 (format "%d %s"
> 				 (car (cdr error)) (cdr (cdr error)))))
> 		    (smtp-via-smtp user-mail-address
> 				   recipients
> 				   (current-buffer)))))
>       (unless (eq result t)
> 	(error "Sending failed; %s" result))))

> とかでしょうか．

  Wanderlust では起きない…というと、やはり MUA 側で対処すべき事なんです
  ね。
  ちょいと Semi-gnus ML にでも振ってみます。
  ありがとうございます。

-- 
  Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From k-itou ＠ mori.cs.titech.ac.jp  Sun Nov 26 17:21:48 2000
From: k-itou ＠ mori.cs.titech.ac.jp (=?ISO-2022-JP?B?IktpbmppIEl0b2ggLyAbJEIwS0YjNmA7ShsoQiI=?=)
Date: 26 Nov 2000 17:21:48 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <wkpujji71p.fsf@meadow.erc.epson.com> (Tatsuya (Tim - Itchy) Ichikawa's message of "25 Nov 2000 22:25:22 -0800")
References: <wkpujji71p.fsf@meadow.erc.epson.com>
Message-ID: <rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>

伊藤と申します。

User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 06)
 EMIKO/1.14.0 (Zoomastigophora) FLIM/1.14.0 (Ninokuchi) APEL/10.2
 Emacs/21.0.91 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 07) EMY/1.13.9
 (Art is long, life is short) SLIM/1.14.3 (篠原ともえ) APEL/10.2
 Emacs/21.0.91 (i386-unknown-freebsd3.5.1) MULE/5.0 (SAKAKI)

の環境でも起こります。最初は、 Emacs 21 の問題と思ってました。
同様に、 delete-process で nil が返されているようです。

よく分かっていないのですが、このメールを書いた User-Agent

User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 06) EMY/1.13.9
 (Art is long, life is short) SLIM/1.14.3 (篠原ともえ) APEL/10.2
 Emacs/20.7 (i386-unknown-freebsdelf3.4) MULE/4.1 (AOI)

では、エラーは出ません。本来の原因ってどこなのでしょう？ 
delete-process の返り値が、それぞれの Emacs で違うということでしょうか？

>>>>> In [emacs-mime-ja : No.00671] 
>>>>>	Tatsuya (Tim - Itchy) Ichikawa <ichikawa ＠ eitc.epson.com> wrote:
> 市川です。

>   User-Agent 環境で SLIM 1_14 を使用し、T-gnus の message.el から call
>   されている smtp.el の smtp-send-buffer 関数が常に nil を返すために
>   smtp 経由での送信に成功しても、下記のコードのため

>     (if recipients
> 	(let ((result (static-if (fboundp 'smtp-send-buffer)
> 			  (smtp-send-buffer user-mail-address recipients
> 					    (current-buffer))
> 			(smtp-via-smtp user-mail-address
> 				       recipients
> 				       (current-buffer)))))
> 	  (unless (eq result t)
> 	    (error "Sending failed; " result)))

>   (error "Sending failed; " result) が評価されます。
>   従って、送信に成功しても必ず Sending failed が表示され、一見送信に失敗
>   してしまったかのような風に見えてしまいます。

>   追いかけ行くと、smtp.el の smtp-close-conection 関数の delete-process
>   が Meadow の場合ですと(といっても、他の Platform はわかりませんが) nil
>   を返して来るのが原因のようです。
>   ただし、ここで常に t を返してしまっていいものかどうかの判断が…はっき
>   り言って私にはつきません。(現状は smtp-submit-package 関数の最後で t
>   を返すようにしています)

>   私だけの環境の問題なのか、それとも User-Agent 環境では発生するものなの
>   かがいまいち、確定できません。

>   他の Platform の方は、いかがでしょうか??

> -- 
>   Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From ichikawa ＠ eitc.epson.com  Sun Nov 26 17:34:01 2000
From: ichikawa ＠ eitc.epson.com (Tatsuya Ichikawa (Tim - Itchy))
Date: 26 Nov 2000 00:34:01 -0800
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp> (Kinji Itoh /
 =?ISO-2022-JP?B?GyRCMEtGIzZgO0obKEIncw==?= message of "26 Nov 2000 17:21:48
 +0900")
References: <wkpujji71p.fsf@meadow.erc.epson.com>
	<rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>
Message-ID: <wksnofceti.fsf@meadow.erc.epson.com>

「ちむ」です。

;; Semi-gnus ML にも Cc しておきます。

>>>>> In [emacs-mime-ja : No.00674]
>>>>>  "Kinji Itoh / 伊藤謹司" <k-itou ＠ mori.cs.titech.ac.jp> wrote:

> User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 06)
>  EMIKO/1.14.0 (Zoomastigophora) FLIM/1.14.0 (Ninokuchi) APEL/10.2
>  Emacs/21.0.91 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

> User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 07)
> EMY/1.13.9 (Art is long, life is short) SLIM/1.14.3 (篠原ともえ)
> APEL/10.2
>  Emacs/21.0.91 (i386-unknown-freebsd3.5.1) MULE/5.0 (SAKAKI)

> の環境でも起こります。最初は、 Emacs 21 の問題と思ってました。
> 同様に、 delete-process で nil が返されているようです。

> よく分かっていないのですが、このメールを書いた User-Agent

> User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 06)
> EMY/1.13.9 (Art is long, life is short) SLIM/1.14.3 (篠原ともえ)
> APEL/10.2
>  Emacs/20.7 (i386-unknown-freebsdelf3.4) MULE/4.1 (AOI)

> では、エラーは出ません。本来の原因ってどこなのでしょう？
> delete-process の返り値が、それぞれの Emacs で違うということでしょうか？

  ふみゅぅ、良くわからなくなって来ました。

    "Meadow-1.13 Beta1++ (TANAHASHI:61)" (emacs 20.7) ... NG
    Emacs/20.7 (i386-unknown-freebsdelf3.4)           ... OK
    Emacs/21.0.91                                     ... NG

  ですか…
  伊藤さん、ところで OK の環境での delete-process (というか
  smtp-send-buffer の戻り値)はどうなっていますか??
  これを見ない事には、犯人は決められないような…

-- 
  Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From ueno ＠ bug.org  Sun Nov 26 17:49:18 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 26 Nov 2000 17:49:18 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <wkn1eni2cp.fsf@meadow.erc.epson.com>
References: <wkpujji71p.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
	<wkn1eni2cp.fsf@meadow.erc.epson.com>
Message-ID: <87g0kfp181.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00673] 
>>>>>	Tatsuya (Tim - Itchy) Ichikawa <ichikawa ＠ eitc.epson.com> wrote:

> > >   User-Agent 環境で SLIM 1_14 を使用し、T-gnus の message.el から 
> > >   call されている smtp.el の smtp-send-buffer 関数が常に nil を返す
> > >   ためにsmtp 経由での送信に成功しても、下記のコードのため
> > ..
> > >   (error "Sending failed; " result) が評価されます。
> > >   従って、送信に成功しても必ず Sending failed が表示され、一見送信に
> > >   失敗してしまったかのような風に見えてしまいます。

[...]

>   Wanderlust では起きない…というと、やはり MUA 側で対処すべき事なんです
>   ね。

「対処すべき」というより「何もしない」のが正解だと思います。

;; 実際、Wanderlust では何ら特別なことはしていませんよね。

;; わざわざ backward compatible な smtp-via-smtp の界面を残してあるのに、
;; smtp-send-buffer の存在を調べるコードを含める理由がわからないのですが...。

↓の変更を元に戻せば、全て解決するのではないでしょうか。

2000-11-21  Katsumi Yamaoka <yamaoka ＠ jpl.org>

        * lisp/message.el (message-send-mail-with-smtp): Use
        `smtp-send-buffer' if it exists instead of `smtp-via-smtp'.

もしどうしても smtp-send-buffer を使いたいなら、
以下のようにするのが良いと思います。

(if recipients
    (static-if (fboundp 'smtp-send-buffer)
	(smtp-send-buffer user-mail-address recipients (current-buffer))
      (let ((result (smtp-via-smtp user-mail-address
				   recipients
				   (current-buffer))))
	(unless (eq result t)
	  (error "Sending failed; " result)))
-- 
Daiki Ueno
;; 既にあきらめの境地...(;_;)



From ichikawa ＠ eitc.epson.com  Sun Nov 26 18:31:51 2000
From: ichikawa ＠ eitc.epson.com (Tatsuya Ichikawa (Tim - Itchy))
Date: 26 Nov 2000 01:31:51 -0800
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <87g0kfp181.fsf@gg.bug.org>
 (Daiki Ueno's message of "26 Nov 2000 17:49:18 +0900")
References: <wkpujji71p.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
	<wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
Message-ID: <wklmu7cc54.fsf@meadow.erc.epson.com>

市川です。

>>>>> In [emacs-mime-ja : No.00676]
>>>>>  Daiki Ueno <ueno ＠ bug.org> wrote:

> 「対処すべき」というより「何もしない」のが正解だと思います。

  :-p
  「対処」してしまいました。

> ;; 実際、Wanderlust では何ら特別なことはしていませんよね。

> ;; わざわざ backward compatible な smtp-via-smtp の界面を残してあるの
> ;; に、smtp-send-buffer の存在を調べるコードを含める理由がわからないの
> ;; ですが...。

> ↓の変更を元に戻せば、全て解決するのではないでしょうか。

> 2000-11-21 Katsumi Yamaoka <yamaoka ＠ jpl.org>

>         * lisp/message.el (message-send-mail-with-smtp): Use
>         `smtp-send-buffer' if it exists instead of `smtp-via-smtp'.

  かもしれません。
  ただ、こうした「理由」は何処かに(うぅ、最近きちんと ML を読んでいない
  から見落としている可能性もありますが)あると思うのです。
  なければ、こういう変更は入らないはずでしょう。

;; 師匠の意見を聞きたいところですが…

> もしどうしても smtp-send-buffer を使いたいなら、
> 以下のようにするのが良いと思います。

> (if recipients
>     (static-if (fboundp 'smtp-send-buffer)
> 	(smtp-send-buffer user-mail-address recipients (current-buffer))
> (let ((result (smtp-via-smtp user-mail-address
> 				   recipients
> 				   (current-buffer))))
> 	(unless (eq result t)
> 	  (error "Sending failed; " result)))

  はうぅ…こっちのがいいかな??
  でも、smtp-via-smtp を「そのまま」利用するのが基本的には正しいのでしょう。

;; もう寝ます。
  
-- 
  Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From k-itou ＠ mori.cs.titech.ac.jp  Sun Nov 26 18:33:02 2000
From: k-itou ＠ mori.cs.titech.ac.jp (Kinji Itoh)
Date: 26 Nov 2000 18:33:02 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <wksnofceti.fsf@meadow.erc.epson.com> (Tatsuya (Tim - Itchy) Ichikawa's message of "26 Nov 2000 00:34:01 -0800")
References: <wkpujji71p.fsf@meadow.erc.epson.com> <rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp> <wksnofceti.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org> <wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
Message-ID: <rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>

伊藤です。

>>>>> In [semi-gnus-ja : No.5687] 
>>>>>	Tatsuya (Tim - Itchy) Ichikawa <ichikawa ＠ eitc.epson.com> wrote:
...snip
> > では、エラーは出ません。本来の原因ってどこなのでしょう？
> > delete-process の返り値が、それぞれの Emacs で違うということでしょうか？

>   ふみゅぅ、良くわからなくなって来ました。

>     "Meadow-1.13 Beta1++ (TANAHASHI:61)" (emacs 20.7) ... NG
>     Emacs/20.7 (i386-unknown-freebsdelf3.4)           ... OK
>     Emacs/21.0.91                                     ... NG

>   ですか…
>   伊藤さん、ところで OK の環境での delete-process (というか
>   smtp-send-buffer の戻り値)はどうなっていますか??
>   これを見ない事には、犯人は決められないような…

すいません。 Emacs/20.7 の方は T-gnus が単純に古かっただけのようです。
T-gnus の送信部分が、 11/21 に変更されているとは思わなかったので (^^;

ということで、

>>>>> In [emacs-mime-ja : No.00676] 
>>>>>	Daiki Ueno <ueno ＠ bug.org> wrote:
...snip
> ;; わざわざ backward compatible な smtp-via-smtp の界面を残してあるのに、
> ;; smtp-send-buffer の存在を調べるコードを含める理由がわからないのですが...。

> ↓の変更を元に戻せば、全て解決するのではないでしょうか。

> 2000-11-21  Katsumi Yamaoka <yamaoka ＠ jpl.org>

>         * lisp/message.el (message-send-mail-with-smtp): Use
>         `smtp-send-buffer' if it exists instead of `smtp-via-smtp'.

> もしどうしても smtp-send-buffer を使いたいなら、
> 以下のようにするのが良いと思います。

> (if recipients
>     (static-if (fboundp 'smtp-send-buffer)
> 	(smtp-send-buffer user-mail-address recipients (current-buffer))
>       (let ((result (smtp-via-smtp user-mail-address
> 				   recipients
> 				   (current-buffer))))
> 	(unless (eq result t)
> 	  (error "Sending failed; " result)))

のようですので、山岡さん待ちでしょうか？ :-P

-- 
Kinji Itoh <k-itou ＠ mori.cs.titech.ac.jp>



From ichikawa ＠ eitc.epson.com  Sun Nov 26 18:49:49 2000
From: ichikawa ＠ eitc.epson.com (Tatsuya Ichikawa (Tim - Itchy))
Date: 26 Nov 2000 01:49:49 -0800
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>
 (Kinji Itoh's message of "26 Nov 2000 18:33:02 +0900")
References: <wkpujji71p.fsf@meadow.erc.epson.com>
	<rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>
	<wksnofceti.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
	<wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
	<rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>
Message-ID: <wkitpbcbb6.fsf@meadow.erc.epson.com>

市川です。

>>>>> In [semi-gnus-ja : No.5688]
>>>>>  Kinji Itoh <k-itou ＠ mori.cs.titech.ac.jp> wrote:

> すいません。 Emacs/20.7 の方は T-gnus が単純に古かっただけのようです。
> T-gnus の送信部分が、 11/21 に変更されているとは思わなかったので (^^;

> ということで、

> のようですので、山岡さん待ちでしょうか？ :-P

  CVS の T-gnus 枝は元に戻しておきます。
  山岡さん待ち…ですね。

;; 個人的には、これでは困るんで、smtp-via-smtp を使うように変更しておこ
;; う…

-- 
  Tim - Itchy- Ichikawa <ichikawa ＠ eitc.epson.com>



From okada ＠ opaopa.org  Sun Nov 26 20:36:32 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Sun, 26 Nov 2000 20:36:32 +0900
Subject: broken mime-example
Message-ID: <sglmu7klrz@opaopa.org>

おかだです．

.mime-exampleが、なんらかの理由で壊れている場合、
emacs-20.7 などで、SEMI をバイトコンパイルすると、

While compiling toplevel forms in file /home/kokada/cvs/m17n/semi/mime-pgp.el:
  !! error (("Invalid character: 0331200, 111232, 0x1b280"))

のようなエラーが出るようです．
;; いろんな環境で SEMI を使っていると壊れることがあるみたいです…

どこが悪いのか、なかなかわかり難いそうなので、

-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: mime-example.dif
型:         application/octet-stream
サイズ:     768 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20001126/f7865583/attachment.obj>
-------------- next part --------------

というのを入れませんか？

;; もちろん、壊れないのが一番なんですが．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org

From okada ＠ opaopa.org  Sun Nov 26 20:59:33 2000
From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= /
 Kenichi OKADA)
Date: Sun, 26 Nov 2000 20:59:33 +0900
Subject: broken mime-example
In-Reply-To: <sglmu7klrz@opaopa.org>
References: <sglmu7klrz@opaopa.org>
Message-ID: <sgk89rkkpm@opaopa.org>

おかだです。

うえのさんに教えてもらいましたが、

In the message <sglmu7klrz ＠ opaopa.org>
okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> .mime-exampleが、なんらかの理由で壊れている場合、
> emacs-20.7 などで、SEMI をバイトコンパイルすると、
>
> While compiling toplevel forms in file /home/kokada/cvs/m17n/semi/mime-pgp.el:
>   !! error (("Invalid character: 0331200, 111232, 0x1b280"))
>
> のようなエラーが出るようです．

そもそも、該当の部分をmake時に読み込む必要はないですよね．

-- 
岡田 健一  URLs: mailto:okada ＠ opaopa.org
	   	 http://www.opaopa.org



From k-itou ＠ mori.cs.titech.ac.jp  Mon Nov 27 01:12:16 2000
From: k-itou ＠ mori.cs.titech.ac.jp (Kinji Itoh)
Date: 27 Nov 2000 01:12:16 +0900
Subject: semi-1_14
In-Reply-To: <htxwvdth722.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's
 message of "24 Nov 2000 21:45:57 +0900")
References: <htxwvdth722.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <rhtitpag1b3.fsf@pandora.mori.cs.titech.ac.jp>

伊藤です。

>>>>> In [emacs-mime-ja : No.00670] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:
> semi-1_14 枝を作りました。

> 今の所、remi-1_14 枝の最終版の中身が入っています。

> commiter の皆様、今後は semi-1_13 枝、remi-1_14 枝に代わり、semi-1_14 
> を公式開発枝として使ってください。


> ところで、SEMI 1.14 から、配布 package は APEL, FLIM を含めたものにし
> ようかなと思っているのですが、どう思われますか。御意見お聞かせください。

> ;; FLIM 1.14 の方の御意見もお待ちしております。

> ;;; とりあえず、試作は行いました。commit は御意見待ちです。

あまり意見がないようなので、内情をよく知っていない、いい加減な1ユーザ
の意見として
...どういうレベルの意見を期待しているのか分かっていないのでかなりアホ
な意見かも

一緒にするメリットとして、依存するElispパッケージを別々に取ってきてイ
ンストールするのは面倒だからと考えていいのでしょうか。

しかし、FreeBSD などでは、SEMIやFLIM、APELのパッケージがあり、勝手に依
存するパッケージを取ってきてインストールしてくれます。追っかけていない
人はこれで十分です。

Meadowでも最初から含まれていますよね。

あと、 APEL は SKK とかで使っていますが、SKKを追っかけている人だと、
APEL を常に最新にしていて、 SEMI を入れたら APEL を入れ直しなんてこと
になる可能性があると思うのですが。まあ、そんな人はいない？

FreeBSDのパッケージを作る人も、SKKとかがAPELを使うので、配布パッケージ
は別々になってしまう気がします。

追っかけている人は、CVS で取ってくるのであまり関係ないですね。

ただ、SEMIなどのパッケージがない UNIX システムに新たにインストールする
ときは一緒であると便利です。

フリーの UNIX 環境に浸っている人やMeadowを使っている人に使われないこと
と、Elispパッケージを一緒にするメンテナンスの手間とかを考えると、一緒
にするメリットがあまりないように感じてしまいます。もう、システムができ
ていてメンテナンス手間はかからないというんでしたら、一緒にするものを別
に用意してくれる分、便利です。

あとは、いろんな枝があり、FLIM、SEMIの依存関係が分かりにくいので、一緒
にしてくれるのはありがたいです。わざわざ、依存関係を説明する手間も省け
ると思います。

ただ、APEL に関する依存関係は、とりあえず、最新にすればいいと考えてい
いんですよね。また、FLIMを使ってSEMIを使わない、Elispパッケージってほ
とんどないですよね。

ということで、 FLIM と SEMI を合わせたElispパッケージがあると一番いい
ような気がするのですが。FreeBSDのパッケージとかにも使われると思います
し。

でも、考えてみたらFreeBSDのportsでインストールのときにはまとめたElisp
パッケージをを取ってきてインストールするときにAPELをインストールしなけ
ればいいだけか、、、って、ports 作成者でも何でもないのですが (^^;

ということで、SEMIに、APEL、FLIMを含めて欲しいです。

-- 
Kinji Itoh <k-itou ＠ mori.cs.titech.ac.jp>



From ueno ＠ bug.org  Mon Nov 27 01:12:38 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 27 Nov 2000 01:12:38 +0900
Subject: broken mime-example
In-Reply-To: <sgk89rkkpm@opaopa.org>
References: <sglmu7klrz@opaopa.org> <sgk89rkkpm@opaopa.org>
Message-ID: <87elzy90g9.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00681] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> うえのさんに教えてもらいましたが、

うーむ。単に呟いただけなのですが...。

> > .mime-exampleが、なんらかの理由で壊れている場合、
> > emacs-20.7 などで、SEMI をバイトコンパイルすると、
> >
> > While compiling toplevel forms in file /home/kokada/cvs/m17n/semi/mime-pgp.el:
> >   !! error (("Invalid character: 0331200, 111232, 0x1b280"))
> >
> > のようなエラーが出るようです．

> そもそも、該当の部分をmake時に読み込む必要はないですよね．

具体的には、現在 mime-view の toplevel に書かれている、
mime-{preview|acting}-siguation-example-list の設定箇所を
(eval-after-load "mime-view" ...) で括って、semi-setup.el に入れてしまえ
ばどうかと思うのですが、如何でしょうか？
-- 
Daiki Ueno



From yamaoka ＠ jpl.org  Mon Nov 27 08:38:32 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 27 Nov 2000 08:38:32 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
References: <wkpujji71p.fsf@meadow.erc.epson.com>
 <rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>
 <wksnofceti.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
 <wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
 <rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>
 <wkitpbcbb6.fsf@meadow.erc.epson.com>
Message-ID: <yosu8zq6mhhj.fsf@jpl.org>

すみません、みなさんにご迷惑おかけしました。

>>>>> In [emacs-mime-ja : No.00679] 
>>>>>	Tatsuya (Tim - Itchy) Ichikawa <ichikawa ＠ eitc.epson.com> wrote:

Tim> 山岡さん待ち…ですね。

Tim> ;; 個人的には、これでは困るんで、smtp-via-smtp を使うように変更し
Tim> ;; ておこう…

  最近の FLIM の動向がよくわからなくなっていた。
  インストールされた SLIM 1.14 を更新していなかった。
  幹の Wanderlust を make すると `smtp-send-buffer' が無いと言い出した。
  Wanderlust の ChangeLog を見ると寺西さんが変更している。
  最新の SLIM 1.14 には `smtp-send-buffer' が存在し、`smtp-via-smtp'
  が obsolete になっている。よし、Wanderlust に右にならえっ...。

というぼくの行動に、二つの関数の仕様を吟味する、という基本的な要素が抜
けていました。

>>>>> In [emacs-mime-ja : No.00676] 
>>>>>	Daiki Ueno <ueno ＠ bug.org> wrote:

上野さん> 「対処すべき」というより「何もしない」のが正解だと思います。

はい、それでも良いのですが `smtp-via-smtp' が obsolete 宣言されている
FLIM が存在する一方で、

上野さん> ;; わざわざ backward compatible な smtp-via-smtp の界面を残
上野さん> ;; してあるのに、smtp-send-buffer の存在を調べるコードを含め
上野さん> ;; る理由がわからないのですが...。

`smtp-send-buffer' が無い FLIM も存在しています。ぼくとしては obsolete
宣言を「近い将来に `smtp-via-smtp' が無くなる」予告であるととらえて、
`smtp-send-buffer' を優先的に使うようにするのが自然な対応だと思うので
すが。

上野さん> もしどうしても smtp-send-buffer を使いたいなら、
上野さん> 以下のようにするのが良いと思います。

[...]

ううん、このロジックでいいのかしら。ちょっと考えます。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From ueno ＠ bug.org  Mon Nov 27 10:22:30 2000
From: ueno ＠ bug.org (Daiki Ueno)
Date: 27 Nov 2000 10:22:30 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
In-Reply-To: <yosu8zq6mhhj.fsf@jpl.org>
References: <wkpujji71p.fsf@meadow.erc.epson.com>
	<rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>
	<wksnofceti.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
	<wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
	<rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>
	<wkitpbcbb6.fsf@meadow.erc.epson.com> <yosu8zq6mhhj.fsf@jpl.org>
Message-ID: <87aeam43ah.fsf@gg.bug.org>

>>>>> In [emacs-mime-ja : No.00684] 
>>>>>	Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡>  最近の FLIM の動向がよくわからなくなっていた。
山岡>  インストールされた SLIM 1.14 を更新していなかった。

もう何も言いません。(;_;)

山岡> `smtp-send-buffer' が無い FLIM も存在しています。ぼくとしては obsolete
山岡> 宣言を「近い将来に `smtp-via-smtp' が無くなる」予告であるととらえて、
山岡> `smtp-send-buffer' を優先的に使うようにするのが自然な対応だと思うので
山岡> すが。

この obsolete 宣言を入れたのは僕なので、それほど気になるのなら外して下さい。

;; 現在の T-gnus の動作環境は FLIM 1.13 API の実装だったと思うので、
;; 将来のことを気にする必要もないと思うのですが。

上野> もしどうしても smtp-send-buffer を使いたいなら、
上野> 以下のようにするのが良いと思います。

山岡> [...]

山岡> ううん、このロジックでいいのかしら。ちょっと考えます。

個人的な見解としては、smtp-via-smtp は自前で error を全て吸収し、利用者
は、「返り値が t なら送信成功、それ以外なら error と見なす」という界面な
のですが、error を出すべきところでは error を投げるほうが自然ではないで
しょうか。

;; 実際、smtp-via-smtp を利用する T-gnus などでは返り値を調べた上で、
;; 更に error を投げていますよね。これは二度手間ではないかと。

もし、これらの点を御理解頂けた上で、FLIM 1.14 API を使う気があるのでしたら、
当然ながら、smtp-send-buffer の利用をお勧めします。
-- 
Daiki Ueno



From yamaoka ＠ jpl.org  Mon Nov 27 10:44:14 2000
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: 27 Nov 2000 10:44:14 +0900
Subject: smtp.el in slim-1_14 branch on Meadow.
References: <wkpujji71p.fsf@meadow.erc.epson.com>
	<rhtg0kf16ub.fsf@pandora.mori.cs.titech.ac.jp>
	<wksnofceti.fsf@meadow.erc.epson.com> <sg1yvzkyar@opaopa.org>
	<wkn1eni2cp.fsf@meadow.erc.epson.com> <87g0kfp181.fsf@gg.bug.org>
	<rhtzoin6ptd.fsf@pandora.mori.cs.titech.ac.jp>
	<wkitpbcbb6.fsf@meadow.erc.epson.com> <yosu8zq6mhhj.fsf@jpl.org>
	<87aeam43ah.fsf@gg.bug.org>
Message-ID: <yosud7figpe8.fsf@jpl.org>

>>>>> In [semi-gnus-ja : No.5691] 
>>>>>	Daiki Ueno <ueno ＠ bug.org> wrote:

山岡>  最近の FLIM の動向がよくわからなくなっていた。
山岡>  インストールされた SLIM 1.14 を更新していなかった。

上野さん> もう何も言いません。(;_;)

すみません、上野さんが (;_;) と表現される理由もわからないくらいなので、
始めに尋ねれば良かったですね。

上野さん> この obsolete 宣言を入れたのは僕なので、それほど気になるのな
上野さん> ら外して下さい。

上野さん> ;; 現在の T-gnus の動作環境は FLIM 1.13 API の実装だったと思
上野さん> ;; うので、将来のことを気にする必要もないと思うのですが。

おっしゃる通りです。無節操ととられても仕方がありませんが、T-gnus 全体
から見たらわずがな部分における過渡期の対応とさせて下さい。

[...]

山岡> ううん、このロジックでいいのかしら。ちょっと考えます。

上野さん> 個人的な見解としては、smtp-via-smtp は自前で error を全て吸
上野さん> 収し、利用者は、「返り値が t なら送信成功、それ以外なら 
上野さん> error と見なす」という界面なのですが、error を出すべきところ
上野さん> では error を投げるほうが自然ではないでしょうか。

はい、ぼくも上野さんと同様の結論に達しまていました。
先ほど commit したものの ChangeLog です。

  * lisp/message.el (message-send-mail-with-smtp): Leave the error
  handling in `smtp-send-buffer's own care.
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>



From akiho ＠ media.osaka-cu.ac.jp  Mon Nov 27 23:43:57 2000
From: akiho ＠ media.osaka-cu.ac.jp (akiho ＠ media.osaka-cu.ac.jp)
Date: Mon, 27 Nov 2000 23:43:57 +0900
Subject: semi-1_14
In-Reply-To: In your message of "27 Nov 2000 01:12:16 +0900"
	<rhtitpag1b3.fsf@pandora.mori.cs.titech.ac.jp>
References: <htxwvdth722.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	<rhtitpag1b3.fsf@pandora.mori.cs.titech.ac.jp>
Message-ID: <200011272244.HAA04911@mailsv.media.osaka-cu.ac.jp>

秋保です。

In article <rhtitpag1b3.fsf ＠ pandora.mori.cs.titech.ac.jp>
Kinji Itoh <k-itou ＠ mori.cs.titech.ac.jp> writes:

Itoh> あと、 APEL は SKK とかで使っていますが、SKKを追っかけている人だと、
Itoh> APEL を常に最新にしていて、 SEMI を入れたら APEL を入れ直しなんてこと
Itoh> になる可能性があると思うのですが。まあ、そんな人はいない？

えっと、たぶん今回の SEMI のパッケージが配布されるとして、 APEL の入れ直し
は起きないはずです。現在の APEL の最新が SEMI パッケージに含まれるでしょう
から。 SKK で必要になるのは、 APEL 10.2 (ちょっと前は 
This version of Daredevil SKK requires APEL at 2000/10/10 or later
と書いてあったのですが、 APEL 10.2 になりました)なので。

それにリリースされるまでは、色々あるもんだし、maintrunk が Daredevil になっ
て余計に開発速度が速くなったみたい。まぁ、そこら辺はおっかけする人の責任で、
APEL を新しくしてもらうと。新しい APEL は悪さしないはずだから。

Itoh> ということで、 FLIM と SEMI を合わせたElispパッケージがあると一番いい
Itoh> ような気がするのですが。FreeBSDのパッケージとかにも使われると思います
Itoh> し。

Itoh> でも、考えてみたらFreeBSDのportsでインストールのときにはまとめたElisp
Itoh> パッケージをを取ってきてインストールするときにAPELをインストールしなけ
Itoh> ればいいだけか、、、って、ports 作成者でも何でもないのですが (^^;

Itoh> ということで、SEMIに、APEL、FLIMを含めて欲しいです。

僕も SEMI といっしょに APEL, FLIM が含まれてくれると嬉しいです。
安定した version の組合せを考えずに取得できるから。何にも用意していない環境
で、すぐに SEMI 使いたいというときの時間が節約できるし。

ただ、現在の variant を考えると SEMI として APEL & FLIM & SEMI が配布される
よりも、 SEMI-oomori(もしくは、SEMI-komori)みたいな方が良いのかも知れない。

-- 
Tsuyoshi AKIHO
akiho ＠ media.osaka-cu.ac.jp



From yyamada ＠ cac.co.jp  Tue Nov 28 16:22:20 2000
From: yyamada ＠ cac.co.jp (Yoshihiko Yamada)
Date: 28 Nov 2000 16:22:20 +0900
Subject: emy - SJIS text Attachment
Message-ID: <un1ekwogj.fsf@field.cac.co.jp>

CACの山田です。
前から、この話題ばかりで、恐縮です。

EMY-1.13.9 で sjis の text を mime-edit-insert-file したところ
charset=iso-2022-jp
となってしまいました。

EMY-1.13.7 の時は
charset=SHIFT_JIS
となってくれたと記憶します。

で、これは カーソルが Nana-Gnus の article buffer の 途中で実行した時で
カーソルがbuffer の 最後の位置で同様に mime-edit-insert-file すると
以下のエラーになります。

Signaling: (wrong-type-argument integer-or-marker-p nil)
  next-visible-point(607)
  mime-edit-content-end()
  mime-edit-normalize-body()
  mime-edit-translate-region(142 5443 "Multipart_Tue_Nov_28_16:07:07_2000-1")
  mime-edit-translate-body()
  byte-code(".." [mime-edit-pgp-enclose-buffer mime-edit-translate-body] 1)
  message-locale-maybe-encode()
  byte-code("..

以上、ご報告まで。
-- 
山田 喜彦  yyamada ＠ cac.co.jp :   （株）シーエーシー  技術研究室
PGP-Key: CAC    http://lark/pks-commands.html
         public http://pgp.nic.ad.jp/pgp/index.html
PGP-Fingerprint:  DH/DSS [71AF A14E 3800 AE85 B0C2  AA50 C08B A8E9 CC29 E341] 



From yoshiki ＠ xemacs.org  Wed Nov 29 15:06:07 2000
From: yoshiki ＠ xemacs.org (Yoshiki Hayashi)
Date: 29 Nov 2000 15:06:07 +0900
Subject: emy - SJIS text Attachment
In-Reply-To: <un1ekwogj.fsf@field.cac.co.jp>
 (Yoshihiko Yamada's message of "Tue, 28 Nov 2000 16:22:20 +0900")
References: <un1ekwogj.fsf@field.cac.co.jp>
Message-ID: <873dgb5n3k.fsf@sodan.org>

Yoshihiko Yamada <yyamada ＠ cac.co.jp> writes:

> CACの山田です。
> 前から、この話題ばかりで、恐縮です。

毎回 bug report をしていただいてありがとうございます。

> EMY-1.13.9 で sjis の text を mime-edit-insert-file したところ
> charset=iso-2022-jp
> となってしまいました。

すみません。かなりぼけてました。私の環境では以下の patch で
とりあえず日本語のファイルは大丈夫なことを確認しました。
# ますます何だかなぁという code になりつつありますが。(^^;;

-------------- next part --------------
Index: mime-edit.el
===================================================================
RCS file: /cvs/root/semi/mime-edit.el,v
retrieving revision 1.35.2.17.4.19
diff -u -r1.35.2.17.4.19 mime-edit.el
--- mime-edit.el	2000/10/16 15:06:34	1.35.2.17.4.19
+++ mime-edit.el	2000/11/29 05:45:48
@@ -1138,6 +1138,43 @@
 	 (forward-char (cadr ret))
 	 (mime-edit-force-text-tag mime-edit-single-part-regexp))))))
 
+(defun mime-edit-guess-charset (file)
+  (with-temp-buffer
+    (let (candidates candidate eol eol-string)
+      (set-buffer-multibyte nil)
+      (insert-file-contents-as-binary file)
+      (setq candidates (detect-coding-region (point-min) (point-max)))
+      (setq candidate (if (listp candidates)
+			  (car candidates)
+			candidates))
+      (setq eol (coding-system-eol-type candidate))
+      (cond ((eq eol
+		 (static-if (featurep 'xemacs)
+		     'lf
+		   0))
+	     (setq eol-string "\n"))
+	    ((eq eol
+		 (static-if (featurep 'xemacs)
+		     'cr
+		   2))
+	     (setq eol-string "\r")))
+      (goto-char (point-min))
+      (when eol-string
+	(while (search-forward eol-string nil t)
+	  (replace-match "\r\n")))
+      (static-if (featurep 'xemacs)
+	  (setq candidate (coding-system-name (coding-system-base candidate)))
+	(setq candidate (coding-system-base candidate)))
+      ;; #### FIXME
+      (cond ((eq candidate 'undecided)
+	     (setq candidate "us-ascii"))
+	    ((eq candidate 'iso-2022-7bit)
+	     (setq candidate "iso-2022-jp"))
+	    (t
+	     (setq candidate
+		   (symbol-name (coding-system-to-mime-charset candidate)))))
+      (cons candidate (buffer-string)))))
+
 (defun mime-edit-insert-file (file &optional verbose)
   "Insert a message from a FILE.
 If VERBOSE is non-nil, it will prompt for Content-Type,
@@ -1150,7 +1187,7 @@
 	  (encoding (nth 3 guess))
 	  (disposition-type (nth 4 guess))
 	  (disposition-params (nth 5 guess))
-	  string)
+	  charset-and-string)
     (if verbose
 	(setq type    (mime-prompt-for-type type)
 	      subtype (mime-prompt-for-subtype type subtype)))
@@ -1162,38 +1199,10 @@
 	(let ((rest parameters) cell attribute value)
 	  (setq parameters "")
 	  (when (string= type "text")
-	    (with-temp-buffer
-	      (let (candidates candidate eol eol-string)
-	      (set-buffer-multibyte nil)
-	      (insert-file-contents-as-binary file)
-	      (setq candidates (detect-coding-region (point-min) (point-max)))
-	      (setq candidate (if (listp candidates)
-				  (car candidates)
-				candidates))
-	      (setq eol (coding-system-eol-type candidate))
-	      (cond ((eq eol
-			 (static-if (featurep 'xemacs)
-			     'lf
-			   0))
-		     (setq eol-string "\n"))
-		    ((eq eol
-			 (static-if (featurep 'xemacs)
-			     'cr
-			   2))
-		     (setq eol-string "\r")))
-	      (goto-char (point-min))
-	      (when eol-string
-		(while (search-forward eol-string nil t)
-		  (replace-match "\r\n")))
-	      (setq string (buffer-string))
-	      ;; ####
-	      (set-buffer-multibyte t)
-	      (erase-buffer)
-	      (insert (decode-coding-string string candidate))
-	      (setq parameters
-		    (concat parameters "; charset="
-			    (symbol-name (detect-mime-charset-region
-					  (point-min) (point-max))))))))
+	    (setq charset-and-string (mime-edit-guess-charset file))
+	    (setq parameters
+		  (concat parameters "; charset="
+			  (car charset-and-string))))
 	  (while rest
 	    (setq cell (car rest))
 	    (setq attribute (car cell))
@@ -1222,8 +1231,8 @@
     (mime-edit-insert-place
      (list type subtype)
      (mime-edit-insert-tag type subtype parameters)
-     (if string
-	 (mime-edit-insert-binary-string string encoding)
+     (if charset-and-string
+	 (mime-edit-insert-binary-string (cdr charset-and-string) encoding)
        (mime-edit-insert-binary-file file encoding)))))
 
 (defun mime-edit-insert-external ()
-------------- next part --------------

> で、これは カーソルが Nana-Gnus の article buffer の 途中で実行した時で
> カーソルがbuffer の 最後の位置で同様に mime-edit-insert-file すると
> 以下のエラーになります。

これ、backtrace を見た感じでは、送信時のエラーのように見えま
す。Debian woody にある Emacs 20.7 と EMY 1.13.9 と
Wanderlust で test してみたのですが、私の環境では再現しませ
ん。山田さんの環境では必ず発生するのでしょうか? ちょっと今
Nana-gnus の環境が無いので確かめられませんが、どうも buffer
が narrow されているときの next-single-property-change の挙
動の違いのような気がします。

mime-edit-content-end の
(next-visible-point (point))
を
(next-single-property-change (point) 'mime-edit-invisible nil (point-max)))
とすると直ったりしますでしょうか。

-- 
Yoshiki Hayashi

From yyamada ＠ cac.co.jp  Wed Nov 29 15:48:37 2000
From: yyamada ＠ cac.co.jp (Yoshihiko Yamada)
Date: 29 Nov 2000 15:48:37 +0900
Subject: emy - SJIS text Attachment
In-Reply-To: <873dgb5n3k.fsf@sodan.org> (Yoshiki Hayashi's message of "29 Nov 2000 15:06:07 +0900")
References: <un1ekwogj.fsf@field.cac.co.jp> <873dgb5n3k.fsf@sodan.org>
Message-ID: <ulmu35l4q.fsf@field.cac.co.jp>

CAC 山田です。

Hayashi さん何時も迅速な対応ありがとうございます。

>>>>> In <873dgb5n3k.fsf ＠ sodan.org> 
>>>>> “Hayashiさん” = Yoshiki Hayashi <yoshiki ＠ xemacs.org> wrote:

Hayashiさん> とりあえず日本語のファイルは大丈夫なことを確認しました。

Hayashi さんのパッチでこちらでも、うまくいくことを確認しました。

私> で、これは カーソルが Nana-Gnus の article buffer の 途中で実行した時で
私> カーソルがbuffer の 最後の位置で同様に mime-edit-insert-file すると
私> 以下のエラーになります。

Hayashiさん> これ、backtrace を見た感じでは、送信時のエラーのよ
Hayashiさん> うに見えます。Debian woody にある Emacs 20.7 と EMY
Hayashiさん> 1.13.9 とWanderlust で test してみたのですが、私の
Hayashiさん> 環境では再現しません。山田さんの環境では必ず発生す
Hayashiさん> るのでしょうか?

Meadow 1.13b1 + Nana-gnus-7.1.0.24 ですが
何度やっても発生します。

Hayashiさん> mime-edit-content-end の
Hayashiさん> (next-visible-point (point))
Hayashiさん> を
Hayashiさん> (next-single-property-change (point)
Hayashiさん> 'mime-edit-invisible nil (point-max))) とすると直っ
Hayashiさん> たりしますでしょうか。

(next-single-property-change (point) 'mime-edit-invisible nil (point-max))

になおして実行してみたところ、無事、送信できるようになりました。

これは、どっちを修正するのが望ましい案件なんでしょう？
-- 
山田 喜彦  yyamada ＠ cac.co.jp :   （株）シーエーシー  技術研究室
PGP-Key: CAC    http://lark/pks-commands.html
         public http://pgp.nic.ad.jp/pgp/index.html
PGP-Fingerprint:  DH/DSS [71AF A14E 3800 AE85 B0C2  AA50 C08B A8E9 CC29 E341] 



From yoshiki ＠ xemacs.org  Wed Nov 29 16:02:33 2000
From: yoshiki ＠ xemacs.org (Yoshiki Hayashi)
Date: 29 Nov 2000 16:02:33 +0900
Subject: emy - SJIS text Attachment
In-Reply-To: <ulmu35l4q.fsf@field.cac.co.jp>
 (Yoshihiko Yamada's message of "Wed, 29 Nov 2000 15:48:37 +0900")
References: <un1ekwogj.fsf@field.cac.co.jp> <873dgb5n3k.fsf@sodan.org>
 <ulmu35l4q.fsf@field.cac.co.jp>
Message-ID: <87n1ej45x2.fsf@sodan.org>

Yoshihiko Yamada <yyamada ＠ cac.co.jp> writes:

> Hayashiさん> mime-edit-content-end の
> Hayashiさん> (next-visible-point (point))
> Hayashiさん> を
> Hayashiさん> (next-single-property-change (point)
> Hayashiさん> 'mime-edit-invisible nil (point-max))) とすると直っ
> Hayashiさん> たりしますでしょうか。
> 
> (next-single-property-change (point) 'mime-edit-invisible nil (point-max))
> 
> になおして実行してみたところ、無事、送信できるようになりました。
> 
> これは、どっちを修正するのが望ましい案件なんでしょう？

おそらく、invisible の方は仕様でしょう。EMIKO にならって 
invisible.el とは訣別する予定ですので、そのときに一緒に EMY 
の方で対処しようと思います。

-- 
Yoshiki Hayashi