インターネット系 Q&A 3

Index
  1. ヘッダでダブルクオート内にカッコが入っていても良いか?
  2. ヘッダでダブルクオート内に MIME encode されたフレーズが入っても良いか?
  3. HTML で、一定時間ごとに機械的に更新するようなことが書けるか?
  4. 電子メールで、テキストファイルを添付したら変換されるか?
  5. ネットワークニュースに投稿する際、SPAM 対策で From: 行を改変するのは良いか?
  6. メールヘッダ To: と Cc: に実質的に違いがあるのか?
  7. FTP で受信失敗時、失敗したところから受信の再開ができないか?
  8. 電子メールの配達証明機能の効果は?
  9. MIME-Version: ヘッダに boundary 指定が付いて、マルチパートが認識されない。
  10. ニュースリーダに ROT13 の解読機能が付いているが、何に使うのか?
  11. 電子メールの送受信で、一行の長さは規定されているか?
  12. Followup-to: fj.xxx とはどういう行為なのか?
  13. Followup-to を指定した場合、本文にその旨を書くことはマナーか?
  14. HTTP サーバのログを見ると index.html にしかアクセスしていないのがあるが。
  15. ネットニュースで、回答が得られたらお礼の記事を出した方がいいか?
  16. WWW のデータシート等をダウンロードして見ると、小文字のウやヨを散見する。
  17. 迷惑な無差別送信メールを SPAM と呼ぶのは、何が由来か?
1. ヘッダでダブルクオート内にカッコが入っていても良いか?

別に問題はない。

ダブルクオートで囲まれた範囲では、ダブルクオートとバックスラッシュ以外は特別な意味をもたない。

「改行 + 空白」で次の行に続けることも可能。RFC822 の文法用語で言えば、その場合ダブルクオートで囲まれた範囲全体が quoted-string = word = phrase となる。

2. ヘッダでダブルクオート内に MIME encode されたフレーズが入っても良いか?

良くない。

RFC2047の 5. Use of encoded-words in message headers には、

    + An 'encoded-word' MUST NOT appear within a 'quoted-string'.

という一節があり、符号化されたワードをダブルクオートで括ることを禁じている。よって、以下は誤り。

To: "=?iso-2022-jp?b?abcdef012345?=
    =?iso-2022-jp?b?1234abcdef==?=" <user1@domain1>

3. HTML で、一定時間ごとに機械的に更新するようなことが書けるか?

自分自身を再度読み込ませれば良いわけだから、クライアントプルが簡単だろう。 <HEAD>...</HEAD>の中に <META HTTP-EQUIV="Refresh" CONTENT=600> とか入れておけば 10分ごとに reload される。

例)

<html>
<head>
<title>keijiban.html</title>
<meta http-equiv="refresh" content="180;url=keijian.html">
</head>
<body>
<p>
この掲示板は3分おきに更新されます
</p>

<address>webmaster@ics.kyoto-su.ac.jp</address>
</body>
</html>

ただし、NetscapeNavigator 4.0x では有効に動作するが、Lynx2.7.2 では、例) の content の部分に埋め込んだ URL が提示されるだけで自動更新はされない。

4. 電子メールで、テキストファイルを添付したら変換されるか?

使用しているソフトによって変わる。また、使用している漢字コードによっても変わる。

Mozilla 3.01 では、漢字未使用・Shift-JIS 漢字使用・JIS 漢字使用のどれも MIME エンコードされることなく、
    Content-Type: text/plain; charset=iso-2022-jp
    Content-Transfer-Encoding: 7bit
となる。

添付したファイルが .txt だと、 Content-Type を text/plane と判定し、iso-2022-jp にコード変換するようである。

Microsoft Internet Mail では
・漢字未使用の場合、
    Content-Type: application/octet-stream;
    Content-Transfer-Encoding: 7bit

・Shift-JIS 漢字使用の場合、
    Content-Type: application/octet-stream;
    Content-Transfer-Encoding: base64

・JIS 漢字使用の場合、
    Content-Type: application/octet-stream;
    Content-Transfer-Encoding: quoted-printable

となり、漢字未使用を除いて MIME エンコードされる。

添付ファイルが .txt でも Content-Type を text/plane と判定せず、使われているデータを解析して最適なエンコード方式をものを選ぶようである。

5. ネットワークニュースに投稿する際、SPAM 対策で From: 行を改変するのは良いか?

RFC1036 上は「Internet 的メールアドレス」を求めており、到達しないものを書くのは良くないだろう。 

2.1.  Required Header lines

2.1.1.  From

