[23] Subject: 欄は、電子メイルや電子ニュースで、記事の主題を書く頭欄です。
多くの MUA, ニュース・リーダーでは記事一覧やタイトル・バーに使われ、記事の引用の際にもよく注記されるなど、メッセージにおいて極めて重要な責を担っていると言えるでしょう。
[58] 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,」しかないように見えたりします。
[72] 伝統的には RFC 822 の定める ASCII の他に、 世界各地の文字コードも使われました。 日本では ISO-2022-JP のほか、シフトJIS、日本語EUC も一部用いられました。
[24] Subject: 欄の charset についての話題は他の頭欄も含めた一般的な話題としてメッセージの頭 (>>4)に移転しました。
[73]
現在では MIME により、 US-ASCII と符号化語によって表されるのがほとんどです。
[59] MIME では Subject: は符号化語を使う対象となっています。
[74]
文字コードは他のヘッダーの場合と同様で、
UTF-8
が多くなっていますが、
ISO-2022-JP を始めとする従来の文字コードも使われています。
[60] 他の各種の慣習と符号化語との関係性は明確になっていませんでした。 MIME と符号化語が実質的に必須となっている現在では、 符号化語を解釈した結果に対して各種の慣習が適用されると判断するべきと考えられます。 過渡期には混乱がありました。
[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
qr/(?: [Rr][Ee] \^? \[? \d+ \]? : \s* )+/x
[54] ポジティブな ToriさんはTwitterを使っています 「メール件名が "re:Invent" ではじまっていると Outlook が丁寧に "re:" を消して表示してくれるので目が泳いでしまって重要なメールを見逃すことがあるという最新 Tips をみなさんに共有したいです」 / Twitter (, ) https://twitter.com/toricls/status/1458647732164259847
[62]
転送したメールの Subject: は元の Subject:
の前に Fw: や Fwd:
を付け足す慣習があります。
返信記事の 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..] も消しちゃうけど、 これは必ずしも良い結果とは思えない。返信記事の著者の判断に 委ねるべき。
See also Control:領域, 制御メッセージ
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日施行)によると... (抜粋)
この手法がタコなことは一目瞭然でぼろくそに言われてます。 真面目に撥ねるには、 RFC 2047 encoded-word があればそれをほどいて、 全体の文字コードを適当な処理しやすいものに変換して、 かつその時正規化 (FULLWIDTH -> HALFWIDTH とか。) してから match するか確認しないと。
実例はまだ観測されてないけど、「連絡先無し」も登場しそうな予感。
手抜きで「!広告!」の MIME encoded-word の encode されたのを match するか確認しようとすると、
とか。それから伝統的な生 JIS の場合も、上記の下半分と 同じことが言えますね。
ここまでして撥ねたいか? って気もする。撥ねるなら最初に書いたように 真面目に decode するか、経費対効果の平衡で適当に手を打つか。
てか、そこまでして送り付けたいか? -> 広告送信者
2002年7月1日に、「!広告!」および「!連絡方法無!」 のあの施行規則が、パワーアップ(?)して再登場。
こんなあやしげな規定になってます。
○特定商取引に関する法律施行規則
販売業者又は役務提供事業者は、前項第九号に掲げる事項に
ついて、その広告の用に供される電磁的記録の表題部の最前部
に、本文で用いられるものと同一の文字コードを用いて符号化
することにより「未承諾広告※」と表示しなければならない。
ただし、電磁的記録の表題部の表示が、当該電磁的記録の送信
に必要な範囲において他の符号化方法により重ねて符号化され
るときは、重ねて符号化される前の文字コードが本文で用いら
れるものと同一の文字コードでなければならない。
これと同じ様なのが計3箇所あります。
ところで、関連法規全部読んだわけじゃないので断言できませんが、
は未定義じゃないですか? (まあ「符号化」は一般用語ってことにしといて。)
どーやら、なにもわかっとらんアホ役人がアホ論理でごり押ししたらしーぞ。
この規定はシンプルメールトランスファープロトコルを利用して 送った時だけ適用されるらしいですよ。
WSP / IDSP) を挟んでおきました(藁)。s/[^未承諾広告※]+//g の結果 == '未承諾広告※' でも評価しますか? (藁== じゃなくて eq でしたね。 (いまでもたまに引っかかります。)subject = "未承諾広告※" real-subject が一番多くて、 subject = "未承諾広告※" 1*(FWS / IDSP) real-subject が幾つか, 1つだけsubject = "「未承諾広告※」" real-subject というのもありました。また、 ML 経由で届いたものには当然 ML のメッセージ番号が前についてました。subject = real-subject "※未承諾広告※" ってのもあった。subject = "末承諾広告※" real-subject ってのもあるそうですね(w[53]
要約の配信形式を定めていた RFC 1153
は、
その場合の
Subject:
の記述方法も定めていました。
[32] Subject: の最初に [Q] とかつけて質問だと表す人もいる。 意味があるのか不明だけど、慣習的には無視してそのまま「Re: [Q]ほげほげ」 にするみたい。まあ好きにしたら? (意味不明)
[33] [C] って書くのが fj.* とかでそれなりに使われてる。茶々の意。
[34] OT: と書いて話題外 off topic であることを示す (ML とかニュース組とかで。) ことがあるらし。
[35] メッセージの話題の分類的なものを [・・・] で括ってはじめに記すことがよくあります。
[51] outlook.jpでメールのタイトルに「【】」という括弧を2組以上使うとメールが送信できないというトラブル | スラド IT () https://it.srad.jp/story/19/12/16/1453259/
たまに「教えて下さい」「〜してもいいですか」みたいに文を Subject: にいれる 人がいるけど、個人的には好ましくないと。 Subject: の中身は名詞格で 「日本語への翻訳」とか「来月の会合についての連絡事項」みたいたるべき と思うのですね。
(もちろん、効果的に文とかにした方がいい場合もあるでしょう。 「電子メイルはお好きですか?」とか。)
特に技術系メイル・リストなんかだと、「教えて下さい」みたいな Subject: は嫌われてます。この根拠は大抵、内容を明確に表してないとか、 過去ログ(何)の検索性とかに求められます。
でも内容が質問であるなら、「教えて下さい」はある程度内容を正確に 表しています。ですから提示するならもっと突っ込んだ根拠を示すべきであります。 過去記事の検索性はもちろんですが、現代的には全文検索が提供されているのが 普通です。
質問が主の ML だと、メイルの内容が「教えて下さい」(またはそれへの回答) であることは明らかです。ここまで仮定して初めて、「教えて下さい」 は何ら情報を伝達しない Subject であると断言出来ます。 Subject: 欄は MUA において記事一覧にほとんどの場合において提示されて、 記事内容を読むかどうかの有力な選択肢として与えられるという 認識はかなり一般的なものと考えられます。ですから過去の記事としての検索性 よりも更に、現在の記事としての要約性が重要であると思われます。
(ほとんどの ML において過去の記事の保管は副次的なものであって、 それを強調し過ぎるのは本末転倒というものでしょう。)
携帯電話から送られてくるメイルがよくこうなってる。うざい。
[5] 料金の比較的安い、ふつーな方の携帯電話のメイル・サービスだと、 Message from 〜 になるらしいです。
[30] Subject: 欄に送信者の所属や名前を入れる人達もいます。
誰からのメッセージかわかりやすいからそうするべきだと主張する人もいます。
[31] 就活系マナー講師のアドバイスの類などでは、採用担当者等に電子メイルを送信する際に
Subject: に自身 (求職者) の所属や名前を入れると採用担当者が見落とさなくてよいなどと助言していることがあるようです。
[57] 営業系の人達は自分の名前や所属を書くことがあります。逆に宛先を書くことがあります。
[56] 特に怪しいML(謎)でわけのわからん Subject: をつけた メイルが多いのは、某M$製MUAで本文の最初の数行が記事一覧 に表示されるから、ちゃんとつける必要はない、ってことだったのか!
[28] Subject: ヘッダーは、
HTML の title 要素と似ています。
[47] HTMLメールでは、MUA は title
ではなく、 Subject: を題名として表示します。
[48] HTML Standard は、 title 要素を原則として必須としていますが、
Subject: のようなプロトコル側の題名の指定が存在する時は、
省略を認めています。
title も参照。form 要素 subject 属性 (HTML)a 要素 subject 属性 (HTML)[39] NCSA Mosaic で実装されていたようです。
message/external-body MIME型 subject 引数[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
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".