[23] [CODE[Subject:]] 欄は、[[電子メイル]]や[[電子ニュース]]で、記事の主題を書く[[頭欄]]です。 多くの [[MUA]], [[ニュース・リーダー]]では記事一覧や[[タイトル・バー]]に使われ、記事の引用の際にもよく注記されるなど、メッセージにおいて極めて重要な責を担っていると言えるでしょう。 * 「Re: 」慣習 Re はラテン語起源の英単語だけど、これは他の言語に翻訳するべきじゃない。 「返: 」とか (これ「Re: 」と等価じゃないし。) 「Sv: 」とか「Odp: 」とか (何語?) は駄目。 「Re(2):」とか「Re^2:」とか「Re[2]:」とか書く人もいるけど不適当。 「Re: Re: Re: Re:」とかみっともないのもたまに見かける。 返信時にばっさり消すべし。 [[iモード]]で「Re>」とかいうわけのわからないのを つけてくる機種があるらしい。 - [25] [[RFC2822]] と [[Usefor]] にも説明があります。 [[ietf-822]] の記事 で、 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] * 「was」慣習 返信記事の Subject: を変える時、前の記事の Subject: を残しておく was 慣習がある。「ほげほげ (was: Foo Bar)」みたいに。 UI 的には、これが簡単に出来る項目 (例えば「新しい主題で返信」) があっても良いかも。 けど何度も返信してるのにいつまでも was がついてるのはみっともない。 ひどい時は「かくかく (was ほげほげ (was: Foo Bar))」になったりして。 だから、返信時に was があったら、代理者は消すのが良いかも。 ([[usefor]]も減らせたら良いかも☆って。) was の最後に「:」をつけたりつけなかったり。[[usefor]]の例は ついてるから、つけるのが良いかも。これも翻訳しない方がいいと思われ。 なお、 Subject 変更時の -_- 慣習 (See [[Message-ID:領域]]) は無視して良いと思われ。 ([[usefor]] にも載ってない。) [[#comment]] * メイル・リスト名・番号を付け足す慣習 転送時によく付けられる「Fwd:」, 「Fw:」、 ML でよくある 「[ML-NAME:12345]」なんてのも消すのが良い。「Re: [ML-Name:12345] Re: [ML-NAME:11456]」 みたいに入り組んでるのも消してやると親切。 だけど調子に乗ると、こうした「構造」ではないもの、 例えば「[Announce] chicago meeting agenda」の [Ann..] も消しちゃうけど、 これは必ずしも良い結果とは思えない。返信記事の著者の判断に 委ねるべき。 [[#comment]] * 「cmsg 」法 (obsolete) See also [[Control:領域]], [[制御メッセージ]] [[#comment]] * 広告の目印 [[#comment]] ** 「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. [[#comment]] ** 「!広告!」, 「!連絡方法無!」 日本国経済産業省・特定商取引に関する法律施行規則の一部を改正する省令 (2002年2月1日施行)によると... (抜粋) - メールの件名欄に「!広告!」と表示 - 連絡方法を設定しない場合には、件名欄に「!連絡方法無!」と表示 - - 施行について (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]] は考慮する必要はないかもしれません。 [[#comment]] ** 「未承諾広告※」 2002年7月1日に、「!広告!」および「!連絡方法無!」 のあの施行規則が、パワーアップ(?)して再登場。 こんなあやしげな規定になってます。 > ○特定商取引に関する法律施行規則 > 販売業者又は役務提供事業者は、前項第九号に掲げる事項に > ついて、その広告の用に供される電磁的記録の表題部の最前部 > に、本文で用いられるものと同一の文字コードを用いて符号化 > することにより「未承諾広告※」と表示しなければならない。 > ただし、電磁的記録の表題部の表示が、当該電磁的記録の送信 > に必要な範囲において他の符号化方法により重ねて符号化され > るときは、重ねて符号化される前の文字コードが本文で用いら > れるものと同一の文字コードでなければならない。 これと同じ様なのが計3箇所あります。 ところで、関連法規全部読んだわけじゃないので断言できませんが、 - 表題部 - 本文 - 文字コード - 表示 - 「文字コード」と「符号化方法」の関係 は未定義じゃないですか? (まあ「符号化」は一般用語ってことにしといて。) どーやら、なにもわかっとらんアホ役人がアホ論理でごり押ししたらしーぞ。 この規定はシンプルメールトランスファープロトコルを利用して 送った時だけ適用されるらしいですよ。 - 迷惑メール対策 - - - (参考) (総務省)デンシメール関係施策 - [3] ''iモード�における「未承諾広告※」メールの受信拒否機能等の提供'' <2002.7.2>'' '' - [4] ''iモードにおける未承諾広告※メールの受信拒否機能等を提供開始'' <2002.9.3>'' '' - [1] 「最前部」以外のところに「未承諾広告※」が入っている、規則には反するのをみたことがあります。 - [2] 巷では「未承諾広告 ※」や「 未承諾広告※」なども流通しているようです。 ([[MIME]] [[encoded-word]] の[[空白間隔]]問題だけでなく、意図的にやっているのもあるらしい。) - [6] ''電磁的記録''って例えば[[穿孔テープ]]は適用除外でしょうかね? - [7] あほらしいけど [[Message::Field::Subject]] では実装しました。広告かどうかの判定が出来ます。「未承諾広告」は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 [[#comment]] * その他接頭辞 [32] Subject: の最初に [Q] とかつけて質問だと表す人もいる。 意味があるのか不明だけど、慣習的には無視してそのまま「Re: [Q]ほげほげ」 にするみたい。まあ好きにしたら? (意味不明) [33] [C] って書くのが [[fj.*]] とかでそれなりに使われてる。[[茶々]]の意。 [34] OT: と書いて話題外 off topic であることを示す (ML とかニュース組とかで。) ことがあるらし。 [35] メッセージの話題の分類的なものを [・・・] で括ってはじめに記すことがよくあります。 * 実質的本体 たまに「教えて下さい」「〜してもいいですか」みたいに文を Subject: にいれる 人がいるけど、個人的には好ましくないと。 Subject: の中身は名詞格で 「日本語への翻訳」とか「来月の会合についての連絡事項」みたいたるべき と思うのですね。 (もちろん、効果的に文とかにした方がいい場合もあるでしょう。 「電子メイルはお好きですか?」とか。) 特に[[技術系メイル・リスト]]なんかだと、「教えて下さい」みたいな Subject: は嫌われてます。この根拠は大抵、内容を明確に表してないとか、 [[過去ログ]](何)の検索性とかに求められます。 でも内容が質問であるなら、「教えて下さい」はある程度内容を正確に 表しています。ですから提示するならもっと突っ込んだ根拠を示すべきであります。 過去記事の検索性はもちろんですが、現代的には全文検索が提供されているのが 普通です。 質問が主の ML だと、メイルの内容が「教えて下さい」(またはそれへの回答) であることは明らかです。ここまで仮定して初めて、「教えて下さい」 は何ら情報を伝達しない Subject であると断言出来ます。 Subject: 欄は MUA において記事一覧にほとんどの場合において提示されて、 記事内容を読むかどうかの有力な選択肢として与えられるという 認識はかなり一般的なものと考えられます。ですから過去の記事としての検索性 よりも更に、現在の記事としての要約性が重要であると思われます。 (ほとんどの ML において過去の記事の保管は副次的なものであって、 それを強調し過ぎるのは本末転倒というものでしょう。) - [19] 単に検索がしにくいってなら検索を改善する方が前向きだと思うしね。 - [20] 結局、検索性の良い Subject は (ML の位置づけにもよるが) それ程重要な条件とは思えない。もっとまともな Subject を書けって言う人は、検索性なんていうつまらない理由よりもっと言わないといけないことが他にあるでしょうと問詰めてみたいもんです。 [[#comment]] * Message from 〜 携帯電話から送られてくるメイルがよくこうなってる。うざい。 - [11] ''Message from SkyMail'' とか。 - [14] ''Message for [VAR[宛先の local-part]]'' になってるのもありますね。今見たやつは [[DoCoMo]] からでした - [21] Subject がなければならないという義務感?からこういうことをしてるのかな、携帯電話会社は。確かにそういう主張をする人もいるけど、携帯電話でよくある短いちょっとしたメッセージに主題なんて一々明記してられないし、する必要もないと思うんだな。 - [22] >>21 で、本文を解釈して勝手に summary 的 subject をつけてくれるなら別として、 >>11,>>14 のような意味のない、むしろ主題でもなんでもない間違った値を勝手に入れるのはどういう了見かね。 * 著者の名前を入れる人達 [30] [CODE(822)@en[[[Subject]]:]] 欄に送信者の所属や名前を入れる人達もいます。 誰からのメッセージかわかりやすいからそうするべきだと主張する人もいます。 ;; [CODE(822)@en[[[From]]:]] 欄の存在を知らないのでしょうかね。 それに対応していない [[MUA]] など存在しないと思うのですが。 どれだけ目立ちたがりなのでしょう。 [31] [[就活]]のアドバイスの類などでは、採用担当者等に[[電子メイル]]を送信する際に [CODE(822)@en[[[Subject]]:]] に自身 ([[求職者]]) の所属や名前を入れると採用担当者が見落とさなくてよいなどと助言していることがあるようです。 * 雑 特に怪しいML(謎)でわけのわからん Subject: をつけた メイルが多いのは、某M$製MUAで本文の最初の数行が記事一覧 に表示されるから、ちゃんとつける必要はない、ってことだったのか! [[電子ニュース]] [RFC1036] って、 Subject: 領域が必須だから、 ちょっと不便。 - [5] 料金の比較的安い、ふつーな方の[[携帯電話]]のメイル・サービスだと、 ''Message from [VAR[〜]]'' になるらしいです。 - [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,」しかないように見えたりします。 - [18] ML によっては必ず宛先を Subject にかく (○○さんへ) とか変な風習があるところがありますね - [24] [CODE[Subject:]] 欄の [[charset]] についての話題は他の[[頭欄]]も含めた一般的な話題として[[メッセージの頭]>>4]に移転しました。 * [CODE(HTMLe)@en[form]] 要素 [CODE(HTMLa)@en[subject]] 属性 @@ [29] ・・・ (see also [[[CODE(HTMLa)@en[title]]属性]]) * 関連 [28] [[HTML]] の [CODE(HTMLe)@en[[[title]]]] [[要素]]と似ています。 [37] [CITE[【2ch】ニュー速クオリティ:メール返信の時、題名を「Re」で返してくる奴って何か失礼じゃない?]] ([TIME[2009-11-10 08:00:57 +09:00]] 版) [38] [CITE@en[AH Formatter XSL/CSS Extension]] ( ([TIME[2013-07-23 07:02:25 +09:00]] 版))