[23]

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

構文

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

折り畳み

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

[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,」しかないように見えたりします。

文字コード

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

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

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

符号化語

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

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

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

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

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

「Re: 」慣習

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

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

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

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

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

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

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

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

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

[55] 画面の左から右まで「Re: Re: Re:」って並んでるやばいメールが令和の今も送られてくるのどういう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]

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

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

「Fw: 」「Fwd: 」慣習

[62] 転送したメールの Subject: は元の Subject: の前に Fw: や 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モード�における「未承諾広告※」メールの受信拒否機能等の提供 <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文字毎に *(WSP / IDSP) を挟んでおきました(藁)。
[8] 2002-11-17 (日) 19:46 わかば: >>7 すごいあほらしいでしょ? もっと徹底させるなら、 s/[^未承諾広告※]+//g の結果 == '未承諾広告※' でも評価しますか? (藁
[9] 2002-11-17 (日) 19:46 >>8: perl なら == じゃなくて eq でしたね。 (いまでもたまに引っかかります。)
[10] 2002-11-18 (月) 16:10 !連絡方法無!: うちにあったのを眺めてみました。 subject = "未承諾広告※" real-subject が一番多くて、 subject = "未承諾広告※" 1*(FWS / IDSP) real-subject が幾つか, 1つだけsubject = "「未承諾広告※」" real-subject というのもありました。また、 ML 経由で届いたものには当然 ML のメッセージ番号が前についてました。
[13] subject = real-subject "※未承諾広告※" ってのもあった。
[17] 2002-12-25 18:46 !連絡方法無!: subject = "末承諾広告※" real-subject ってのもあるそうですね(w

PEM

>>45

RFC 1153

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

その他接頭辞

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

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

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

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

[51] outlook.jpでメールのタイトルに「【】」という括弧を2組以上使うとメールが送信できないというトラブル | スラド IT (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 宛先の local-part になってるのもありますね。今見たやつは DoCoMo からでした
[21] Subject がなければならないという義務感?からこういうことをしてるのかな、携帯電話会社は。確かにそういう主張をする人もいるけど、携帯電話でよくある短いちょっとしたメッセージに主題なんて一々明記してられないし、する必要もないと思うんだな。
[22] >>21 で、本文を解釈して勝手に summary 的 subject をつけてくれるなら別として、 >>11,>>14 のような意味のない、むしろ主題でもなんでもない間違った値を勝手に入れるのはどういう了見かね。

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

著者の名前を入れる人達

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

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

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

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

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

構文

折り畳み

文字コード

符号化語

「Re: 」慣習

「Fw: 」「Fwd: 」慣習

「was」慣習

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

「cmsg 」法 (obsolete)

広告の目印

「ADV:」

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

「未承諾広告※」

PEM

RFC 1153

その他接頭辞

実質的本体

Message from 〜

著者の名前を入れる人達

雑

HTML の題名

`form` 要素 `subject` 属性 (HTML)

`a` 要素 `subject` 属性 (HTML)

`message/external-body` MIME型 `subject` 引数

歴史

JIS

構文

折り畳み

文字コード

符号化語

「Re: 」慣習

「Fw: 」「Fwd: 」慣習

「was」慣習

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

「cmsg 」法 (obsolete)

広告の目印

「ADV:」

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

「未承諾広告※」

PEM

RFC 1153

その他接頭辞

実質的本体

Message from 〜

著者の名前を入れる人達

雑

HTML の題名

form 要素 subject 属性 (HTML)

a 要素 subject 属性 (HTML)

message/external-body MIME型 subject 引数

歴史

JIS

`form` 要素 `subject` 属性 (HTML)

`a` 要素 `subject` 属性 (HTML)

`message/external-body` MIME型 `subject` 引数