題名

Subject: ヘッダー (インターネットメール)

[23] Subject: 欄は、電子メイル電子ニュースで、記事の主題を書く頭欄です。 多くの MUA, ニュース・リーダーでは記事一覧やタイトル・バーに使われ、記事の引用の際にもよく注記されるなど、メッセージにおいて極めて重要な責を担っていると言えるでしょう。

「Re: 」慣習

Re はラテン語起源の英単語だけど、これは他の言語に翻訳するべきじゃない。 「返: 」とか (これ「Re: 」と等価じゃないし。) 「Sv: 」とか「Odp: 」とか (何語?) は駄目。

「Re(2):」とか「Re^2:」とか「Re[2]:」とか書く人もいるけど不適当。 「Re: Re: Re: Re:」とかみっともないのもたまに見かける。 返信時にばっさり消すべし。

iモードで「Re>」とかいうわけのわからないのを つけてくる機種があるらしい。 <http://www.fml.org/mlarchives/MHL/fml-help/msg154.html>

[36]

qr/(?: [Rr][Ee] \^? \[? \d+ \]? : \s* )+/x

「was」慣習

返信記事の Subject: を変える時、前の記事の Subject: を残しておく was 慣習がある。「ほげほげ (was: Foo Bar)」みたいに。 UI 的には、これが簡単に出来る項目 (例えば「新しい主題で返信」) があっても良いかも。

けど何度も返信してるのにいつまでも was がついてるのはみっともない。 ひどい時は「かくかく (was ほげほげ (was: Foo Bar))」になったりして。 だから、返信時に was があったら、代理者は消すのが良いかも。 (useforも減らせたら良いかも☆って。)

was の最後に「:」をつけたりつけなかったり。useforの例は ついてるから、つけるのが良いかも。これも翻訳しない方がいいと思われ。

なお、 Subject 変更時の -_- 慣習 (See Message-ID:領域) は無視して良いと思われ。 (usefor にも載ってない。)

メイル・リスト名・番号を付け足す慣習

転送時によく付けられる「Fwd:」, 「Fw:」、 ML でよくある 「[ML-NAME:12345]」なんてのも消すのが良い。「Re: [ML-Name:12345] Re: [ML-NAME:11456]」 みたいに入り組んでるのも消してやると親切。

だけど調子に乗ると、こうした「構造」ではないもの、 例えば「[Announce] chicago meeting agenda」の [Ann..] も消しちゃうけど、 これは必ずしも良い結果とは思えない。返信記事の著者の判断に 委ねるべき。

「cmsg 」法 (obsolete)

See also Control:領域, 制御メッセージ

広告の目印

「ADV:」

1999年発効の米国加州法ではこう決まっているらしい。

In the case of e-mail that consists of unsolicited advertising

material for the lease, sale, rental, gift offer, or other

disposition of any realty, goods, services, or extension of credit,

the subject line of each and every message shall include "ADV:"

as the first four characters.

「!広告!」, 「!連絡方法無!」

日本国経済産業省・特定商取引に関する法律施行規則の一部を改正する省令 (2002年2月1日施行)によると... (抜粋)

  • メールの件名欄に「!広告!」と表示
  • 連絡方法を設定しない場合には、件名欄に「!連絡方法無!」と表示
voice mail な受信代理者だったらどうやって「表示」するんだろ? そんなとこまで送信者が面倒見ないといけないの?

この手法がタコなことは一目瞭然でぼろくそに言われてます。 真面目に撥ねるには、 RFC 2047 encoded-word があればそれをほどいて、 全体の文字コードを適当な処理しやすいものに変換して、 かつその時正規化 (FULLWIDTH -> HALFWIDTH とか。) してから match するか確認しないと。

実例はまだ観測されてないけど、「連絡先無」も登場しそうな予感。

