別に構わないだろう。
外向けの回線が細ければ、80 台の PC で一斉にアクセスした時に、単に糞詰まりになって外に出られなくなるだけである。
アクセスの仕方にもよるが、例えば利用するサイトが決まっているなら、proxy/cache サーヴァを設置して、ブラウザがそれを利用するようにしておき、講義で利用するページはあらかじめアクセスしてキャッシュにいれておけば多少はましになるかもしれない。ただし、いろんなページを自由に見に行くなら効果は薄いだろう。
全員が一ヶ所へアクセスするような課題は出さないように気をつけ、可能なら「気をつけるべきである」ことも教育するようにするとよいかもしれない。たとえば「…を ftp してきて make せよ」といった課題を出すときには、そのプログラムは local に mirror すべきである。
逆にてんでんばらばらのところへ行くならそんなに気にしなくても良い。もちろん容量の大きな cache がある方が望ましくはあるが、cache が無くて全員で首を締め合うとどういうことが起きるかを実感させるのもまた教育的である。
MIME encoding されていない Subject の場合は、どこにも ISO-2022-JP だと言う宣言はされていない。そういう宣言がされていない以上、ESC $ B も ESC ( I も同列であり、問題はない。
仮に受信側が ESC-(-I を読めない環境であっても、 Subject に「奇妙な文字列が表示される」以外に困ることはないだろう。そもそも、Subject の charset や encoding に関しての約束事は、利用者間の合意によるものである。
ただし、fj では使わない約束になっているので、fj で流してはならない。また、JIS X0201 かなは ISO-2022-JP からは外れているので、ISO-2022-JP を両端で合意している環境のメールにも使ってはならない。
例えば、BothWays (http://www1.infoeddy.ne.jp/ftk/bothways/) というソフトは、メールサーバから POP3 で取り出した日時を知ることができる。
POPの場合、送り先のメールサーバが finger 情報を出している場合には、Mailspool からは取り込んだな、というのは分かる。ただ、「読んだ」かどうかは分からない。まとめて捨ててるかもしれないし、「見て」るかもしれないが全然頭に入っていないかもしれない。
あくまでも「届いたかどうか」か、あるいは「メールを開いたかどうか」であって、「読んだ」かどうかというのは、基本的には相手に聞くしかない。メールに「読んだら返事ください」って書いておくのが確実である。ただし、返事をくれるかどうかは相手の自由なので、確実性には欠ける。
ジャンクメイル:
必要もないのに送りつけられてくる電子メイル。郵便物のダイレクトメールの電子メイル版や、ねずみ講へのお誘い、コンピュータウイルスまがいの報告、電子年賀状等々。
SPAM:
投稿先、投稿相手をほぼ無差別に選択して送られるネットニュースの記事や電子メイル。もともとは缶入りポークランチョンミートの商品名。
SPAM のことで知りたいのなら
http://caramia.g-net.org/spam/
http://caramia.g-net.org/spam/whatis.html
RFC821では、
<mailbox> ::= <local-part> "@" <domain>
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig> ::= <a> | <d>
<let-dig-hyp> ::= <a> | <d> | "-"
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<d> ::= any one of the ten digits 0 through 9
とあり、ドメイン名の要素の第一文字目はアルファベット文字と規定している。しかし、RFC1123 (Requirements for Internet hosts - application and support) で、数字から始まるドメイン名を許す様になっている。DNS 的なドメイン名だけではなく、電子メールのドメインについても書いてある。
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].
One aspect of host name syntax is hereby changed: the restriction on the
first character is relaxed to allow either a letter or a digit.
Host software MUST support this more liberal syntax.
....
5.2.17 Domain Literals: RFC-822 Section 6.2.3
A mailer MUST be able to accept and parse an Internet domain literal whose
content ("dtext"; see RFC-822) is a dotted-decimal host address.
This satisfies the requirement of Section 2.1 for the case of mail.
ここで、RFC-821 の <domain> の文法も拡張されたと解釈され、 数字から始まるドメイン名の要素も許されると考えられる。
回線を切断しても TCP のコネクションが張られたままになっていて、アプリケーションを終了するときに fin の立ったパケットを送ろうとして自動接続してしまう、という事象が考えられる。
この問題のみを解決し、不便な副作用の起こらないフィルタの設定方法が無いならば、面倒だが、
といった手順が、これを防ぐ方法の一つである。
HTTP だけであれば、手前の LAN に多少かしこい proxy をたてておけば防ぐことは容易である。しかし、rlogin や ftp でも意図しない再接続が起る可能性はある。
8.2 HEAD The HEAD method is identical to GET except that the server must not return any Entity-Body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should be identical (略)
と記述されている。HEAD に対して Entity-Body は返してはならないと規定されていることから、HTTP1.0 準拠をうたっていて BODY を返すサーバはタコである。
尚、RFC2068(HTTP1.1) では MUST NOT と強調されている。
そんなことはない。個人が利用できる地域ドメインがある。
http://www.nic.ad.jp/jpnic/domain/rule.html
Java または Java script を利用して、ブラウザが利用するプロキシを動的に設定できるようにするものである。例えば、プロキシの設定を書いた *.pac というファイルを作り、それを指定して読み込ませるといった方法がある。
個人でプロバイダ経由で接続している場合はあまり意味はないが (プロバイダが用意していれば別だが)、以下のような場合に効果がある。
また、aaa.aaa.aaa というサイトに対してはプロキシ A を使うが、bbb.bbb.bbb という サイトに対してはプロキシ B を使うということも可能。ローカル (file:〜) に用意しておけば、複数のプロバイダに契約している場合に、接続したプロバイダごとにプロキシサーバを選択できる。
参考は
http://www.bento.ad.jp/~fumiya/Doc/proxy-autoconfig.html
RFC では RFC2136/ RFC2137 で DDNS(Dynamic DNS) が記述されている。 RFC2136/ RFC2137 が作成される前に、IBM から DDNS が出されている。
IBM 版では、DHCP サーバと DHCP クライアントの両方が DDNS に対応していることが要求される。DHCP クライアントは、DHCP サーバから IP アドレスの割り当てを受けたら、DDNS サーバに対して正引き情報 (name → addr) を更新するよう要求する。また、DHCP サーバは、DHCP クライアントに IP アドレスを割り当てたら、DDNS サーバに対して逆引き情報 (addr → name) を更新するよう要求する。
ホスト名は、DHCP クライアントの DHCP Configuration file に記憶させておくか、あるいは DHCP クライアントのオペレータに入力させることにより設定する。これに関して「ホストのなりすまし」を防ぐために、デジタル署名技術が援用されており、特にセキュリティが要求される場合には、クライアントの DHCP Configuration file に記憶させた署名と、DHCP サーバ/DDNS サーバに記憶させた署名が一致しないと DDNS ゾーンデータベースの更新ができないようにする、という設定が可能。
上記の DDNS の動作の説明を含んだ文書は、 OS/2 Warp Server V4 日本語版テクニカルガイド から入手できる。DDNS の説明は、第6章の「TCP/IP サービス」に含まれている。
192.168/16 prefix とは、
192.168.0.0〜192.168.255.255 の範囲は、上から16bit部分が 192.168
Netmask でいうと 255.255.0.0 (= 16bit)
上記以外の例としては、
10/8 prefix
10.0.0.0〜10.255.255.255 の範囲は、上から 8bit部分が 10
Netmask でいうと 255.0.0.0 (= 8bit)
172.16/12 prefix
172.16.0.0〜172.32.255.255 の範囲は、上から12bit部分が 172.16
Netmask でいうと 255.240.0.0 (= 12bit)
draft-gilman-news-url-00.txtというInternet Draftが出ていて、そちらに news://host/groupという形式が定義されている。内容的には news://host/group や news:[//host/]group/messegeno あたりの形式の追認と、snews URL: の導入といったもの。
参考までに、lynx の作者 Foteos Macrides 氏は「間違っとる」と嘆きながら、news://host/group という書式をサポートしてくれたらしい。
省略可能である。ただし、宛先を示すヘッダが別途必要。
RFC822 では、C.1. FIELD DEFINITIONS でフィールドのシンタクスを定義している。これは、C. DIFFERENCES FROM RFC #733 とあるように、 RFC733 から変わった所の記述である。
RFC733 では以下のように記述されている。
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
つまり, 1*destination となっており、少なくとも, To, Resent-To, cc, Resent-cc, bcc, Resent-bcc の 6つの中の少なくとも 1 つが必要だということである。
従って、宛先を示す 6 つのヘッダのうち、どれか 1 つでもあれば、 To: フィールドを省略しても、規定上は問題ない。
誤りである。
RFC822 の C.3.4 DESTINATIONで、以下のように記述されている。
A message must contain at least one destination address field. "To" and "CC" are required to contain at least one address.
つまり, 「メッセージは少なくとも 1つの destination address field を持たなくてはいけない。"To" と "CC" には 1つ以上の address を持たなくてはいけない」わけである。
また、ヘッダにおける括弧 () でくくられた部分は Comment という定義なので、To: (My Friends) とすると、address はゼロ個ということになるので、上記の条件に適合しない。
To: や Cc: フィールドの中では省略できないため、To: フィールドを付ける場合には、必ずアドレスを付けなければならない。(Bcc: フィールドの中ではアドレスを省略しても構わない)。
ただし、To: フィールド自体を省略するのは可。
Apparently-To については、 RFC2076 で以下のように記述されている。
Inserted by Sendmail when there is no "To:" recipient in the original message, listing recipients derived from the envelope into the message heading. This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients.
元のメッセージのヘッダに To: フィールドが無いと sendmail が envelope から生成する場合があるということである。
sendmail 5.x ベースのところをある条件で通過すると、To: が無いメールはすべての envelope 的宛先を Apparantly-To: に書き並べるようである。sendmail 8.x 以降を使うようになってから見掛けなくなったので、5.x -> 8.x のどこかで sendmail の仕様変更があったものと思われる。
見えても構わないアドレスを指定したほうがよい。
以下に、ヘッダ記述パターンを場合分けすると、
誤り
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org
To: (my friends)
Bcc: address1, address2, ...
これは To が no address なので間違い。さらに、To や Bcc の行自体削除される場合があり、sendmail が Apparently-To を付けて見えない筈のアドレスが見えるかもしれない。
正しいが Bcc: のアドレスが見られる可能性あり
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org
Bcc: address1, address2, ...
Bcc: 行自体が削除されることがあるので、結果的に間違いになるかもしれない。sendmail が Apparently-To を付けて見えない筈のアドレスが見えるかもしれない。
推奨
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org
To: 見えて構わないアドレス
Bcc: address1, address2, ...
これならば To 行が削除されることはない。Bcc 行自体が削除されても問題ない。sendmail が Apparently-To を付けることもない。「見えて構わないアドレス」に適当なのが思いつかない場合は、取り敢えず自分のアドレスでも書けばよい。
ポイントは、POST行のあとに、POSTするデータの長さを表す Content-Length: ヘッダ行が必要であることと、ヘッダの終了を表す空行のあとに送りたいデータを入力することである。つまり、
POST /some.cgi HTTP/1.0
Content-Length=データの長さ
(空行)
a=foo&b=bar..
となる。POSTするデータの長さを表す Content-Length: ヘッダを入力し、空行のあとに送りたいデータを入力すればよい。