JIS-X-0201の標準的な指定の仕方が決まってない為。
fjで見るだけでも、半角カナは 3種類ぐらいの方法がばらばらに使われている。^n,^o を使ったり、ESC-(-I を使ったり、G1に指示したり、SJIS をそのまま送ったり等。これらをすべて表示出来るプログラムは多くはないだろう。
ちなみに、fjで使うとすれば、ISO-2022-JPの延長である、ESC-(-I になるが、^n,^o は今でも落とす所が多いし、G1 は Latin-1 に割り振るのが合理的であるという見方もある。
また仮に半角カナを表示できる環境であっても、それが使用された為に EUC と SJIS の自動判定ができなくなるという欠点がある。特に WWW は、EUC と SJIS の混在を認めている為、半角カナの使用は原則禁止とせざるおえない。
アドレスはメールが本人に届けばよく、Organization はそのアドレスの発行元でもいいし、(それとは関係なしに) 本人の所属でもよい。極端な話「Organization: 地球」というのもあり得る。
結局は書き手個人の見識と読み手個人の見識の問題であり、投稿の読み手が From や Organization 欄をどう判断するかは、本文の内容にも応じて、全く気にしないか、あるいはガキの仕業としてメール自体を無視するか、単に大人の常識・世間の常識の次元の話であり、規則・決まりの次元ではないだろう。
" を含む文字の場合、問題を生ずることがある。たとえば, "滋" という文字の場合,
From: "滋" <foo@bar.co.jp>
は, ESC を ^[ で表わすと,
From: "^[$B"^[(B" <foo@bar.co.jp>
となり, 途中の " で quoted-string が終了, その次の ( でコメントの開始、しかも括弧が対応しないのでコメントが終わらない、となるので <foo@bar.co.jp> がアドレスとして扱われなくなる。
日本語文字コードが、httpサーバが EUC、ブラウザが SJISとする。
ただし、Internet Explorer 3.0では、4.の作業をしないため、SJIS から EUC の変換をサーバーにある FORM を処理する CGI で変換する必要がある。この変換には、jcode.pl という Perl のライブラリを利用するのが最も簡単である。
re
― prep. 【主に法・商】 …に関して; …について (concerning)
: re Brown ブラウン事件に関して.
----------------------------------------------------------------
《CD-ROM 版 リーダーズ英和辞典 (C) 1992 株式会社研究社より引用》
re/ri:/. You use re in writing to introduce a subject or item
which you are going to discuss or refer to in detail; use in
formal written English.
----------------------------------------------------------------
COLLINS COBUILD ENGLISH LANGUAGE DICTIONARY (1992)
re は略語ではない。一つの単語である。
IP アドレスや、ネットワークアドレスなどネットワーク関係の設定を問い合わせる仕組みである。DHCP サーバを用意しておけば、クライアントを個別に設定する労力が軽減される。
RFC1541 "Dynamic Host Configuration Protocol"
尚、通常プロバイダからのダイヤルアップの動的割り当ては、PPP の IPCP が使用される。
RFC1332 "The PPP Internet Protocol Control Protocol (IPCP)"
シフトJIS では、a1〜df は「JIS X 0201 片仮名」(いわゆる半角片仮名)、81〜9f、e0〜ef が「JIS X 0208 漢字」の第1バイト、f0〜fc が拡張文字セットの第1バイトとして使用されている。
シフトJIS では fd〜ff が第1バイトにも第2バイトにも来ることがない為、以下の文字を EUC で書いておけば自動判別が可能になる。
第2バイトが fd の漢字
胤 往 拐 茅 棋 享 屑 拳 口 狛 冊 持 収 傷 埴 雀
箭 増 蛸 喋 蹄 統 乳 駁 眉 幅 方 慢 油 理 練
傴 劑 哈 圄 奬 屎 廐 悃 戔 撈 暾 椌 檢 沱 漲 燵
瓔 癬 磊 笶 糺 缸 脯 茉 蕘 蝮 襠 譚 踴 逹 鍄 陜
髱 鵆 龜
第2バイトが fe の漢字
蔭 応 改 萱 棄 京 屈 捲 向 込 刷 時 周 償 飾 裾
線 憎 只 寵 逓 到 入 麦 美 服 朋 満 癒 璃 聯
傲 辨 咨 圉 奩 屓 廏 悚 戛 撼 暼 棍 檣 沾 滌 燼
珱 癰 磬 筐 紆 缺 腋 苙 蕈 蝙 襞 譫 蹊 迸 錮 陞
顰 髷 鵈 龠
ヘッダに Supersedes: <Message-ID> を書いておくと、 <Message-ID> の記事をキャンセルし、新しい記事におき換える。これは rfc1036 には無く、son-of-rfc1036 の方にある。
INN の場合、VERIFY_CANCELS が DO の場合、キャンセルメッセージが元の記事よりも先に届いた場合(キャンセル対象の記事が存在しない場合)、キャンセルメッセージが無視される。VERIFY_CANCELS が DONT の場合、先に届いたキャンセルメッセージのメッセージID が history として残され、後から該当する記事が届いたら、それを削除する。
研究社 リーダーズ英和辞典より
flame
-vi.
2 <情熱など>燃え上がる; かっと怒り出す <out, up>
その他、Jargon やハッカーズ大辞典を参照すると良いだろう。
http://www.fwi.uva.nl/~mes/jargon/
Eric Raymond 編
福崎俊博 訳
アスキー出版局 3,200円 ISBN4-7561-0274-X
そこいらじゅうにある。
上流のサイトに問いあわせるのが筋だが、以下のURLから探せる。
http://www.eecis.udel.edu/~mills/ntp/servers.html
誤りと考えるべきである。
現在、Usenet ではデファクトスタンダードと見なされている Son-of-rfc1036 というドキュメントがある。ここで、Distribution: 行に書ける文字列についての取り決めがあり、Distribution: 行をニュースグループを書く欄であると混同することを禁じている。
RFC 2076 "Common Internet Message Headers" では、Son-of-rfc1036 が引用され non-standard ではあるが、デファクトスタンダード(Usenet)であると位置づけている。
Not even an RFC, but still widely used and partly almost a defact standard for Usenet News)
つまり、son-of-rfc1036 をスタンダードに準ずるものとして認めており、さらに、Distribution: 行については以下のように言及している。
RFC 1036: 2.2.7, not standardized for use in e-mail.
Geographical or organizational Distribution: limitation on where
this article can be distributed.
Distribution:
行は地理的、組織的な配布制限に用いることが、明確に述べられている。
fj は、地理的な配布制限ではない
(88年の『JUNET 参加の手引』のころは、違っていたかもしれない)。当然、組織でもない
(仮に組織であったとしても、その組織内で fj という Distribution
を使ってよいというコンセンサスがない)。
以上から、「Distribution: fj」は、不正と考えるべきである。
"Good Times" ウィルスという騒ぎにもなった、TEXT 型メールウィルスは、90% はデマだと思われる。残りの 10% は「読んだだけ」と思って、実は添付されているファイルを実行してしまったケースだろう。
注意するべきはこの 10%
のケースで、「こういうウイルスは存在しない」と説明するのは危険な嘘になる可能性がある。実際にあった話で、
AOL4U というプログラムはウイルスである --> デマ
というデマが流れ、これを打ち消す
AOL4U というウイルスは存在しない --> 一見正しい
が広められたのだが、今度はそれを逆手に取って
本当に AOL4U というウイルスが作られた --> なんと！
という例もある。
この手の Good Times siblings（兄弟）情報への対応として正しいのは、おそらく
を広報することである。
本当にメールを「見る」だけで作用するウイルスというのは今のところ知られていない。しかし、ユーザは単に見ているだけのつもりでも、実際には添付されているプログラムを実行していることがある。
Good Times siblings の特徴としては、
文字コードについていえば、ヘッダに
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-2022-jp">
など、使っている文字コードの情報を入れておくべきである。ISO-2022-JP が文字コードの自動判別に失敗するという話はあまり聞かない。
MS 漢字コードでいわゆる「半角かな」を使っていると、日本語 EUC と誤認されることがあるようだ。HTML が正しく書かれていれば、ブラウザの種類によらず、正しく表示してくれるはずなので、仕様に則った正しい HTML で書くべきである。
RFC にはアドレスの数の上限に関する規定はない。
MUA や sendmail の作りの制限で上限が設けられているものもあるかもしれない。1 行の長さの制限に引っ掛かるようであれば、行頭に TAB を入れてヘッダを複数行に分割したり、To: や Cc: ヘッダ行自体を複数持たせても構わない。
「送ってくるな」という返信は、mail reachable と判断されて、より多くの mail が舞い込むことになりかねないので避けるべきである。
相手の address が mail reachable であれば、script 書いてmail 攻撃という手もあるが、postmaster から大目玉食らうことになるだろう。非に非をもって対処することは、何ら正当化されないので、mail 攻撃をやっているのがばれれば (syslog を見ればすぐ分かる)、大目玉食らうことは十分ありえる。
大学の mail 環境なら、特定の domain からの mail は削除してもらうよう、postmaster にお願いすればよいかもしれない。ただし、正規の仕事ではないので菓子折りが必要。 :-)
unix 環境で mail を受け取るならば、script を書いて自分で削除することも可能。
また、header の Recieved by **** に Provider の address 等が残っていれば、そこのサポート宛に苦情 mail を送れば、アカウント回収等の措置ほ施してもらえるかもしれない。ここまでする面倒が嫌ならば、無視して、script で kill するのが一番だろう。
たとえば
など。
HTML 3.0 には数式機能が存在したが、HTML 3.2 になって削除され、実装しているブラウザもないだろう。
従って、現状では数式はイメージで表示するしかない。ワープロソフト等を使用して画面に表示し、画面キャプチャー等で画像として取り込む方法が最も容易だろう。
将来的には、Mathematical Markup Language というものも出てきている。
URL:http://www.w3.org/pub/WWW/MarkUp/Math/
これは XML のアプリケーションで、詳しい仕様(ドラフト) は以下の
URL から入手できる。
URL:http://www.w3.org/pub/WWW/TR/WD-math/
たとえば、
など。