アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
こう作ってみた。 (スコア:1)
--
意見
1.について
SMTPならばRFC821(STD 10)/2821の参照はできないものか。RFCのアーカイブは
http://www.faqs.org/rfcs/index.html(英文) に存在する。
なお、電子メールの形式ならばRFC822(STD 11)/2822に規定されている。
2.(1).1)について:
特定商取引法(経済産業省)との仕分けが未完成の状況で、両方に同じものを
指定しないばかりに片方に従えばもう片方が違法になると言う状況に陥るのは
望ましいことではない。最悪、両方の法律のこの部分の規定が両方とも無効と
取り扱われるおそれがある。
2.(1).6)について:
経路情報は発信者が付すものではない。発信者が保有する設備で経路情報をつ
けないように設定したりニセの経路情報をつけたりするな、だったら分かるが。
2.(1)の全般について
RFC2822を見れば分かるように、ヘッダ部と本文部に分けて考えないとおかし
なことになりかねない。1),4)はヘッダ部だし2),3),5)は本文部と考えないと受
信した方が困ることになる。
法第4条の通知に関する情報の取り扱いに関する規約の参照方法も併せて表示
させるべきと思料する。逆に「アクティブ電子メールリスト」として販売するな
どの方法により送信者が利益を得、受信者に大きなダメージを与えるおそれがあ
るため。(現状では規約の作成を強制する方法、作った規約を守らせる方法がな
いが。) 併せて言えば、HTML文書のハイパーリンクには、携帯端末等の受信者
から見えない状態で受信者識別情報を付し、ある電子メールアドレスが実際に利
用者が存在するものであるという情報を収集することができるので、2.(1)の各
項目の情報の掲載方法については、「HTML文書のハイパーリンクの先としてはな
らない」という規定もつけるべきと思われる。
2.(2)について
どの状態を「同一でない文字コード」と呼ぶのか不明。それこそ、ヘッダ部と
本文部に分ける必要がある。
ヘッダ部ではRFC2047に沿ってUS-ASCII以外の文字を一旦US-ASCIIの範囲にエ
ンコードして送り出すが、多分国内のメールソフトはiso-2022-jp以外受け付け
ないものがほとんどだと思われる。
本文部については、国内では2つのケースがあり得る。ひとつはRFC2237に沿っ
てしまう方法。もう一つはHTML文書の中に埋めてしまう方法である。前者なら文
字コードもこれ(+JIS X 0213の付属書2の方法)に固定してしまえばいい。HTMLの
中に埋めてしまう形式であれば、「同時に読むことができること」とすればいい
と考えられる。
4.について:
現在は検索エンジンなどが行うのと同様のロボットによるWeb上の情報収集の
上でWebの掲示者がのせている電子メールアドレスを収集する手法に移行してい
る。
しかし、この方法も、個人発信などの内容が十分に整備されていないWebにお
いて、もはや使われていない古い内容の電子メールアドレス記述が残っている場
合があり、それが大量に収集されて発信されると、受取手側では架空電子メール
の処理をさせられるのと同然の効果をもたらすことになる。
従って、この方法も「電子メールアドレスとして利用することが可能な符号を
作成する機能を有するプログラム」として規制すべきと思料する。
ありゃま (スコア:1)
しかし、US-ASCIIの上にMIMEが載っていることを無視した規定は救いがたい…。