手抜きで「!広告!」の MIME encoded-word の encode されたのを match するか確認しようとすると、

  • 大文字・小文字の違いを無視する (「ISO-2022-JP」, 「B」, 「Q」)
  • 「!」の(暗号化されたものの)全角・半角を無視する
  • 「!」が ASCII なら encoded-word の外にある可能性。
  • あるいは外で =?us-ascii?q?!?= とか =?us-ascii?q?=3F?= な可能性。
  • そうなると encoded-word 間に一杯 FWS で継続行だったり:-)
  • 最後の「!」で encoded-word は終わりと思いきや、次の文字(例えば「☆」?)が続いているという罠:-)
  • ISO-2022-JP 中で頻繁に ESC $ B / ESC ( B が登場してるとか。
  • ISO-2022-JP 中で ESC $ @, ESC ( J, はたまた ESC ( H が使われてるとか:-)
  • ISO-2022-JP じゃなくて Shift_JIS や UTF-8 や ISO-10646-UTF-1 の可能性が...

とか。それから伝統的な生 JIS の場合も、上記の下半分と 同じことが言えますね。

ここまでして撥ねたいか? って気もする。撥ねるなら最初に書いたように 真面目に decode するか、経費対効果の平衡で適当に手を打つか。

てか、そこまでして送り付けたいか? -> 広告送信者

  • [12] 「未承諾広告※」になってから、 (当然といえば当然ですが) まったく見なくなりました。 新しい UA は考慮する必要はないかもしれません。

「未承諾広告※」

2002年7月1日に、「!広告!」および「!連絡方法無!」 のあの施行規則が、パワーアップ(?)して再登場。

こんなあやしげな規定になってます。

○特定商取引に関する法律施行規則

販売業者又は役務提供事業者は、前項第九号に掲げる事項に

ついて、その広告の用に供される電磁的記録の表題部の最前部

に、本文で用いられるものと同一の文字コードを用いて符号化

することにより「未承諾広告※」と表示しなければならない。

ただし、電磁的記録の表題部の表示が、当該電磁的記録の送信

に必要な範囲において他の符号化方法により重ねて符号化され

るときは、重ねて符号化される前の文字コードが本文で用いら

れるものと同一の文字コードでなければならない。

これと同じ様なのが計3箇所あります。

ところで、関連法規全部読んだわけじゃないので断言できませんが、

  • 表題部
  • 本文
  • 文字コード
  • 表示
  • 「文字コード」と「符号化方法」の関係

は未定義じゃないですか? (まあ「符号化」は一般用語ってことにしといて。)

どーやら、なにもわかっとらんアホ役人がアホ論理でごり押ししたらしーぞ。

この規定はシンプルメールトランスファープロトコルを利用して 送った時だけ適用されるらしいですよ。

その他接頭辞

[32] Subject: の最初に [Q] とかつけて質問だと表す人もいる。 意味があるのか不明だけど、慣習的には無視してそのまま「Re: [Q]ほげほげ」 にするみたい。まあ好きにしたら? (意味不明)

[33] [C] って書くのが fj.* とかでそれなりに使われてる。茶々の意。

[34] OT: と書いて話題外 off topic であることを示す (ML とかニュース組とかで。) ことがあるらし。

[35] メッセージの話題の分類的なものを [・・・] で括ってはじめに記すことがよくあります。

実質的本体

たまに「教えて下さい」「〜してもいいですか」みたいに文を Subject: にいれる 人がいるけど、個人的には好ましくないと。 Subject: の中身は名詞格で 「日本語への翻訳」とか「来月の会合についての連絡事項」みたいたるべき と思うのですね。

(もちろん、効果的に文とかにした方がいい場合もあるでしょう。 「電子メイルはお好きですか?」とか。)

特に技術系メイル・リストなんかだと、「教えて下さい」みたいな Subject: は嫌われてます。この根拠は大抵、内容を明確に表してないとか、 過去ログ(何)の検索性とかに求められます。

でも内容が質問であるなら、「教えて下さい」はある程度内容を正確に 表しています。ですから提示するならもっと突っ込んだ根拠を示すべきであります。 過去記事の検索性はもちろんですが、現代的には全文検索が提供されているのが 普通です。

質問が主の ML だと、メイルの内容が「教えて下さい」(またはそれへの回答) であることは明らかです。ここまで仮定して初めて、「教えて下さい」 は何ら情報を伝達しない Subject であると断言出来ます。 Subject: 欄は MUA において記事一覧にほとんどの場合において提示されて、 記事内容を読むかどうかの有力な選択肢として与えられるという 認識はかなり一般的なものと考えられます。ですから過去の記事としての検索性 よりも更に、現在の記事としての要約性が重要であると思われます。

(ほとんどの ML において過去の記事の保管は副次的なものであって、 それを強調し過ぎるのは本末転倒というものでしょう。)

Message from 〜

携帯電話から送られてくるメイルがよくこうなってる。うざい。

著者の名前を入れる人達

[30] Subject: 欄に送信者の所属や名前を入れる人達もいます。 誰からのメッセージかわかりやすいからそうするべきだと主張する人もいます。

From: 欄の存在を知らないのでしょうかね。 それに対応していない MUA など存在しないと思うのですが。 どれだけ目立ちたがりなのでしょう。

[31] 就活のアドバイスの類などでは、採用担当者等に電子メイルを送信する際に Subject: に自身 (求職者) の所属や名前を入れると採用担当者が見落とさなくてよいなどと助言していることがあるようです。

特に怪しいML(謎)でわけのわからん Subject: をつけた メイルが多いのは、某M$製MUAで本文の最初の数行が記事一覧 に表示されるから、ちゃんとつける必要はない、ってことだったのか!

電子ニュース [RFC1036] って、 Subject: 領域が必須だから、 ちょっと不便。

[16] 折り畳みがちゃんと実装されていても、解釈の違いにより妙に空白間隔の多い Subject として認識されることがあります。例えば、 Mozilla 1.2.1 では

 Subject: BCP 66,
              RFC 3406 on Uniform Resource Names (URN) Namespace Definition
              Mechanisms

 Subject: BCP 66,             RFC 3406 on Uniform (後略)

と認識するようです。結果としてメッセージ一覧の Subject の欄が狭いと 「BCP 66,」しかないように見えたりします。

HTML の題名

[28] Subject: ヘッダーは、 HTMLtitle 要素と似ています。

[47] HTMLメールでは、MUAtitle ではなく、 Subject:題名として表示します。

[48] HTML Standard は、 title 要素を原則として必須としていますが、 Subject: のようなプロトコル側の題名の指定が存在する時は、 省略を認めています。

title も参照。

form 要素 subject 属性 (HTML)

[29] ・・・ (see also title属性)

a 要素 subject 属性 (HTML)

[39] NCSA Mosaic で実装されていたようです。

message/external-body MIME型 subject 引数

歴史

JIS

[49] 見出しの一部であって、メッセージ内容を要約したもの。 発信者が指定する。 Subject。 (JISX0032:1999 32.03.05)

[50] この定義じゃ summary と違いない気がするんだけどいいんか? (JIS電子メイル用語に summary はないからいいの?)

[37] 【2ch】ニュー速クオリティ:メール返信の時、題名を「Re」で返してくる奴って何か失礼じゃない? ( 版) <http://news4vip.livedoor.biz/archives/51392256.html>

[38] AH Formatter XSL/CSS Extension ( ( 版)) <http://antennahouse.com/CSSInfo/extension.html#IDANV3X>

[40] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) <http://tools.ietf.org/html/rfc3801#section-4.2.15>

[41] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ( ( 版)) <http://tools.ietf.org/html/rfc4130#appendix-A.1>

[42] RFC 5537 - Netnews Architecture and Protocols ( ( 版)) <http://tools.ietf.org/html/rfc5537#page-15>

[43] RFC 5536 - Netnews Article Format ( ( 版)) <http://tools.ietf.org/html/rfc5536#section-3.1.6>

[44] RFC 5965 - An Extensible Format for Email Feedback Reports ( 版) <http://tools.ietf.org/html/rfc5965#page-5>

[45] RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures ( 版) <https://tools.ietf.org/html/rfc989#section-4.4>

If disclosure protection is

desired for the "Subject:" field, it is recommended that the

enclosing header contain a "Subject:" field indicating that

"Encrypted Mail Follows".