|
「ネットワークプログラミングの基礎知識」 http://X68000.startshop.co.jp/~68user/net/ に「SSL でアクセスしてみよう」 http://X68000.startshop.co.jp/~68user/net/ssl.html を追加しました。 サンプルソースがほとんど http://stingray.sfc.keio.ac.jp/security/ssl/ssl.html のパクリというのが情けない…。 |
|
ときに、UNIX+Java+Java servlet+JDBC+Postgres+ XML+XSLT な解説って需要ありますか? 書きたくはあるけれど、普通の ISP では Java servlet なんて 使えないだろうなぁ…。 |
|
どうも、skel.103Mです。 素早いフォローありがとうございます。＞68user様・rosegarden様 >>2063 rosegarden > > でも、なぜこういうことをするようRFCで定められている > > のでしょうか？ > > RFC 821 や RFC 2821 をざっと見た限りだと MUST とか SHOULD > とかいう表現はありませんね。 RFC2821には MUST や SHOULD なる表現があります。RFC2821の 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)の第２段落にある以下の記述が これに該当すると思います： > A client SMTP SHOULD start an SMTP session by issuing the EHLO > command. ＆ > In any event, a > client MUST issue HELO or EHLO before starting a mail transaction. RFC2821はRFC821を破棄したわけですから、クライアントによるHELO（また はEHLO）コマンドの発行が新しく*必須*となったと考えてよいと思われ ます。その理由っていったい何なんでしょう？？私にはさっぱり想像 できないんですけど……。そこで、 >>2062 68user > とりあえずこちらを。 > http://djbdns.jp.qmail.org/djb/smtp.html を見てみましたが、これによると、「サーバ 実装者には HELOなしの世 界への将来の転換をサポートするように、 クライアント が HELOを省略 させるようにしむけることを推奨します。」という記述があるんです けど。…これってHELO（またはEHLO）の存在意義はないと言ってるよう にとれるんですけど……私だけ？ (^^;;; > 知りませんでしたが、envelope がクリアされるらしいですね。 ご紹介いただいたWebページはqmailの実装をもとにして記述されたもの のようですが、RFC2821にはそれを示唆する部分は見つけられませんでし た。 う〜む…… |
|
>>2067 skel.103M > > > でも、なぜこういうことをするようRFCで定められている > > > のでしょうか？ > > > > RFC 821 や RFC 2821 をざっと見た限りだと MUST とか SHOULD > > とかいう表現はありませんね。 > RFC2821には MUST や SHOULD なる表現があります。RFC2821の > 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)の第２段落にある以> 下の記述が > これに該当すると思います： なるほど、おっしゃる通りです。 私は 3.2 を見ていました。 かえって勉強になりました。ありがとうございます。 |