The "From" line contains the electronic mailing address of the
person who sent the message, in the Internet syntax.

それを承知で嘘を書くというのなら、やっていることは「相手 (Spam 業者) が悪いことをするから、自分も悪いことをして対抗するんだ」という手段であることを認識すべきである。少なくとも「誰にでも勧め」られる行為ではない。

6. メールヘッダ To: と Cc: に実質的に違いがあるのか?

受け取った人にとってのメールの位置付けが違う。

メール配送機構とか、sendmail の実装とか形式的・機構的な (人間にとってはどうでも良い) 面では殆ど差が無いといえる。しかし、受け取った人が自分宛であるのか他人宛の控えであるのかを知ると云う、実質的に大きな差がある。

7. FTP で受信失敗時、失敗したところから受信の再開ができないか?

Windows では GetRight というソフトでできる。このソフトは Resume 機能がついていて、ファイルのダウンロードに失敗しても失敗したところからやり直せるというもの。例えば、8MB のファイルをダウンロード中に 4MB までダウンロードしたところでネットワークが切れてしまったとしても、残りの 4MB をダウンロードするだけでもう一度、最初からダウンロードし直す必要がない。

この GetRight の for JAVA なるバージョンがあるようなので、他のプラットフォームでも使用できそうである。

http://www.headlightsw.com/ に詳しく書かれている。

MacOS で同等の機能を持つ FTP クライアントソフトに、Fetch 3.0.3 というものがある。

ただし、これらは FTP クライアント側だけではなく FTP サーバ側でも REST Command を解する必要がある。draft-ietf-ftpext-mlst-04.txt に REST (REST STREAM) の記述がある。

8. 電子メールの配達証明機能の効果は?

古来からの Return-Receipt-To ヘッダによる場合は、sendmail の独自機能のため sendmail 以外の場合や、よくメンテされた新しいバージョンの sendmail を適切に設定しているサーバでも動作を期待することはできない。

また、ESMTP による方法では、相手のサーバにたどり着く間に SMTP に対応してないサーバがいると動作は期待できない。FWTK (Firewall Tool Kit の smap/smapd) を経由する場合もこれに含まれるだろう。

メーリングリストへ配達証明つきで送って、参加者の人数分の return receipt が返ってくるというミスをおかす可能性もある。無論、リストの処理の過程で対応することも可能だが、義務付けられる筋合いのものではない。

といったことから、その機能は問題が多いので、「よく理解していない限り使うべきではない」と言う管理者は多い。

9. MIME-Version: ヘッダに boundary 指定が付いて、マルチパートが認識されない。

RFC 2045 に

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

とある通り、boundary=... を含んだ MIME-Version フィールドは誤った形式のものである。

誤った形式を持つ MIME-Version は無視されても仕方が無く、MIME-Version が存在しないケースとして記述されている以下の箇所 (RFC 2045) に適用可能であると考えられる。 

  In the absence of a MIME-Version field, a receiving mail user
  agent (whether conforming to MIME requirements or not) may
  optionally choose to interpret the body of the message according
  to local conventions.  Many such conventions are currently in
  use and it should be noted that in practice non-MIME messages
  can contain just about anything.

よって、メイラによる解釈は自由であり、Content-Type を RFC 2045 に規定されたものとは見なさず、multipart/mixed として処理しなくても構わない (マルチパートとして認識せずとも仕方が無い) と言える。

無論、受けた側の対応に関しては、MIME-Version が誤っているのに MIME に従って処理してあげるメイラもあってよい (メイラの自由だから) が、メッセージボディ全体をplain text としてしまうことも適切な処置の一つと言えるだろう。

10. ニュースリーダに ROT13 の解読機能が付いているが、何に使うのか?

ROT13 は、ABCDEFGHIJKLMNOPQRSTUVWXYZ を NOPQRSTUVWXYZABCDEFGHIJKLM に変えるもの (小文字も同様)。13 文字づつ回すから rot13。日本語などの 94x94 だと同様に rot47 というものがある。単純な暗号の一種である。

これは、ぱっと見て分からないような文章を書く時に使われる。例えば、ネタばらしとか、オチとか、下ネタとか...。

11. 電子メールの送受信で、一行の長さは規定されているか?

RFC821 (SMTP) では以下のように、<CRLF>を含めて 1000 文字まで。 

  text line

     The maximum total length of a text line including the
     <CRLF> is 1000 characters (but not counting the leading
     dot duplicated for transparency).

RFC1939 (POP3) では、以下のように、<CRLF>を含めて 512 文字まで。 

   Responses may be up to 512 characters long, including the
   terminating CRLF.
