Edit

Page

Page title:

Page body:

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

* 構文

[58] [CODE[Subject:]] は元々自由記述でしたが、いろいろな慣習が成立しています。
また、分野によっては構文の指定があります。

** 折り畳み

[SEE[ [[折り畳み]] ]]

- [15] [WEAK[2002-12-03 (火) 13:25]] ''[[!連絡方法無!]]'': [[encoded-word]] と[[折り畳み]]がちゃんと実装されていない [[MUA]] などで Subject がちょんぎれて見える現象は、未だに起こっているようです。 (encoded-word なんて糞な仕様にするからだ!) See [[encoded-word]>>1]

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

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

を

[PRE[
 Subject: BCP 66,             RFC 3406 on Uniform [INS[(後略)]]
]PRE]

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

** 文字コード

[72] 
伝統的には [[RFC 822]] の定める [[ASCII]] の他に、
世界各地の[[文字コード]]も使われました。
[[日本]]では [[ISO-2022-JP]] のほか、[[シフトJIS]]、[[日本語EUC]]
も一部用いられました。

[24] [CODE[Subject:]] 欄の [[charset]] についての話題は他の[[頭欄]]も含めた一般的な話題として[[メッセージの頭]>>4]に移転しました。

[73] 
現在では [[MIME]] により、 [CODE[US-ASCII]] と[[符号化語]]によって表されるのがほとんどです。

*** 符号化語

[59] [[MIME]] では [CODE[Subject:]] は[[符号化語]]を使う対象となっています。

[74] 
[[文字コード]]は他の[[ヘッダー]]の場合と同様で、
[CODE[UTF-8]]
が多くなっていますが、
[CODE[ISO-2022-JP]] を始めとする従来の[[文字コード]]も使われています。

[75] 
[[言語タグ]]構文は未実装のことが多いです。

[60] 
他の各種の慣習と[[符号化語]]との関係性は明確になっていませんでした。
[[MIME]] と[[符号化語]]が実質的に必須となっている現在では、
[[符号化語]]を解釈した結果に対して各種の慣習が適用されると判断するべきと考えられます。
過渡期には混乱がありました。
[EG[

[61] 例えば [CODE[Re: ]] を[[符号化語]]に含めてしまうかどうか [[MUA]]
によって異なり、 [CODE[Re: ]] の存在をうまく検出できなかったり、
[[返信]]のたびに [CODE[Re: ]] が増えていく原因になったりしていました。

]EG]

** 「Re: 」慣習

[64] 
[[返信]]は元の [CODE[Subject:]] の前に [CODE[Re: ]]
を付け足す慣習があります。

-*-*-

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

[65] 
しかし実際にはそうした例がいろいろあります。

[52] 
[[中華人民共和国]]では「回复: 」を使うことがあります。

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

-*-*-

[67] 
[[返信]]への[[返信]]では元の [CODE[Re: ]] があるのを十分としそれ以上付け足さないのが正当な慣習とされます。

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

[69] 
[[Unix]] 系や [[Usenet]] など伝統的な[[インターネット]]方面では
[CODE[Re: ]] を1つだけとする慣習が続いていました。

[70] 
一方で[[パソコン通信]]等からの移民や営業系の人々などは
[CODE[Re: ]] を重ねたり、
数値を入れたりしました。
技術的には [CODE[Subject:]] とは違いますが、
[[ウェブ]]の[[掲示板]]の記事題名でもそうした実装例が見られました。

[55] 
画面の左から右まで「Re: Re: Re:[SNIP[]]」って並んでるやばいメールが令和の今も送られてくるのどういう[[MUA]]使ってるんだろうwwww

-*-*-

- [25] [[RFC2822]] と [[Usefor]] にも説明があります。 [[ietf-822]] の記事 <mid:3D0420D6.40708@att.com> で、 Tony Hansen は、 2822 は間違っては無いがあまり正しくなく、 Usefor の方が良い表現だと評しています。
- [26] >>25 で、彼はよりよい表現としてこう述べています。「『Re』は[[ラテン語]]の単語『Res』の ablative (relational) case ([[奪格]]) で『こと (thing)』を意味して、よく、『〜について (in the matter of)』の意味の『in re』の形で使います。時々間違われますが、『Reference (参照)』,  『Reply (返信)』, 『Response (応答)』の略語ではありません。
- [27] >>26 ましてや[[レス]]の略ではないということでいいですか?

[36] 
[PRE(perl example code)[
qr/(?: [Rr][Ee] \^? \[? \d+ \]? : \s* )+/x
]PRE]

