<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
   <title>電子メール教本</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/" />
   <link rel="self" type="application/atom+xml" href="http://blogs.manapo.com/email/atom.xml" />
   <id>tag:blogs.manapo.com,2007:/email//2</id>
   <updated>2007-11-15T03:03:25Z</updated>
   <subtitle>電子メールの利用マナーを正しく知るために</subtitle>
   <generator uri="http://www.sixapart.com/movabletype/">Movable Type 3.34</generator>

<entry>
   <title>電子メールの掟（資料編）-7</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000165.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.165</id>
   
   <published>2007-11-15T03:01:25Z</published>
   <updated>2007-11-15T03:03:25Z</updated>
   
   <summary>4.0 情報サービス(gopher、Wais、WWW、ftp、telnet)...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      4.0 情報サービス(gopher、Wais、WWW、ftp、telnet)
      <![CDATA[<br>
最近のインターネット史、'新しくて様々な情報サービスに応じて、ネットは爆発したところ'です。 <br>
gopher、Wais、WWW(WWW)、オブジェクト指向(MOOs)であるマルチユーザディメンジョン(MUDs) マルチユーザディメンジョンはこれらの新しい領域のいくつかです。<br>
情報を見つける能力は爆発していますが、「買主の危険負担」は一定のままで残っています。 <br>
これらのサービスに関する詳しい情報がないかどうか、参考資料14、28をチェックしてください。<br>
（訳注：現在は gopher,Wais は殆ど使われていません）<br>
<br>
4.1 ユーザガイドライン<br>
<br>
4.1.1 一般的なガイドライン<br>
-これらのすべてのサービスが他の誰かに属すのを覚えています。費用負担をする人々は、用法を支配する規則を作り始めます。情報は無料であるかもしれません。またはそれは無料ではありません！<br>
チェックするのを確認してください。<br>
<br>
<br>
-どんな形式の情報サービスでも関する問題がありましたら、局所的でチェックすることによって、問題解決を始めてください: ファイル構成、ソフトウェアセットアップ、ネットワーク接続などをチェックします。<br>
問題を最後に仮定するのがプロバイダーです。そして、プロバイダーへ連絡する前にこれを行いましょう。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 14<br>
-ファイルの種類を区別するために使用された命名規則がありますが、いつでもこれらのファイル命名規則に頼ってはいけません。例えば、".doc"ファイルはいつもWordファイルであるというわけではありません。<br>
<br>
-また、情報サービスはwww.example.comなどの慣用的なものを使用します。これらの慣用を知り、役に立つようになるまでの間、一方ではそれらを常に当てにしないでください。<br>
<br>
-ファイル名がどのようにあなた自身のシステムに働くかを知りましょう。<br>
-セッションの間、情報を提供するのに使用される慣用的なものを意識してください。FTPサイトには通常、トップディレクトリの中にファイルに関する情報を記載し、利用案内をするREADMEというファイルがあります。しかし、これらのファイルが必ず最新である、そして/または、正確であると仮定しないでください。<br>
<br>
-あなたが見つけるどんな情報も最新である、そして/または、正確であると仮定できません。新技術が、殆どの場合、だれでも出版社で紹介されることを許容しますが、すべての人々が出版に伴う責任を発見するというわけではなかったのを覚えていてください。<br>
<br>
-セキュリティと認証技術が使用中であり、あなたがシステムに提出するどんな情報も「クリーン」なインターネットの上で送られているのを確信できない場合、それを覚えていてください。「パケット盗聴プログラム(sniffer)」からの保護も捏造者なしで。<br>
<br>
-インターネットが地球を網羅しているので、情報サービスが文化とあなた自身の共同体と著しく異なったライフスタイルを反映するかもしれないのを覚えています。 あなたが不快であることがわかる材料は地理学で起こるかもしれません(それらが許容できるのがわかります)。 偏見のない心を保ちましょう。<br>
<br>
-ポピュラーなサーバから情報が欲しい時、リストを提供されているなら近くにあるミラーサーバを必ず使用しましょう。<br>
-あなたが、他の人々に拾って欲しい材料を蓄積させるのに、他の誰かのFTPサイトを使用してはいけません。これは、「ダンピング」と呼ばれて、一般に許容できる振舞いではありません。<br>
<br>
-あなたがサイト構築・運用に苦労していて助けを求めるとき、問題をデバッグするのを助けるためにできるだけ多くの情報を必ず提供しましょう。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 15<br>
-ホームページなどのあなた自身の情報サービスを持って来るとき、ローカルのガイドラインと適合するものかどうかを理解し、感情的な問題を予防するために、あなたのローカルシステム管理者に必ず問い合わせましょう。<br>
<br>
-人気サイトに「ラッシュアワー」（混雑時間帯）を避け、オフピークの時間帯にログインすることによってシステム稼働率を広げることを考えましょう。]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-6</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000164.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.164</id>
   
   <published>2007-11-15T02:02:06Z</published>
   <updated>2007-11-15T02:51:55Z</updated>
   
   <summary>3.1.3 ネットニュースガイドライン...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      3.1.3 ネットニュースガイドライン
      <![CDATA[　ネットニュースは、人々が特定に関心の話題について話し合うグローバルな分散システムです。<br>
　それは主要な部門と共に階層構造に分割されます。 <br>
<br>
sci--科学関係の議論; <br>
comp--コンピュータ関係の議論; <br>
news--ネットニュース自体を中心に置く議論; <br>
rec--レクリエーション活動; <br>
soc--社会問題; <br>
talk--くどくて果てしない論議;<br>
biz--ビジネス関係; <br>
そして、alt--交互の階層構造。<br>
<br>
altグループを創設するのが階層構造の他の一部分にグループを創設するのと同じ過程に直面していないので、Altはそのように命名されます。また、地方の階層構造があります、Bionetなどのように広く分配される階層構造、そして、あなたの勤務地には、また、それ自身のグループがあるかもしれません。 <br>
最近、「人文科学」階層構造が加えられました、そして、時のたつにつれてありそうな構造が加えられるでしょう。<br>
Newsについての、より長い議論に関しては、参考資料 2、8、22、23を見てください。<br>
<br>
-	ネットニュース用語で、“Posting”はグループに新しい記事を掲示するか、他の誰かが掲示した記事へ応じることを指します。“Cross-Posting”は、２つ以上のグループに記事を掲示するのを示します。あなたがグループかそれとも「Followup-To:」を指示するかどうかにCross-Postingを紹介するなら、あなたのPostingのヘッダーでは、読者に警告します！ 通常、読者はメッセージが特定のグループに掲示されて、追跡がそのグループに行くと仮定するでしょう。ヘッダーはこの振舞いを変えます。<br>
<br>
-	回答を掲示する前に、進行中の議論(私たちは、これを「スレッド」と呼ぶ)のすべてを読みます。「私も」メッセージを掲示するのを避けます。(そこでは、内容が前の投稿との協定に制限されます)。追跡している投稿内容は引用された内容を超えるべきです。<br>
<br>
-	質問への答が1人の人だけのためのものであるときに、電子メールを送ります。ネットニュースにはグローバルな分配があって、全世界がたぶん個人的な応答に興味を持っていなかったのを覚えていてください。しかしながら、何かがいつニュースグループ関係者への一般的興味のものになるか判らないので、投稿にためらわないでください。<br>
<br>
-	ヘッダーの“Distribution”セクションをチェックしなさい。但し、それを当てにしてはいけません。ネットニュースが届けられる仕組みは複雑なために、Distributionヘッダは頼り無いです。しかし、あなたが限られた数か読者にとっての何か興味深さになるものを掲示しているなら、あなたの記事の分配をそれらの人々に制限するのを試みるために Distribution行を使用します。例えば、あなたがニュージャージーの読者だけに興味深くなる記事を掲示しているなら、Distributionに"nj"であるように設定します。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 11<br>
-	投稿記事自体が1つ以上のニュースグループに興味深くなるのを感じるなら、確実に個別にそれらのグループにそれを掲示するよりむしろCROSSPOSTへの記事になってください。一般に、たぶん唯一の5～6グループには、これを保証する十分同様の関心があるでしょう。<br>
<br>
-	質問を掲示する前に参照ソース(コンピュータマニュアル、新聞記事、ヘルプファイル)を熟読しましょう。ほかの場所で答えがどこで容易に入手できるかをニュースグループに尋ねてしまうという、気むずかしい"RTFM"(「f」で始まる単語の、より平凡な意味は通常含意されますが、すばらしいマニュアルを読む)メッセージを発生させます。<br>
<br>
-	広告を歓迎するニュースグループがありますが、一般に、それはオフ話題製品の広告を出すために、まさに罪であると考えられます。広告をありとあらゆるグループに送ると、あなたの接続性の損失はほとんど保証されるでしょう。<br>
<br>
-	あなたがあなた自身の投稿における誤りを発見したなら、できるだけ早くそれを取り消しましょう。<br>
-	あなた自身のどんな記事をも取り消すのを試みるとは限りません。どのようにあなたの投稿記事を取り消すか、そして、またはチェーンレターなどのある他の投稿記事が、取り消す必要であるかどうかを知らないなら、管理者に連絡してください。<br>
<br>
-	何かを掲示して、すぐにそれを見ないなら、それが失敗したと仮定しないでください。そして、暫く経っても同じなら、それを再び投稿します。<br>
<br>
-	ニュースグループの中には他の事情で疑わしい味にあると考えられる投稿を可能にする(そして、何らかの歓迎)ものもあります。それでも、ニュースグループを読んでいるすべての人々が材料に感謝するという保証が全くあなたがいるくらいにはありません。犯罪を与えるのを避けるのに、Rotateユーティリティ(アルファベット配列を13個移動させて、あなたの投稿ですべてのキャラクタを交替させる)を使用します。Unixの　Rot13ユーティリティはその例です。<br>
<br>
-	映画か本について議論するグループでは、どれが「スポイラー」として重要な内容を明らかにするかは投稿をマークするのに不可欠であると考えられます。あなたのSubject:にこの言葉("Spoilers")を入れます。立ち並んでいます。あなたが見えないところで内容を保つために、あなたのポストの始まりに空白行を加えることができるか、またはあなたがRotateをそれに加えることができます。<br>
<br>
-	一般に、ニュース記事の鍛造物は非難されます。あなたは偽造から操作検出「指紋」(fingerprint)を発生させるソフトウェアを使用することによって、我が身をかばうことができます。PGP(米国)がその例です。<br>
（訳注：PGP は、現在では殆どの国で利用することが出来ます）<br>
<br>
-	匿名のサーバを通る投稿はいくつかのニュースグループで受け入れますが、他では嫌われます。匿名で掲示されると、自分自身の名前の下で掲示される不適当な材料は、まだ不適当です。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 12<br>
<br>
-	加減されたニュースグループに掲示するとき、あなたの投稿を見る際、わずかな遅れが予想されます。モデレータ（議長）は、あなたのポストを特定のスレッドに一致させるようにあなたの件名(Subject)を変えるかもしれません。<br>
<br>
-	応酬に係わらないようにしましょう。 放火の材料に掲示せず、また反応してはいけません。<br>
<br>
3.2 管理者ガイドライン<br>
<br>
3.2.1 一般的なこと<br>
-	あなたのサイトがネットニュースグループの購読とメーリングリストに加入するにあたり、関連することに関して持っているどんな方針もはっきりさせます。<br>
<br>
-	あなたのサイトがネットニュースにグループを掲示するに関連して、または、メーリングリストに持っているあらゆる方針をはっきりさせてください、.sigsでの注意書きの使用を含みます。<br>
<br>
-	アーカイブ方針をはっきりさせて、宣伝します。 (どれくらい長い間、記事は保管されますか?)<br>
-	即座に、偏見なしにあなたのユーザに関する罪名を調査します。<br>
-	あなたのシステムの健康状態を必ずモニターします。<br>
-	長くシステムログを格納する方法を考えてください。そして、ログ収集に関するあなたの方針を宣伝します。<br>
<br>
3.2.2 メーリングリスト<br>
-	「バウンスメール」問題を避けるためのメーリングリスト維持を考えます。<br>
-	問題が起きたら、メーリングリスト所有者を助けましょう。<br>
-	計画された休止時間は、どんな内容であっても、メンテナンス掲示板などでメーリングリスト所有者に知らせます。<br>
-	”-request”別名要素で、購読申し込みアドレスと管理アドレスを必ず持っています。<br>
-	すべてのメールゲートウェイがスムーズに作動するのを確実にします。<br>
<br>
3.2.3 ネットニュース<br>
-	あなたが受けるフィードの本質について宣伝します。 あなたが完全なフィードを得ないなら、人々は、「それはなぜ？」を知りたがっているかもしれません。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 13<br>
-	ネットニュース読者クライアントの多様性がクライアントで問題について非難されるニュースサーバを引き起こすかもしれないのを意識してください。<br>
<br>
-	彼らがそれら自身の投稿キャンセルかチェーンレターなどの無効投稿を要求するなら、至急、ユーザからの要求を光栄に思いましょう。<br>
<br>
-	"Usenet"、「ネットニュース」、および「ニュース」を別名でもアクセスさせてください。そして、誰かが電子メールを読むのを確実にします。<br>
<br>
3.3 モデレータ（議長）ガイドライン<br>
3.3.1 一般的なガイドライン<br>
-	あなたのFrequestly Asked Questions(FAQ)が一定の間隔を置いて掲示されるのを確実にします。 記事/メッセージのためのあなたのガイドラインを含めます。あなたがFAQ維持装置でないなら、彼らがそうするのを確実にします。<br>
<br>
-	良い歓迎メッセージを必ず維持してください。参加、脱退案内も同様に。<br>
-	ニュースグループはそれらの特許/ガイドラインを定期的に掲示させるべきです。<br>
-	メーリングリストとニュースグループは、更新されます。直ちにメッセージを投稿してください。休暇か街を出たら、代用品を指定してください。<br>
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-5</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000163.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.163</id>
   
   <published>2007-11-15T01:56:43Z</published>
   <updated>2007-11-15T02:47:12Z</updated>
   
   <summary>3.0 １対多のコミュニケーション(メーリングリスト、ネットニュース)...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      3.0 １対多のコミュニケーション(メーリングリスト、ネットニュース)
      <![CDATA[いつでも、あなたは１対多のコミュニケーションに従事しています。また、電子メールのためのすべての規則が適用されるべきです。 結局、1つの電子メール送信で多くの人々とコミュニケートするのは、怒っている人々を除いて、１対１のコミュニケーションより、さらに多くの1人の人とコミュニケートするのに類似しています。 <br>
したがって、あなたがあなたのメッセージの聴衆に関してどういう重要な影響を与え得るのかを知るのはかなり重要です。<br>
<br>
<br>
3.1 ユーザガイドライン<br>
3.1.1 一般的なメーリングリストとネットニュースのためのガイドライン<br>
<br>
-どんなにコミュニティに積極的に参加したくても、1～2カ月はメーリングリストとニュースグループの両方を読みましょう。これは、あなたがグループの文化の理解を得るのを助けます。<br>
<br>
-ユーザの振舞いをシステム管理者のせいにしてはいけません。<br>
<br>
-多数の聴衆があなたの投稿を見ると考えます。それはあなたの上司かあなたの次の上司を含むかもしれません。あなたが書くものでは、この点も注意してください。また、投稿は格納されて、頻繁にメーリングリストとニュースグループがそうであるように、それがあなたの言葉であることが非常に長い期間多くの人々がアクセスを持っている場所に格納されるかもしれないことを覚えていてください。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page  7<br>
-個人が自分の思うことを言うと仮定してください。そうすれば、彼らが言うことは彼らの組織を代表することにならないでしょう(明らかに述べられない場合)。<br>
<br>
-電子メールとニュースの両方がシステム資源を取ることがよく知られています。 あなたの組織が持っているかもしれない彼らの用途をカバーするあらゆる特定の規則に注意を向けてください。<br>
<br>
-メッセージと記事は、簡潔であって、肝心であるべきです。関係ない話題を歩き回らせないでください、そして、漫歩しないでください。そして、電子メールをタイプする際に唯一他の人々の誤りを指摘するメッセージまたはスペルを送らないでください。これらはいかなる他の振舞いよりも未熟な初心者としてあなたをマークします。<br>
<br>
-件名(Subject)はグループの慣例に従うべきです。<br>
-偽造とパロディーは承認された振舞いではありません。<br>
<br>
-広告は、いくつかのメーリングリストとニュースグループで歓迎されて、他のものの上で憎悪されます！これはあなたが参加する前に、あなたの聴衆が掲示する内容を知る必要がある別の例です。最も確かに、完全に話題である求められていない広告は、あなたが多くの嫌がらせの手紙を得るのを保証するでしょう。<br>
<br>
-投稿かリプライを送るなら、メッセージの先端にオリジナルをまとめるようにしてください。またはオリジナルの文脈をちょうど与えることができるくらいの原本を含めます。これは、読者が、彼らが、いつあなたの応答を読むのを出発するかを理解しているのを確実にするでしょう。ネットニュースが1人のホストから別のホストまでの投稿を広げることによって特に増殖するので、オリジナルを見る前にメッセージへの応答を見るのは可能です。文脈を与えると、皆は助けます。しかし、全体のオリジナルを含めないでください！<br>
<br>
-もう一度、あなたがメッセージに付ける署名を必ず持っているはずです。これは、ヘッダー情報を剥取る送信者かニュースキャスターのどんなユニークさも、人々がどうあなたに連絡するかに関するメッセージにおける唯一の参照を削除しないことを保証するでしょう。<br>
<br>
-投稿かリプライするとき、注意してください。頻繁に、多くの投稿をする場合、(リストかグループのアドレスである)を溯源したアドレスは回答に送り返されます！<br>
かかわるすべてを当惑させて、あなたは偶然個人的な応答を多くの人々に送ることができます。<br>
「回答」を当てにすることの代わりにアドレスをタイプするのは最も良いです。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page  8<br>
-配送通知、配送エラー通告、およびVacationプログラムは、完全に標準化されているというわけではなくてインターネット・メールに接続されたシステムの範囲の向こう側に完全に高信頼であるというわけではありません。メーリングリストに送ると、それらは侵略的です。そして、何人かの人々が配送自体がプライバシー侵害を受けると考えます。<br>
要するに、それらを使用してはいけません。<br>
<br>
-あなたが送信した個人メールがメーリングリストかニュースグループに行ってしまったのがわかったなら、謝罪を当事者、グループに送りましょう。<br>
<br>
-気付くと、あなたが1人の人との意見の不一致（対立）が起きているなら、メッセージをメーリングリストかニュースグループに送り続けるより、むしろ電子メールで互いに個別に対応しましょう。あなたが何らかの関心を持ち、グループが持っているかもしれないものに関してまとめることができるかをポイント討論することが後で役立ちます。<br>
<br>
-応酬に係わらないようにしましょう。 放火の材料に掲示せず、また反応してはいけません。<br>
-メッセージを送るか、またはそうであるだけである記事を掲示するのを避けましょう。回答に関する無料の回答。<br>
<br>
-等幅フォントとダイヤグラムを区切るのに注意してください。これらは異なったシステム、および同じシステムの上の異なった送信者とでは、異なって表示するでしょう。<br>
<br>
<br>
<br>
-広範なバラエティーに富むあらゆる分野に議論の場となるニュースグループとメーリングリストがあります。これらはライフスタイル、宗教、および文化の多様性を表します。単に彼らが不快であると彼らに言うために記事を掲示するか、またはメッセージをあなたにとって、観点が不快であるグループに送ることが許容できません。また、性的に人種的にメッセージを悩ませるのにおいて、法的な意味があるかもしれません。あなたが好ましくないのがわかるかもしれない項目をフィルターにかけるために利用可能なソフトウェアがあります。<br>
<br>
3.1.2 メーリングリストガイドライン<br>
どんなメーリングリストがインターネットに存在するか、そして、どのようにそれらを接合するかに関する情報を見つけるいくつかの方法があります。 これらのリストを接合することに関するあなたの組織の方針と任命をそれらに必ず理解してください。<br> 
一般に、インターネットを通して情報を見つけようとする前に、いつもローカル資源をチェックしているほうがよいです。 <br>
それにもかかわらず、定期的にニュースに掲示された1セットのファイルがあります。<br>
インターネットメーリングリストをリストアップする答えとどうそれらに加入するか。 <br>
これは、どんな話題のリストも見つけるための計り知れない資源です。また、参考資料　9、13、15を見てください。<br>
<br>
-適切な電子メールアドレスに送信して、参加・脱退します。何らかのメーリングリストソフトウェアがこれらを捕らえることができるくらい賢いのですが、すべてがこれらを調べ出すことができるというわけではありません。メーリングリストがどう働いているかを学んで、正しいメールを正しい場所に送るのは、あなたの責任です。<br>
多くのメーリングリストが参加申し込み送付のために「要求」別名を持つ慣習を固く守りますが、申し込んでください。<br>
その際は、メッセージを一切記述しないでください。 <br>
あなたがメーリングリストに参加を申し込むことによって、そのメーリングリストでの慣習を確認してください。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page  9<br>
-あなたが加わるどんなメーリングリストへの購読メッセージも保存します。 通常、これらはまた、脱退する方法をあなたに教えます<br>
<br>
-一般に、あなたが一旦メッセージを送ると、メッセージを検索するのは可能ではありません。 あなたが一旦それを送ると、あなたのシステム管理者さえメッセージを取り戻すことができないでしょう。これは、あなたが、本当にそれを書いたときに行くメッセージが後日必要なときに取得する環境を確実に整えなければならないことを意味します。<br>
<br>
-多くの送信者の自動返答機能は、社内のコミュニケーションの役に立ちますが、それを全体のメーリングリストに送るとイライラの元になります。投稿時の審査、メーリングリストからのメッセージに答えるとき、そのメーリングアドレスに返答してしまいます。ほとんどの自動リプライがメーリングリストのメンバー全てのものになるでしょう。<br>
<br>
-ftp可能なUniform Resource Locator(URL) ポインタが一般開放できる場合、大きいファイルをメーリングリストに送らないで、そちらを活用しましょう。あなたが複数の添付ファイルとしてそれを送りたいなら、グループの慣習に必ず従います。あなたが、それが何であるかを知らないなら、尋ねましょう。<br>
<br>
-あなたが長期間、電子メールをチェックすることができないとき、"nomail"オプション(それが利用可能である場合に)を外すか、または設定することを検討しましょう。<br>
<br>
-特にメーリングリストで密接に話されるなら、メッセージを１つ以上のメーリングリストに送るとき、クロスポストしたのを謝罪しましょう。<br>
<br>
-あなたが質問するなら、概要を必ず掲示します。そうするときは、質問を送る以上に、むしろあなたが受け取るメッセージの蓄積をまとめてください。<br>
<br>
-メーリングリストの中には、個人的なものも幾つかあります。電子メールをこれらのメーリングリストに押しかけて送らないでください。 電子メールをこれらのメーリングリストから、より広い聴衆に転送したり紹介したりしないでください。<br>
<br>
-あなたが議論で捕らえられるなら、かかわった個性よりむしろ問題に議論の焦点を合わせ続けるようにしましょう。<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page 10<br>

]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-4</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000162.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.162</id>
   
   <published>2007-11-15T01:51:26Z</published>
   <updated>2007-11-15T02:30:10Z</updated>
   
   <summary>2.1.2  Talk  （訳注：いわゆる、チャットのようなもので、ここ内容はチ...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      <![CDATA[2.1.2  Talk  （訳注：いわゆる、チャットのようなもので、ここ内容はチャットにも適用できます）<br>
Talkは２人の人がコンピュータを通して双方向の対話を持つ、ワンセットのプロトコルです。<br>]]>
      <![CDATA[-大文字と小文字を混在させるときは、あなたが手紙をタイプライターで書くか、または電子メールを送るつもりで正しく使いましょう。<br>
<br>
-行端を端末の右端へ追い出さないでください;<br>
行の終わりでCarriage Return(CR)を使用してください。<br>
また、あなたの画面サイズが他の人皆のものと同じであると仮定しないでください。<br>
良い経験則は横70文字未満、および12未満の単語で済ませる(あなたが分割スクリーンを使用しているので)ことです。<br>
<br>
-何らかの余白を残してください; スクリーンの縁に書かないこと。<br>
-あなたが完了して、もう片方の人が、タイプし始めるかもしれないのを示すのに２回CRを入力します。 (空白行).<br>
<br>
-いつも「さようなら」、または同様な他の送別の言葉を使ってください。そして、セッションを殺す前にもう片方の人から送別の言葉を見るのを待ちます。あなたがはるかに遠くで誰かとコミュニケートしているとき、これは特に重要です。 あなたのコミュニケーションがネットワーク帯域幅(パイプのサイズ)と潜在(光速)の両方を当てにするのを覚えていてください。<br>
<br>
-Talk にて、割り込みは、もう片方の人に対する中断であることを知らせます。適宜使用するだけです。<br>
そして、見知らぬ人と決して話さないでください。<br>
<br>
-リプライを得られない理由は多いです。 すべてが正しく働いていると仮定できません。 Talk のすべてのバージョンがどんな互換性があるというわけではありません。<br>
<br>
-通信中断後、可能であれば、Talk は相手へ再呼び出しをします。それを1回か2回やらせてください。<br>
そして、反応が無い場合に、それを強制終了します。<br>
<br>
-相手が応答しないなら、あなたは別のttyを試みるかもしれません。 どれが開いているかを決定するのに指を使用します。 相手がまだ応じていないなら、発信し続けません。<br>
<br>
-Talk には、あなたがタイプした内容を表示する能力があります。あなたがゆっくりタイプして、タイプミスした場合、もう片方の人が、通常あなたが意図したことを理解することができるため、修正を試みる価値があるというわけではありません。<br>
<br>
-Talk は、1セッションだけにするように注意してください！<br>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Page  6<br>
2.2 管理者問題<br>
<br>
-特に不法で、不適当な状況の取扱いのための書かれたガイドラインを確立するか、または不正通信があるのを確認してください。<br>
<br>
-要求は翌営業日には直ちに扱いましょう。<br>
-至急、不適当であるか不法なメッセージを受け取ることに関する心配を持っている人々に応じましょう。<br>
チェーンレターに関する要求は、すぐに扱うべきです。<br>
<br>
-あなたのユーザへ、ハードディスク割当てなどのどんなシステム規則についても説明しましょう。彼らが、要求の含意が以下の方法などで理解しているのを確認してください。 <br>
ディスクへの充填; 電子メール配送などを遅らせて、電話代請求書を上げます。<br>
　（訳注：これは極端な例だが、「何でもあり」ではないことを知らしめる必要性が出てくる場合はありますね）<br>
<br>
-「Postmaster」を必ず別名登録させます。「root」を必ず別名登録させます。誰かがその電子メールを読むのを確実にするためです。<br>
<br>
-偏見なしにあなたのユーザに関する苦情を調査します。アドレスが偽造されて、だまされたかもしれないのを覚えていてください。<br>
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-3</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000161.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.161</id>
   
   <published>2007-11-15T01:41:29Z</published>
   <updated>2007-11-15T02:25:27Z</updated>
   
   <summary>Page  2...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      Page  2
      -良い経験則：あなたが送信するとき、保守的な人になってください。逆に、あなたが受信するときは寛容になるのです。 怒らせられても、あなたは加熱されたメッセージ(私たちはこれらを「炎」と呼ぶ)を送るべきではありません。他方では、あなたを燃やそうと画策し、驚かせるべきではありません。そして、「炎」に応じない慎重さが有効です。

-一般に、返信する前にあなた宛ての全ての電子メールをチェックするのは、良い考えです。時々、あなたに助け(または、明確化)を求める人は「良くない(悪い知らせの)」メッセージを送るでしょう。 また、どんなメッセージもあなたに向けられたのを確実に確認してください。 あなたは第一の受取人ではなく、むしろCc: であるかもしれません。

-受取人にとって簡単に判る連絡先を入れます。 多くの送信者がヘッダーを裸にします。あなたの返送先を含んでいる情報です。 ですが、あなたが誰であるかを知るのを確実にするには、あなたのメッセージの終わりに１行か２行の問い合わせ先を必ず含んでください。 あなたは、早めにこのファイルを作成して、あなたのメッセージの終わりに加えることができます。 (何人かの送信者が自動的にこれをします。) インターネットでは、これは　&quot;.sig&quot;　か「署名」ファイルとして知られています。 あなたの .sigファイルはあなたの名刺の代理をします。 (そして、あなたは異なった事情でそれを1つ以上持つことができます。)
（訳注：最近の殆どのＭＵＡは、署名を自動挿入するので、あまり気にする必要はないでしょう）

-メールを送信するときは、注意してください。電子メールアドレス自体は、それがちょうど１人の人であるように見えますが、それとは裏腹にグループに行くかもしれません。だれを送るかを認識してください。

-返答するとき、Cc: を見ます。メッセージが双方向の会話になったなら、Cc: を含み続けません。

-一般に、インターネットを使用するほとんどの人々がインターネットとその作業に関する一般疑問に答える時間を持っていません。あなたはRFCかメーリングリスト上で名前を見たかもしれませんが、迷惑メールを人々に照会させないでください。

-あなたが交信する人々が地球の向こう側に位置しているかもしれません。 あなたが即座の応答が欲しいメッセージを送っても、それを受ける人は到着すると家で眠っているかもしれません。相手が目覚めるまで待ちましょう。そして、出勤してください。そして、電子メールが到着しなかったか、または彼らが気にかけないと仮定する前に、ログインしましょう。

-長いか個人的な会話を開始する前に、すべての電子メールアドレスについて確かめます。また、対象の題名に「長い」という言葉を含むのが、良い習慣であるので、受取人は、それを見てメッセージを読んで応じるには時間がかかるのを理解します。100行以上が、「長い」と考えられます。
Page 3
-電子メールの送受信問題で助けを求めるために誰か連絡する場合、通常、あなたは手元のリソースを利用するでしょう。人々は、手元のソフトウェアとシステムであなたの問題を助けることができるかをチェックします。また、あなたが疑わしいか、または不法なものを受けるなら、それらの行き先は決まっています。また、ほとんどのサイトで博識なユーザに「Postmaster」を別名で保有するので、あなたは電子メールに関する助けを得るために電子メールをこのアドレスに送ることができます。

-受取人が文化・言語・およびユーモアにはあなた自身と異なった視点の人間であることを理解しましょう。日付の形式、測定値（訳注：長さや重さなどの単位）、および熟語がどこでも通用するわけではありません。皮肉に特に注意してください。

-大文字と小文字を併用しましょう。 大文字はまるであなたが叫んでいるかのように見えます。
（訳注：アルファベット文字圏での話しです。それ以外の文字圏では無意味な内容です）

-強調のシンボルを使用しましょう。それは私が*意図した*ことです。強調は、アンダーラインを使用します。
_戦争と平和_ は私の愛読書です。（訳注：アンダーラインによる強調は日本語には不向きです）

-顔文字を使用して、声の調子を示してください。控えめにそれらを使用します。:-) の例はにこやかですか？(横目で見てください) にこやかな意志の包含が、受取人があなたの言うことに満足にする、そうでない場合に侮辱的なコメントを破壊する、と仮定しないようにしてください。

-夜通し、感情的な反応メッセージが来るのを待ちます。対象に関する本当に強い意見がありましたら、FLAME ON/OFF包囲を通ってそれを示します。 

例えば:
FLAME ON:
このタイプの議論はそれを送るのに要する帯域幅の価値がありません。
それは、不合理で不十分に推論されています。 他の国々は私に同意します。
FLAME OFF:
（訳注：現在では -------------------- のような行で囲むスタイルが多い）

-送信者が メッセージのMIME コード化をしない場合、制御文字と非ASCII文字を含めてはいけません。 
あなたが MIMEコード化されたメッセージを送るなら、受取人がそれらを解読することができるのを確実にします。

-返信の際は、簡潔になりすぎないように注意して、出来るだけ簡潔にしてください。メッセージに理解することができるくらいの元の材料を含めてください。前のすべてのメッセージを含んでいることによって単にメッセージに答えるのは、非常に悪い作法です: 無関係な内容は全て削除します。
（訳注：全文引用は非常に悪い作法だと、ここで示しています）

-行長を65文字未満に制限してください、そして、復帰(改行)で行を終わらせます。
（訳注：日本語だと32文字に相当しますが、35文字程度が最大です）

-電子メールには、メッセージの内容を反映する件名標目があるべきです。
Page 4
-あなたが署名を入れるなら、それを短く保ちます。 経験則は４行以下。接続時間に応じて多くの人々が接続性の代価を払うのを覚えていてください。そうすれば、あなたのメッセージが長ければ長いほど、彼らはさらに代価を支払います。

-その電子メールは個人的ではないかもしれません。電子メール(そして、ニュース)では、様々な偽造メッセージを使って、だまそうとしている人がいます。 メッセージを信じる前に常識の「現実チェック」を適用します。

-メッセージの重要性に正当化を見出せると思うなら、至急簡潔に送付者にあなたがそれを得たのを知らせる電子メールを返信してください、あなたが後でより長い回答を送るつもりであってもです。

-電子メールを通る行為への「妥当な」期待は人とのあなたの関係とコミュニケーションに関する文脈によります。
一般に、特定の電子メール環境で学ばれた標準はインターネット中の人々とのあなたのメールコミュニケーションに適用されないかもしれません。スラングやローカル地域の頭文字語に注意してください。

-電子メールを送る費用は、平均して送付者と受取人(または、彼らの組織)によっておよそ等しく支払われます。 これは物理的なメール、電話、テレビ、またはラジオなどの他のメディアと異なっています。 また、電子メールを誰かに送るのはネットワーク回線容量、ハードディスク容量、またはCPU利用率のような他の特定の方法でかかるかもしれません。これらが迷惑メール広告が歓迎されない(そして、多くは禁じられます)基本的な経済的理由です。

-あなたがどれくらいの大きさの電子メールを送るかを仮定しています。 Postscriptファイルかプログラムなどの大きいファイルを含んでいると、あなたが提供することができないか、または過度のリソースを消費するほど大きいメッセージは幅を利かせるかもしれません。 良い経験則は50kByteより大きいファイルを送らないだろうことです。ファイル転送が代替手段でしょう。または、より小さい塊にファイルを切り、または別々のメッセージとしてそれぞれ発信することを期待しています。
（訳注：これは添付ファイルの事も含めている。現在の経験則は、概ね 2Mbyte が目安）

-多量の求められていない情報を人々に送らないようにしましょう。
-あなたがメールシステムで電子メールを転送するなら、恐れられた転送ループに注意します。あなたに送られたメッセージが次への1台のコンピュータから次までの永久ループに入るように、数人のホストの上で、転送設定していないのを確認してください。

Page 5



   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-2</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000160.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.160</id>
   
   <published>2007-11-15T01:28:49Z</published>
   <updated>2007-11-15T02:11:02Z</updated>
   
   <summary>2.0 １対１のコミュニケーション(電子メール、Talk)...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      2.0 １対１のコミュニケーション(電子メール、Talk)
      <![CDATA[私たちは、１対１のコミュニケーションを人がまるで面と向かうかのように別人とコミュニケートしている状況に準えて定義します: <br>
対話(face to face)。 一般に、どんな状況にも、人々との相互作用のための礼儀規則は有効であるべきです。<br>
そして、インターネットでは、それは例えば、ボディー・ランゲージと声の調子を推論しなければならないところで二倍重要です。 電子メールと話で交信するためのネチケットに関する詳しい情報がないかどうか、参照資料 1、23、25、27をチェックしてみてください。<br>
<br>
2.1 ユーザガイドライン<br>
<br>
2.1.1 電子メール<br>
-	あなたがインターネットを通して、自分自身のインターネット・アクセスを持っている場合、プロバイダと電子メールの所有権に関して雇い主に必ず問い合わせてください。電子メールの所有権に関する決まりは場所によって異なります。<br>
<br>
-	あなたが暗号化装置(ハードウェアかソフトウェア)を使用していない場合、あなたはインターネットに関する電子メールが安全でないと仮定するべきです。 電子メールでは、あなたがはがきに書かないことは、同様に決して何も書かないでください。<br>
<br>
-	あなたが受け取った内容は、著作権を重要視しましょう。 ほとんどの国には、著作権法があります。<br>
<br>
-	あなたが受け取ったメッセージを転送・返信するなら、言葉遣いを変えてください。 メッセージがあなたへの個人メールであり、それをグループに返信するなら、あなたは最初に差し出し人へ許可を求めるべきです。メッセージを短くして、関連部分だけを引用することができますが、適切な権限を与えられるのを確認してください。<br>
<br>
-	電子メールを通してチェーンレター（訳注：不幸の手紙の類を「チェーンレター」といいます。）を決して送ってはいけません。 チェーンレターは、インターネットでは禁じられます。 あなたのインターネット利用権は取り消されるかもしれません。ローカルシステム管理者に通知してください、あなた１人が受け取って後は無視してください。]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（資料編）-1</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071115000159.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.159</id>
   
   <published>2007-11-15T01:24:08Z</published>
   <updated>2007-11-15T02:05:05Z</updated>
   
   <summary>○ RFC1855 ― ネチケットガイドライン...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（資料編）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ○ RFC1855 ― ネチケットガイドライン
      <![CDATA[実は、インターネットでのマナーは、RFC1855 という資料にガイドラインが示されている。<br>
　インターネット上のエチケットということで、「ネチケット」とも言われる。<br>
　RFC は Reqest For Comment の略で、直訳すれば、「要件のメモ書き」だが、そのメモ書き集が今日では、インターネットのあらゆる提案資料や技術資料として主要なものになっている。<br>
　1855 は1 から付けられている連番で、さしずめ、1855番目の資料というところである。<br>
RFC1855 は 1995年10月に公開されたものである。<br>
　ここに掲載する RFC1855 は、筆者が、機械翻訳のあと、日本語表記に合う様に適切に表現を変更したものである。<br>
　〔原文：http://tools.ietf.org/html/rfc1855 〕<br>
<br>
ネチケットガイドライン<br>
<br>
このメモの状態<br>
<br>
このメモはインターネットコミュニティのための情報を提供します。 <br>
このメモはどんな種類のインターネット規格も指定しません。 このメモの分配は無制限です。<br>
<br>
要約<br>
<br>
このドキュメントは、組織自身が使用のために、適合するにふさわしい ’Network Etiquette(ネチケット)’のための最小限のガイドラインを提供します。<br>
それは、適合をより簡単に、どんな特定の項目も見つけるのが簡単にできるように故意に箇条書き形式で書かれています。<br>
また、それは個人のための最小限のガイドライン、ユーザ・管理者の両方に適用できます。 <br>
このメモはIETFの Network(RUN)作業部会のResponsible Useの制作です。<br>
<br>
目次<br>
<br>
1.0 序論　　　　　　　　　　　　      Page. 1<br>
2.0 一対一コミュニケーション          Page. 2<br>
3.0 多くへの1つのコミュニケーション  Page. 7<br>
4.0 情報サービス                      Page.14<br>
5.0 選択された図書目録                Page.18<br>
6.0 セキュリティ問題                  Page.21<br>
7.0 作者のアドレス                    Page.21<br>
<br>
ここから本文<br>
1.0 序論<br>
<br>
以前、インターネットを使用している人々の多くは、インターネットで「成長」して、技術的内容にも気を配り、通信とプロトコルの本質を理解していました。 <br>
今日、インターネットユーザの共同体は新しい人々を含めます。 これらの「新入り」は、インターネット独特の文化になじみがなく、通信とプロトコルに関して知る必要に迫られません。 急速にこれらの新しいユーザをインターネット文化に運び込むように、このガイドは組織と個人が自らの使用のために取って、適合するにふさわしい最小限の振舞い方を提供します。<br>
 Page  1<br>
個人が意識しているべきであるか、それらの組織に掲示するか、または送信する際の、電子メールとファイルの適切な所有権と、どう処理するかの規則などは、個人的なアカウントを通るインターネットサービスプロバイダ、Ａ大学の学生アカウント、または会社でのアカウントであることにかかわらずそれを彼らのインターネット・アクセスに供給する問題ではありません。必要に応じ、特別な基準や決まりごとがあるかどうかも、各自で必ず確認してください。<br>
<br>
私たちは3つのセクションにこの材料を文書化しました:<br>
１対１のコミュニケーション(電子メールと会話を含んでいます);<br>
１対多のコミュニケーション(メーリングリスト、ネットニュース、そして、情報サービス群。);<br>
そのServicesはftp、WWW、Wais、gopher、MUDs、およびMOOsを含んでいます。<br>
最後に、私たちは選りすぐりの参考資料を持っています。選りすぐりの参考資料は参照に使用できるかもしれません。
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-10</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071026000126.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.126</id>
   
   <published>2007-10-26T05:44:26Z</published>
   <updated>2007-11-15T01:59:08Z</updated>
   
   <summary>○コンピュータウィルス対策...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ○コンピュータウィルス対策
      <![CDATA[　昨今では、spam 対策に埋没しがちで、且つ混同されがちなのだが、今となってはセキュリティ対策の基本とも言える。<br>
　コンピュータウィルス対策を行うソフトウェアで、よく知られているのは概ね下記だろう：<br>
<br>
<table  border="0" cellpadding="0" cellspacing="8">
<tr><td>・ウィルスバスター</td><td>（トレンドマイクロ社</td><td><a href="http://jp.trendmicro.com/jp/home/" target="_blank">http://jp.trendmicro.com/jp/home/</a>　）</td></tr>
<tr><td>・Norton AntiVirus</td><td>（シマンテック社</td><td><a href="http://www.symantec.com/ja/jp/" target="_blank">http://www.symantec.com/ja/jp/</a> ）</td>
<tr><td>・マカフィー</td><td>（マカフィー社</td><td><a href="http://www.mcafee.com/japan/" target="_blank">http://www.mcafee.com/japan/</a>　）</td></tr>
<tr><td>・ウィルスセキュリティー</td><td>（ソースネクスト社</td><td><a href="http://www.sourcenext.com/" target="_blank">http://www.sourcenext.com/</a>　）</td></tr>
<tr><td>・avast ! antivirus</td><td>（ALWIL Software a.s. </td><td><a href="http://www.avast.com/index_jpn.html " target="_blank">http://www.avast.com/index_jpn.html</a>　）</td>
<tr><td>・Clam AntiVirus</td><td>(ClamAV</td><td><a href="http://www.clamav.net/" target="_blank">http://www.clamav.net/</a>　）</td>
</table> <br>
　このうち、 avast ! antivirus と Clam AntiVirus は無償(avast! antivirus は個人利用のみ無償) である。<br>
さらに Clam AntiVirus はオープンソースで、メールサーバに組み込んで使用する。他の５つは、普段使うコンピュータに常駐プログラムの形で使用する。<br>
　この手のソフトウェアは、spam 対策と同様、コンピュータウィルスに感染している電子メールを抽出し、隔離する。<br>
　ただ、コンピュータウィルスの場合は、隔離して保存しても、保存した電子メールは読まないにこしたことは無いので、隔離後に削除することが多い。実際、上記で挙げたコンピュータウィルス抽出を行うソフトウェアは、コンピュータウィルスを検出すると、電子メール丸ごと削除が基本となっている。<br>
<br>
　さて、コンピュータウィルスはどのように検出・抽出するのだろうか。<br>
　現状では、検出方法に大きく「シグネチャ手法(パターンマッチング手法とも言う)」と「ヒューリスティック手法」があり、現在流通しているほぼ全てのコンピュータウィルス検出を行うソフトウェアは、両者の検出方法を併用している。<br>
<br>
　シグネチャ手法：　遺伝子ＤＮＡのように、特定のコンピュータウィルスにもそれ自身を示す固有部分をチェックする方法。初期のコンピュータウィルスは殆どこのやり方で検出できる。<br>
　ヒューリスティック手法：　コンピュータウィルス自身がシグネチャ型の検出逃れをするため、自身をアメーバのように変化させるもの(ステルス型とも言う)も増えてきているので、コンピュータ全体の挙動チェックをして、コンピュータウィルスと疑われる動作をしたプログラムをコンピュータウィルスとするもの。<br>
<br>
　また、上記のシグネチャ手法に類似した手法として、「チェックサム手法」、<br>
上記のヒューリスティック手法に類似した手法として、「ジェネリック手法」「ルールベース手法」がある。<br>
<img src="http://blogs.manapo.com/email/images/img3_73.gif" align="left" border="0">
どの手法を採用するにしろ、コンピュータウィルスを見極める手がかりとするため、パターン定義ファイルが必須である。<br>
　このパターン定義ファイルは、Clam AntiVirus・avast! antivirus は毎日、他のソフトウェアも２～３日に１回、ほぼ毎日現れる新種のコンピュータウィルスに対応するために更新される。<br>
　現在では、このパターン定義ファイルは、インターネット経由で入手・更新するのが普通になっている。<br>
　多くの場合、コンピュータウィルス抽出を行うソフトウェアが自動的にこの処理を行う。<br>
<br>
左記は、筆者が管理するメールサーバの１つを統計したものである。<br>
このメールサーバは、組織内部での電子メールが多いため、spam メールは平均で全体流量の５～７％程度で、極めて少ない部類になる。<br>
<br>
最近は、コンピュータウィルスは減少傾向である。<br>
しかしながら、２～３年前に大発生したコンピュータウィルスが未だにほぼ毎日検出される。<br>
「自分のところは大丈夫」とタカをくくっていないだろうか？<br>
　是非、セキュリティ対策の基本であるコンピュータウィルス抽出を行うソフトウェアを導入して頂きたいものである。<br clear="all">
<br>
○今どきのメールサーバは、こんなに複雑<br>
<img src="http://blogs.manapo.com/email/images/img3_74.gif" align="left" border="0">最後に、メールサーバの構成を簡単に示そう。<br>
<br>
左の図は、筆者が運用しているメールサーバの構成概要を示したものである。赤文字は現在採用しているもので、将来は変わる可能性もある。<br>
<br>
このほかに port 587(submittion) を送信のメールサーバで受け付けている。<br>
また、受信のメールサーバには、電子メールアドレス単位でメールボックス（メールスプール）を設けている。<br>
図中には無いが、spam フィルタにも、電子メールアドレス単位で、ベイジアンフィルタの為のデータファイルがある。<br>
<br>
一口に「メールサーバ」といっても複数のソフトウェアモジュールが組み合わさって初めて実現していることが何となく理解できれば幸いである。<br>
<br>
図中、アカウントＤＢとあるが、筆者はこの部分に OpenLDAP を使用している。現在では、電子メールのユーザ管理は、このようにある種のデータベースを用いるのが主流になっている。<br clear="all">
<br>
<br>
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-9</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071026000125.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.125</id>
   
   <published>2007-10-26T03:19:12Z</published>
   <updated>2007-11-15T01:43:29Z</updated>
   
   <summary>○spam対策...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ○spam対策
      <![CDATA[　spam はしばしば「迷惑メール」とも呼ばれる。今やインターネットを流れる電子メールの９割は spam メールだとも言われているくらいで、2005年頃までのコンピュータウィルス対策にとって替わる重点対策事項になっている。<br>
　この spam 対策であるが、通常は以下の組み合わせで、受信する電子メールを選別するのが基本である：<br>
<center><img src="http://blogs.manapo.com/email/images/img3_70.gif" border="0"></center>
　隔離メールボックスは、spam 判定された電子メールを通常のメールボックスから排除するためのものである。<br>
　削除しないで、なぜ「隔離」という形をとるのかというと、受信者に最終判断する素地を与えるためである。<br>
　以前は、電子メールアドレスのチェックや電子メールの体裁など、見た目にはっきり判るパターンで spam 対策は一定の成果を上げていたが、昨今では巧妙にそういったチェックをすり抜けることを意図した spam メールが半分以上であり、そのような spam メールに対応すべく、最近では、数学的な確率理論（＝ベイズの定理）に基づくベイジアンフィルタ方式によるものが普及してきている。<br>
　ベイジアンフィルタ方式を実現しているソフトウェアで、よく知られているものは下記の３つである：<br>
<br>
<table  border="0" cellpadding="0" cellspacing="8">
<tr><td>・SpamAssassin</td><td>（ <a href="http://spamassassin.apache.org/ " target="_blank">http://spamassassin.apache.org/</a><br>日本語サイト＝http://www.spamassassin.jp/)</td></tr>
<tr><td>・bsfilter </td><td>（<a href="http://bsfilter.org/" target="_blank">http://bsfilter.org/</a> ）</td>
<tr><td>・Thunderbird</td><td>（<a href="http://www.mozilla-japan.org/products/thunderbird/" target="_blank">http://www.mozilla-japan.org/products/thunderbird/</a>　）</td></tr>
</table><br>
  SpamAssassin と bsfilter はメールサーバに組み込んで使うものであり、Thunderbird は ＭＵＡである。<br>
<br>
　筆者のところでは、メールサーバに SpamAssassin を組み込み、希望者にメールサーバでの spam メール隔離機能を提供している。SpamAssassin は、300余りの細かなチェック項目を設け、その確率を点数にして各項目の合計点数を加算して、あらかじめ決めた点数以上になれば spam メールであると判定する仕組みになっている。<br>
<br><img src="http://blogs.manapo.com/email/images/img3_71.gif" border="0" align="left">
左記は、この一例である。<br>
SpamAssassin は、spam メールと判定した電子メールひとつひとつにこのようなレポート（何故 spam メールと判定したのか）を添える機能がある。<br>
<br>
「spam メールである」と判定する基準は変更でき、左の例では 10.0点以上を spam メールと見なすように予め設定している。<br>
この点数が、数学的な理論に基づく方法で導出したものである。中には、「こんなのが何故？」と思わされる項目もある。<br clear="all">
<br>上記を日本語にすると、
<table border="0" cellpadding="0" cellspacing="5" vspace="">
<tr><td valign="top">・電子メール回送元の一部にIP アドレスがおかしいのがあった</td><td>（評点 3.4）</td></tr><br>
<tr><td>・トップレベルドメインが .info である</td><td>（評点 0.8）</td></tr>
<tr><td>・第３レベルにキーワード www がある（www.*.info）</td><td>（評点 3.2）</td></tr>
<tr><td>・メール本文の一部に HTML 形式メッセージがある</td><td>（評点 1.0）</td></tr>
<tr><td>・メール本文の HTML 形式メッセージの割合が 70～80％である</td><td>（評点 1.0）</td></tr>
<tr><td>・このメールに、日本(JP) で spam と認識されるドメイン名が見受けられる</td><td>（評点 3.4）</td></tr>
<tr><td>・このメールに、セーシェル諸島(SC) で spam と認識されるドメイン名が見受けられる</td><td>（評点 3.6）</td></tr>
<tr><td>・薬物関係のメールと判断した</td><td>（評点 0.1）</td></tr></table>
<br>
<br>
この例では、spam メール判定基準を超える 16.5点だったので、spam メールと判定されたという訳である。<br>
<br>
　ベイジアンフィルタ方式の大きな問題点として、「誤判定」がある。<br>
　人間の目では明らかに spam メールだと判るのに「非spam」と判定されたり、<br>
　逆に重要な業務連絡の電子メールが、書き方や体裁が悪くて 「spam メール」と判定されたりすることがあるのだ。<br>
　そのため、特にベイジアンフィルタ方式では、「spamメール」と判定したなら、即削除せずに「隔離」するのだ。<br>
<br>
　誤判定は、ベイジアンフィルタに「学習させる」ことで軽減させる。いろいろな電子メールをパターン化して分析し、正しく点数をつけるための元ネタが多ければ多いほど判定が正確になるのだ。<br>
　この「学習」操作が、電子メール受信者自身で手動で行う内容なので、<br>
<br>
・ 個々に違う spam メールの判定基準を電子メールの受信者に合わせることが出来る　（長所）<br>
・ spam メールの判定精度を受信者自らが上げる素地がある（長所）<br>
・ 学習操作の煩雑さ（短所）<br>
<br>
　といった、長所も短所も兼ね備えた状態になっている。それでも７割以上の spam メールを隔離できるのだから、ベイジアンフィルタ方式の spam 対策の意味は大きいだろう。<br>
<br>]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-8</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071026000124.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.124</id>
   
   <published>2007-10-26T03:16:25Z</published>
   <updated>2007-11-15T01:27:54Z</updated>
   
   <summary>○submission とは？ ...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      <![CDATA[○submission とは？<br>
]]>
      <![CDATA[　今までは、電子メールの送信も中継も同じ受け口を使ってきた。<br>
　だが 2005年頃から、POP before SMTP からの移行と、メールサーバには、電子メールの送信受付専用の受け口を設けようという動きの中で、一部大手プロバイダの半ば苦肉の策(?) として登場したのが submission である。
<img src="http://blogs.manapo.com/email/images/img3_69.gif" border="0"><br>
左図は、日本国内で主に行われている submission サービスの模式図である。<br>
電子メールは歴史的経緯から、SMTP プロトコル用に予約されている 25番ポートを使って電子メールの送信依頼をいつも待ち構えている。<br>
<br>
ここで「ポート」とは、通信を行う際の接続口のようなもので、「ポート番号」はその接続口の番号であるが、１つのIP アドレスに対しては 65536のポートがあり、SMTP は通常 25番が割り当てられていると思っていただきたい。<br>
<br>
従来は、なんでもかんでも電子メールの送信には 25番ポートで受け付ける仕組みだったが、迷惑メール対策などの多機機能化の流れで、電子メール送信受付専用ポートを設ける考えが出てきて、これが submission ポート(587番ポート)という訳である。<br>
ところが、日本の場合は、商業的理由で POP before SMTP 形式の不正アクセス対策からさっさと SMTP Auth に移行しなかった一部プロバイダの技術的対応を図る場になっている感がある。<br>
<br>
　現状では、多くのプロバイダが、OP25B(Outbound Port 25 Blocking) と称して、自社以外の通信回線から 25番ポートへの接続を禁止し、本来さっさとやるはずだった SMTP Auth 対応を行っていると言う始末である。<br>
　更に言えば、現状では Port25 に流すプロトコルも Port587 に流すプロトコルも全く同じ SMTP である。<br>
　ただ、SMTP は長い目で見ると、今後はメールサーバ間専用の電子メール通信プロトコルと、メールサーバに対して電子メール送信を受け付けるプロトコルに分かれるかもしれないので、ポートを分割すること自体は悪い考えではない。]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-7</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071026000123.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.123</id>
   
   <published>2007-10-26T03:11:35Z</published>
   <updated>2007-10-26T03:26:53Z</updated>
   
   <summary>○不正アクセス対策 (POP before SMTP , SMTP-Auth)...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ○不正アクセス対策 (POP before SMTP , SMTP-Auth)
      <![CDATA[　これは、1996年から 1997年頃、それまで第三者中継が普通だった古き良き時代の文化を悪用され、正規の利用者以外（多くはコンピュータウィルスをばら撒くため）の利用が問題になり、特定のメールサーバに処理能力を超えるような電子メール処理が集中したりしたために考えられたものである。<br>
　以下、簡単にこれらの方式を示す：<br>
<br>
　・POP before SMTP<br>
<img src="http://blogs.manapo.com/email/images/img3_68.gif" align="left" border="0"><br>
左の図は、POP before SMTP の動作を簡単に示したものである。文字通り、POP で電子メールを受信したあとでないと電子メールを送信できないという仕組みである。<br>
<br>
これによって、メールサーバの正規ユーザだけが電子メールの送信を行うことが出来る仕組みが出来上がっている。<br>
<br>
POP の後、電子メールを送信する許可を与える時間はプロバイダによって異なるが、15分～60分くらいである。<br>
だが、この方式に対応していない有名なＭＵＡが１つだけ存在する。それは、Outlook Express。ダイヤルアップが主流だった時代は、送信トレイに電子メールが溜まっていると苦労したようである。このＭＵＡは、起動して回線が接続すると、送信処理を先に行う造りになっていたからである。<br>
<br>
<br>
　・SMTP Auth<br>
　当初の SMTP は、ユーザ認証の機能が無かった。<br>
　開発当初の 1982年頃といえば、電子メールは主に大型コンピュータを使う人の為のものであり、大型コンピュータを使うためには、電子メールを使う以前にユーザ認証のプロセスが入るので、勝手に使われることが無かったからである。<br>
　更に、電子メールを出来るだけ早く送り届けるためには相互協力が不可欠で、第三者転送が欠かせない古き良き時代だった時代背景もある。<br>
　SMTP-Auth は、既存の SMTP の仕様を拡張して、文字通りユーザ認証機能を取り込んだものである。<br>
　最近は、SMTP-Auth が主流になりつつある。<br>
<br>
　今や不正アクセス対策としての POP before SMTP は古典的な方法になってしまっているのだが、未だにいくつかの電子メールサーバで採用されている方式である。<br>
　筆者が管理するメールサーバでは、 POP before SMTP は 2004年に終息させ、全て SMTP Auth へ変更している。]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-6</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071018000112.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.112</id>
   
   <published>2007-10-18T04:43:08Z</published>
   <updated>2007-10-18T04:52:53Z</updated>
   
   <summary>― 電子署名や暗号電子メールの利用マナー...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ― 電子署名や暗号電子メールの利用マナー
      <![CDATA[　ここまで見て来たように、電子署名の検証や暗号電子メールは、その環境を整え、使い方を習得するだけでも負担を強いるものである。だから、必要性が特にないのにやみくもに電子署名の電子メールや暗号化電子メールを使うべきではない。<br>
　当事者間で合意を得てから利用するように手順を踏むべきであろう。<br>
<br>
　また、インストール手順が複雑だからといって、他人に任せるのは絶対にやめよう。<br>
　先ず、その行為自体がセキュリティホールである。「インストールを行った他人」にパスフレーズや秘密鍵・公開鍵を持ち出されてしまうとどうなるか考えると自明である。<br><br>

○POP・APOP・IMAP の違いについて<br>
　POP と IMAP なら、これまでにも数回出てきているので、何となく理解できる方もいらっしゃると思う。<br>
　どれも SMTP で電子メールが配送されたメールサーバから電子メールを取り込むためのものである。<br>
<br><table align="center">
<tr><td>POP・APOP</td><td>IMAP</td></tr>
<tr><td><img src="http://blogs.manapo.com/email/images/img3_66.gif" border="0"></td><td><img src="http://blogs.manapo.com/email/images/img3_67.gif" border="0"></td></tr>
<tr>
  <td>電子メールはメールサーバーから取得した後、基本的に受信後メールサーバから削除。<br>
  明示的な保存指定をすることで、一定期間保存可</td>
  <td>電子メールの一覧のみを取得・保存。<br>
  本文はメールサーバに全て保存。基本的に明示的な削除指示をしない限り電子メール本体はメールサーバ上に残る。</td></tr></table>
<br>                                     
　上図は、電子メールシステムの歴史（躍動期）の最後の方で示した POP と IMAP の相違を示した図を再掲したものである。<br>
　言い換えると、受信メールの保管方法が POP と IMAP の決定的な違いである。<br>
<br>
　では、POP と APOP の違いであるが、大枠は「殆ど同じ」である。<br>
　POP では、電子メールの取得にユーザＩＤ(電子メールアドレスなど)とパスワードの組を用いて、利用者の認証を行うが、パスワードが通信回線上を生データのまま流れるため、電子メール受信の為のPOPパスワードを盗み取られ、不正受信や不正参照が行われるという事態が起き得るということで、パスワード部分を暗号化したものが APOP という訳である。<br>
<br>
　APOPは、(Authenticated Post Office Protocol) の略である。<br>
　実際にはパスワード部分を MD5 形式で暗号化したものを生パスワードの代わりに送っているだけである。<br>
　そのため、受信する電子メール本体は、通信回線上では生データのまま流れることに変わりはない。]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-5</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071009000107.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.107</id>
   
   <published>2007-10-09T05:41:34Z</published>
   <updated>2007-10-18T01:06:09Z</updated>
   
   <summary>― 暗号メールを送信する...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ― 暗号メールを送信する
      <![CDATA[先ずは、電子署名の時と同様、通常どおり電子メールを作成する。<br clear="all">
<img src="http://blogs.manapo.com/email/images/img3_62.gif" border="0" align="left">
ここで、「暗号化」をクリックすると、送信者欄の右端に鍵マークが表示される。<br>
<br>
これは、「表示されているだけ」であり、実際に暗号化処理を始めるわけではない。<br>
この状態でいつもどおり「送信」をクリックすることで暗号電子メール送信処理が開始される。<br>
尚、暗号電子メール送信を行うためには、送信相手先の公開鍵が必要であることに注意すること。暗号電子メールの送信はこれで完了である。<br clear="all">
<br>
― 暗号メールを受信する<br>
<img src="http://blogs.manapo.com/email/images/img3_63.gif" border="0" align="left">GNUPG で暗号化した電子メールを Outlook Express で受信すると、
左図のようになる。<br>
これを受信者の秘密鍵で解読するのである。
<br clear="all"><br>
<center>
  <img src="http://blogs.manapo.com/email/images/img3_64.gif" border="0">　<img src="http://blogs.manapo.com/email/images/img3_65.gif" border="0"><br>
</center>
暗号電子メールの解読にも WinPT を用いる。WinPT を起動し、<br>
-----BEGIN PGP MESSAGE----- と -----END PGP MESSAGE----- 行を含めた電子メール全体を、<br>
右クリック → すべて選択(A) → 右クリック → コピー(C) としてから、<br>
タスクトレイのWinPT アイコン右クリック → clipboard → Decrypt/Verify をクリックすると、
<br>
秘密鍵のパスフレーズ入力を要求される。（上図左側）<br>
ここで、「 Please enter your passphrase 」の下の欄に公開鍵と秘密鍵ペアの生成をした時に設定したパスフレーズをキーボードから入力し、「 OK 」をクリックする。<br>
<br>
そうすることで、復元された電子メールが表示される。（上図右側）<br>
別の電子メールを処理したり、新たな電子メールを Outlook Express で作成する場合は、秘密鍵や公開鍵が見つからないと不可解な警告が出たり、本文の日本語入力が出来なくなる不具合などが起きるので、必ず WinPT は終了させること。<br>
だが、今後のバージョンアップでこれらの不具合は解消されるだろう。<br>
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-4</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071009000106.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.106</id>
   
   <published>2007-10-09T05:35:02Z</published>
   <updated>2007-10-11T01:05:01Z</updated>
   
   <summary>― 電子署名の検証をする ...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      ― 電子署名の検証をする

      <![CDATA[　電子署名をする理由のひとつに「発信元証明」がある。この証明処理を電子メールの受け手がするかどうかは自由だが、いつでも出来ることが必要である。<br>
<br>
　受け手が「発信元証明」をするためには、送信者の公開鍵が必要である。<br>
　公開鍵サーバもあるが、ここでは、受け手へ公開鍵を渡す方法を示す：<br>
<img src="http://blogs.manapo.com/email/images/img3_55.gif" border="0" align="left">
GPA を起動し、<br>
予め渡したい鍵をハイライトさせた上で、Export をクリックする。<br clear="all"><br><br>
<br>
<br>

<img src="http://blogs.manapo.com/email/images/img3_56.gif" border="">　<img src="http://blogs.manapo.com/email/images/img3_57.gif" border="0"><br>
すると、上図のような画面が出てくる。<br>
　ここで保存フォルダとファイル名を指定する。フォルダ名やファイル名で注意して頂きたいのは、現行のバージョン (2007/05/22 現在) では、日本語文字を正しく認識しないバグがあることである。<br>
　上図左側では日本語フォルダがあるが、フォルダ内の参照は出来ても Export 処理はエラーが起きて出来ない。<br>
　上図右側のように日本語文字を含まないフォルダ名・ファイル名にする必要がある。<br>
<br>
　この例では、E:\Work\mypublic.asc というファイルに公開鍵が Export される。<br clear="all">
<img src="http://blogs.manapo.com/email/images/img3_58.gif" border="0" align="left"><br>
Export されたファイルの中身は、左記のようにテキストエディタで参照可能である。<br>
<br>
ちなみに左記は、筆者の現在のPGP 公開鍵(2007/05/22 現在)である。<br>
<br>
これをこのままの形で受け手へ渡すのである。<br>
-----BEGIN PGP PUBLIC KEY BLOCK-----  と、<br>
-----END PGP PUBLIC KEY BLOCK----- の行も含めて渡すことに<br>
留意すること。<br>
<br>
もし、相手から左記のような PGP 公開鍵を受け取ったら、適当なファイルに保存しておこう。<br>
保存ファイルも日本語フォルダ名・ファイル名は上手くインポート処理(後述)できないので、その点にも注意が必要である。<br clear="all">
<br>
<br>
<img src="http://blogs.manapo.com/email/images/img3_59.gif" border="0" align="left"><br>
受け取った公開鍵を取り込むには、<br>
GPA を起動し、Import をクリックし、Export と同じような手順で行う。<br>
日本語のフォルダ名やファイル名は表示だけするが、読み書きが出来ないバグがあるので、Export の場合と同様の注意が必要である。<br>
Windows において、GNUPG で電子署名された電子メールを検証するには、WinPT を使用する。<br>
WinPT は、タスクトレイから、スタート → すべてのプログラム(P) → GnuPG For Windows → WinPT で起動できる。<br>
これもデスクトップにショートカットを作っておくと良い。<br>
WinPTが起動すると、タスクトレイに <img src="http://blogs.manapo.com/email/images/img3_52.gif"  border="0"> のように該当アイコン（一番左のもの）が常駐する。<br>
　終了するときは、右クリック → Exit クリックで終了できる。<br>
　ダブルクリックすると、登録されている公開鍵の一覧が表示される。GPA と似たようなことが出来る。<br>
<br>
<img src="http://blogs.manapo.com/email/images/img3_60.gif" border="0" align="left">
GNUPG で電子署名された電子メールを Outlook Expressで受信すると、左記のような状態になる。<br>
余計なものが前後にくっついてしまっている。<br>
<br>
これは、Outlook Express が GNUPG 形式で電子署名された電子メールのフォーマットに完全に対応していないことによる。<br>
<br>
WinPT で署名検証を行うには、左記の電子メール全体(-----BEGIN PGP … から -----END PGP … を含む行全て)を右クリック → すべて選択(A) → 右クリック → コピー(C) としてから、<br>
タスクトレイのWinPT アイコン右クリック → clipboard → Decrypt/Verify をクリックすると、<br clear="all"><br>
<img src="http://blogs.manapo.com/email/images/img3_61.gif" border="0" align="left"><br>
左記のように検証結果が表示される。<br>
‘The signature is good’と表示されていれば、この電子メールは問題ないということになる。<br>
<br>
同時に故意に改ざんされていないこともここで確認できる。<br>
「 OK 」クリックでこの画面を閉じる。<br><br>
尚、WinPG で、WinPG が　GPGoe へ悪影響を与えているバグがみられるので、WinPG は検証終了後、終了させた方が良いようである。<br>
WinPG をタスクトレイに常駐させたまま Outlook Express を終了・起動すると、Outlook Express で電子メールを作成する際、日本語入力が出来なくなる不具合が発生する。
]]>
   </content>
</entry>
<entry>
   <title>電子メールの掟（技術偏）-3</title>
   <link rel="alternate" type="text/html" href="http://blogs.manapo.com/email/archives/071009000105.html" />
   <id>tag:blogs.manapo.com,2007:/email//2.105</id>
   
   <published>2007-10-09T05:30:43Z</published>
   <updated>2007-10-09T06:05:50Z</updated>
   
   <summary>さて、ここからは、実際に使い方を簡単に Outlook Express を例にし...</summary>
   <author>
      <name></name>
      
   </author>
         <category term="電子メールの掟（技術偏）" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="ja" xml:base="http://blogs.manapo.com/email/">
      <![CDATA[さて、ここからは、実際に使い方を簡単に Outlook Express を例にして紹介する。 <br>
― 電子署名をする<br>
　先ずは、通常どおり電子メールを作成する。<br>]]>
      <![CDATA[<img src="http://blogs.manapo.com/email/images/img3_53.gif"  border="0" align="left"><br>そして、「署名」をクリックすると、送信者欄の右端に署名マークが表示される。<br>
<br>
これは、「表示されているだけ」であり、実際に電子署名を行い、その処理が終わっているわけではない。<br>
<br>
この状態でいつもどおり「送信」をクリックすることで電子署名処理が開始される。<br clear="all">
<br>
<img src="http://blogs.manapo.com/email/images/img3_54.gif"  border="0" align="left">電子署名には、秘密鍵と公開鍵を用いるが、秘密鍵を使用する時点で、左記のようにパスフレーズの入力を求められる。<br>
ここで、「 Please enter your passphrase 」の下の欄に公開鍵と秘密鍵ペアの生成をした時に設定したパスフレーズをキーボードから入力し、「 OK 」をクリックする。<br>
ここで電子署名処理が行われ、電子メールが通常どおり送信される。]]>
   </content>
</entry>

</feed>