12. Followup-to: fj.xxx とはどういう行為なのか?

誰かがその記事にフォローアップをすると、デフォルトで Newsgroups: が fj.xxx になる。よって、Newsgroups: をいじらない人だけがフォローすると、フォロー記事がすべて fj.xxx に集まるという効果を持つ (もちろんニュースリーダがまっとうな実装の場合)。

つまり、Followup-to: を指定するということは、「この記事に対するフォローアップが投稿されるデフォルトのグループを指定する」という行為である。

例えば、グループ A で議論していたのが、B の方が適切な内容になってきた場合、A, B にクロスポストにした上で Followup-To: B を指定した記事を投稿することが多い。そうすれば、そのクロスポストした記事が両グループのつながりの役割を果たすことになる。

13. Followup-to を指定した場合、本文にその旨を書くことはマナーか?

そんなことはない。

確かに、Followup-To を指定した場合、本文にも書いておくことは親切であり、注意を促すといった意図で書く人もいるだろう。しかし、それはおまけのようなもので、「書くべき」ものというわけではないし、マナーでも慣習でもない。

本来は Followup-To がついていることを読み手に知らせるのは、ニュースリーダがやるべきことであろう。

14. HTTP サーバのログを見ると index.html にしかアクセスしていないのがあるが、自動スキャンか ?

プロクシにキャッシングされているので取りに行かないだけかもしれないし、text only で見ているだけかもしれない。

そもそも、自分が公開してしまったファイルを受け取り側がどう持って行くかなんてことを気にするのは変である。例えば、本を書いたとして、目次から見る人、あと書きから見る人、解説から見る人、等いろいろあるだろう。どう読まれるかを予想することは無理である。

公開していないファイルを探り当てられたとか、インストールしていない http サーバ経由でファイルが持って行かれているといった場合は、気にすべきだが…

15. ネットニュースで、回答が得られたらお礼の記事を出した方がいいか?

ただ単に「ありがとうございました」だけの記事の投稿は無駄である。一連の投稿のまとめとして、最初自分がどういう問題で投稿したのか、そして最終的にどのように解決できたのかを書いた上で「ありがとうございました」と書いて投稿すれば、他の人にとっても有益なもので有り得る。

大事なことは、読む人 (特に、お礼を言う相手だけじゃなく、その他大勢の人々) のことを考えて書くことである。純粋にお礼のみの記事は、情報量ゼロなのでゴミ記事といえる。また、「これから試します」「いまダウンロードしています」のような記事もやっぱりゴミである。

また、「ありがとうございました」のような題名 (Subject) をつけるのも良くない。むしろそのままの題名にしておいた方が、どの記事に関する結果やお礼なのかが分かりやすいといえる。

16. WWW のデータシート等をダウンロードして見ると、小文字のウやヨを散見する。

Copyright を表す (C)[&copy;] や Registered trade mark (R)[&reg;] の文字コードが、MS 漢字コードではそれぞれ半角のゥやョに割り当てられてしまっているので、このようなことが起こる場合がある。

フォントとして Courier New や Lucida Console 等の欧文フォントを使用したり、表示 - 文字コードセットで欧米 (ISO-8859-1) を指定してやれば (C) や (R) の記号が見えるだろう。

ちなみに、Netscape Communicator 4.5 は、日本語設定のままで、(C) や (R) を表示してくれるようになっている。

17. 迷惑な無差別送信メールを SPAM と呼ぶのは、何が由来か?

元ネタとよく言われるのは、70 年代の頃に英国 BBC 放送で放映していたモンティパイソンというコント番組の中で、SPAM が必ずついてくるレストランというネタである。

あるカップルがレストランに入って注文すると、なぜかどのメニューにも SPAM がついていて、「SPAM のないメニューはないんかい !!」とキレてしまうネタがある。別に望んでもいないのに勝手に SPAM をつけられるということから、こっちが望んでもいないのに向こうから勝手に押し付けられるような状況を SPAM と称しているのだろう。

モンティパイソンに関する日本語のページとしては、以下が詳しい。
http://www.yo.rim.or.jp/~manp/

また、元ネタとなったと言われているモンティパイソンのスキットの台本は、以下で読むことができる。
http://www.stone-dead.asn.au/tv-series/sketches/fc-25/spam-sketch.html

尚、SPAM という商品の宣伝がメールで流れたのが由来というのは嘘である。SPAM の製造元である Hormel Foods は、この商品イメージと迷惑メールを関連付けることに対して抗議している。
http://www.spam.com/ci/ci_in.htm



Index