[54] [CITE@ja[ポジティブな ToriさんはTwitterを使っています 「メール件名が "re:Invent" ではじまっていると Outlook が丁寧に "re:" を消して表示してくれるので目が泳いでしまって重要なメールを見逃すことがあるという最新 Tips をみなさんに共有したいです」 / Twitter]]
([TIME[2021-11-15T08:39:47.000Z]], [TIME[2021-11-15T08:41:38.107Z]])
<https://twitter.com/toricls/status/1458647732164259847>

** 「Fw: 」「Fwd: 」慣習

[62] 
[[転送]]したメールの [CODE[Subject:]] は元の [CODE[Subject:]]
の前に [DFN[[CODE[Fw: ]]]] や [DFN[[CODE[Fwd: ]]]]
を付け足す慣習があります。

** 「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日施行)によると... (抜粋)

- メールの件名欄に「!広告!」と表示
- 連絡方法を設定しない場合には、件名欄に「!連絡方法無!」と表示

- <http://www.meti.go.jp/kohosys/press/0002285/> 
- 施行について (2002年2月1日) <http://www.meti.go.jp/kohosys/press/0002358/>

;; 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箇所あります。

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

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

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

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

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

- 迷惑メール対策 <http://www.meti.go.jp/policy/consumer/warehouse/tokushoho/spammail/spammail.html>
- <http://slashdot.jp/article.pl?sid=02/07/02/1559254&mode=thread>
- <http://k-tai.impress.co.jp/cda/article/news_toppage/0,,10038,00.html>
- (参考) (総務省)デンシメール関係施策 <http://www.soumu.go.jp/joho_tsusin/top/m_mail.html>
- [3] ''iモード&#65533;における「未承諾広告※」メールの受信拒否機能等の提供''
<2002.7.2>'' <http://www.nttdocomo.co.jp/new/contents/02/whatnew0702.html>''
- [4] ''iモードにおける未承諾広告※メールの受信拒否機能等を提供開始''
<2002.9.3>'' <http://www.nttdocomo.co.jp/new/contents/02/whatnew0903.html>''

- [1] 「最前部」以外のところに「未承諾広告※」が入っている、規則には反するのをみたことがあります。
- [2] 巷では「未承諾広告  ※」や「  未承諾広告※」なども流通しているようです。
([[MIME]] [[encoded-word]] 
の[[空白間隔]]問題だけでなく、意図的にやっているのもあるらしい。)
- [6] ''電磁的記録''って例えば[[穿孔テープ]]は適用除外でしょうかね?
- [7] あほらしいけど [[Message::Field::Subject]] <IW:SuikaCVS:"perl/lib/Message/Field/Subject.pm"> では実装しました。広告かどうかの判定が出来ます。「未承諾広告」は1文字毎に *([CODE(ABNF)[WSP]] / [CODE(CHARNAME)[IDSP]]) を挟んでおきました(藁)。
- [8] [WEAK[2002-11-17 (日) 19:46]] ''[[わかば]]'': >>7 すごいあほらしいでしょ? もっと徹底させるなら、 [CODE(perl)[s/[^未承諾広告※]+//g]] の結果 == '未承諾広告※' でも評価しますか? (藁
- [9] [WEAK[2002-11-17 (日) 19:46]] ''>>8'': [[perl]] なら [CODE(perl)[==]] じゃなくて [CODE(perl)[eq]] でしたね。 (いまでもたまに引っかかります。)
- [10] [WEAK[2002-11-18 (月) 16:10]] ''[[!連絡方法無!]]'': うちにあったのを眺めてみました。 [CODE(ABNF)[subject = "未承諾広告※" real-subject]] が一番多くて、 [CODE(ABNF)[subject = "未承諾広告※" 1*(FWS / IDSP) real-subject]] が幾つか, 1つだけ[CODE(ABNF)[subject = "「未承諾広告※」" real-subject]] というのもありました。また、 [[ML]] 経由で届いたものには当然 ML のメッセージ番号が前についてました。
- [13] [CODE(ABNF)[subject = real-subject "※未承諾広告※"]] ってのもあった。
- [17] [WEAK[2002-12-25 18:46]] ''[[!連絡方法無!]]'': [CODE(ABNF)[subject = "末承諾広告※" real-subject]] ってのもあるそうですね(w

** PEM

>>45

** RFC 1153

[53] 
[[要約]]の配信形式を定めていた [[RFC 1153]]
は、
その場合の
[CODE[Subject:]]
の記述方法も定めていました。
[SEE[ [[RFC 1153]] ]]

** その他接頭辞

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

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

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

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

[51] [CITE@ja[outlook.jpでメールのタイトルに「【】」という括弧を2組以上使うとメールが送信できないというトラブル | スラド IT]]
([TIME[2019-12-16 21:06:05 +09:00]])
<https://it.srad.jp/story/19/12/16/1453259/>

** 実質的本体

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

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

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

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

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

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

- [19] 単に検索がしにくいってなら検索を改善する方が前向きだと思うしね。
- [20] 結局、検索性の良い Subject は (ML の位置づけにもよるが) それ程重要な条件とは思えない。もっとまともな Subject を書けって言う人は、検索性なんていうつまらない理由よりもっと言わないといけないことが他にあるでしょうと問詰めてみたいもんです。

** Message from 〜

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

- [11] ''Message from SkyMail'' とか。
- [14] ''Message for [VAR[宛先の local-part]]'' になってるのもありますね。今見たやつは [[DoCoMo]] からでした
- [21] Subject がなければならないという義務感?からこういうことをしてるのかな、携帯電話会社は。確かにそういう主張をする人もいるけど、携帯電話でよくある短いちょっとしたメッセージに主題なんて一々明記してられないし、する必要もないと思うんだな。
- [22] >>21 で、本文を解釈して勝手に summary 的 subject をつけてくれるなら別として、 >>11,>>14 のような意味のない、むしろ主題でもなんでもない間違った値を勝手に入れるのはどういう了見かね。

[5] 料金の比較的安い、ふつーな方の[[携帯電話]]のメイル・サービスだと、 ''Message from [VAR[〜]]'' になるらしいです。

** 著者の名前を入れる人達

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

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

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

[57] 営業系の人達は自分の名前や所属を書くことがあります。逆に宛先を書くことがあります。

[18] [[ML]] 
によっては必ず宛先を Subject にかく (○○さんへ) とか変な風習があるところがありますね

* 雑

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

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

* HTML の題名

[28] [CODE(822)@en[[[Subject:]]]] [[ヘッダー]]は、
[[HTML]] の [CODE(HTMLe)@en[[[title]]]] [[要素]]と似ています。

[47] [[HTMLメール]]では、[[MUA]] は [CODE(HTMLe)@en[[[title]]]]
ではなく、 [CODE(822)@en[[[Subject:]]]] を[[題名]]として表示します。

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

;; [CODE(HTMLe)@en[[[title]]]] も参照。

* [CODE(HTMLe)@en[form]] 要素 [CODE(HTMLa)@en[subject]] 属性 (HTML)

@@ [29] ・・・
(see also [[[CODE(HTMLa)@en[title]]属性]])

* [CODE(HTMLe)@en[a]] 要素 [CODE(HTMLa)@en[subject]] 属性 (HTML)

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

* [CODE(MIME)@en[message/external-body]] MIME型 [CODE(MIME)@en[subject]] 引数

[REFS[
- [46] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.2.3.5>
]REFS]

* 歴史

** JIS

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

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

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

[38] [CITE@en[AH Formatter XSL/CSS Extension]]
( ([TIME[2013-07-23 07:02:25 +09:00]] 版))
<http://antennahouse.com/CSSInfo/extension.html#IDANV3X>

[40] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]]
( ([TIME[2014-09-07 15:46:36 +09:00]] 版))
<http://tools.ietf.org/html/rfc3801#section-4.2.15>

[41] [CITE@en[RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)]]
( ([TIME[2014-09-21 21:13:43 +09:00]] 版))
<http://tools.ietf.org/html/rfc4130#appendix-A.1>

[42] [CITE@en[RFC 5537 - Netnews Architecture and Protocols]]
( ([TIME[2014-09-14 17:08:11 +09:00]] 版))
<http://tools.ietf.org/html/rfc5537#page-15>

[43] [CITE@en[RFC 5536 - Netnews Article Format]]
( ([TIME[2014-09-21 18:14:06 +09:00]] 版))
<http://tools.ietf.org/html/rfc5536#section-3.1.6>

[44] [CITE@en[RFC 5965 - An Extensible Format for Email Feedback Reports]]
([TIME[2014-12-21 09:40:25 +09:00]] 版)
<http://tools.ietf.org/html/rfc5965#page-5>

[FIG(quote)[
[FIGCAPTION[
[45] [CITE@en[RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures]]
([TIME[2015-02-22 16:43:49 +09:00]] 版)
<https://tools.ietf.org/html/rfc989#section-4.4>
]FIGCAPTION]

>  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".

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)