迷惑メール対策していますか？
今日は迷惑メール対策がテーマです。
迷惑メールもすっかり定着して当然のようになりました（これでは困るのですが）。最近は迷惑メールを判定するシステムも精度があがり、手元に届くものはごく一部となりましたが、実は、実際には山のような迷惑メールが送信されています。うまくフィルタリングされているので気が付かないだけです。
以下は、今月から当社で運営しているメールサーバーで９月１８日に外部から受信したメールの処理件数です。
メール利用者数（アドレス数） 約３５人
①受信 1050
②SPFエラー 391
③送信元ドメインエラー 44
④受信 615
②と③が明らかに迷惑メールとされるメールの件数です。全体の４１％です。
更に、この後の処理で④の中で内容が迷惑メールと判定されるケースもありますので、それらを合わせると半分以上が迷惑メールです。
迷惑メールは１件でも目にしたらすごく不快な気分になると思います。もし自分のメール一覧の半分が迷惑メールであったなら、メールを使うのは苦痛かもしれません。
上記のエラーの種類で②SPFエラーという項目があります。
これは、迷惑メールを判定するためのSPF方式（呼び名は正しくないかもしれません）で迷惑メールと判定されたという意味です。
SPF方式というのは、迷惑メールを判定するために送信者のドメインのDNSにSPFレコードを設定するものです。SPFレコードには、そのドメインの送信メールサーバーのサーバー名（かIPアドレス）を定義します。SPFレコードに定義されたサーバー以外から送信されたメールは迷惑メールと判断することができます。
SPFレコードの例
①”v=spf1 include:spf.protection.outlook.com ~all”
②”v=spf1 include:_spf.google.com ~all”
①はOffice365を利用している例、②はGoogleAppsを利用している例です。
それぞれ、送信メールサーバーを定義しています。
サーバーが１台の場合はIPアドレスを書くだけでもOKです。
プロバイダーのメールサーバーを利用している場合は、プロバイダーからSPFの書き方の案内があると思います。
先のエラー件数で、SPFエラーが全体の３７％もありますから、SPF判定を入れるのと入れないとでは大きな違いです。今よりも３７％多い迷惑メールがユーザーに配信されることになります。
私の感覚では、このSPFの方式は５，６年前から普及し始めたと思います。特殊なソフトウェアやライセンスも不要でDNSにレコードを追加するだけで運用できますから、大変よいしくみだと思います。
しかし、課題もあります。
これは、各企業が自社のDNSにSPFレコードを定義してもらわないと判定ができません。意外なのですが、上場会社や大企業でもこの対策をしていない企業が結構あります。SPFレコードがない場合はそのドメインに対しては判定をスキップしますが、送信者の偽装を見破ることができません。
最悪なのが、間違ったSPFレコードを記述してしまうことです。そうするとメールが受信拒否されてしまうことがあります。
また、受信メールサーバーがその機能に対応している必要があります。今回、当社で急遽メールサーバーを運用し始めたのも、お客様から迷惑メールが多いという相談を受けたことによります。
フィルターを入れているのにおかしいと思い調べてみると、なんと利用している大手プロバイダーのメールサーバーがSPF方式に対応しておらず、高価なメールフィルタリングサービスを利用しているにも関わらず、それをすり抜ける迷惑メールがあるということがわかりました。
よって、急遽、一番最初に受信するメールサーバ（MXサーバー）を稼動させた結果が冒頭の処理件数です。
冒頭の処理件数でいう②と③だけでもかなり迷惑メールが防げます。これに更にメール内容のフィルターソフトを使えばほぼ万全だと思います。
迷惑メールを防ぐしくみとサーバー性能と及び通信速度の向上と相まって、１５年前にくらべてメールサーバーの運用もかなり楽になりました。
当時のメールサーバーの運用はメールが詰まって本当に大変でした（しみじみ）。
さて、皆さんの会社の迷惑メール対策は大丈夫でしょうか？
SPF対策など迷惑メールを送信できないしくみがとても重要です。
※本記事はメールマガジン『インスクエア ビジネスニュース』に寄稿しました。
クラウド・エヌ
最近は、ＮＴＴコミュニケーションズの「クラウド・エヌ」というサービスをよく利用しています。３月ごろに、知り合いから紹介を受けて、たまたまその時に対応していた案件にフィットしたため、それ以来顧客に紹介したり、自社でもちょくちょく利用しています。
先週はセミナーにも参加し、なるほど、これは確かに楽チンだな、と更に思うようになりました。
「クラウド・エヌ」というのは、誤解を恐れずに分かりやすく言えばレンタルサーバーのクラウドサービスで、NTTCom社が運営するサービスの固有名詞です（と言ってもよくわからない！？）。実際にはレンタルサーバーだけにとどまらず、一般的にはIaaS（Infrastructure as a Service）と呼ばれるサービスで、インフラ全体をクラウドとして提供するサービスです。
皆さん、パソコンのＣＰＵでデュアルコア、とか、４コア、というのは聞いたことがあると思います。例えば１００コアくらいの巨大なＰＣがあったとして、それを複数人が、あたかも自分が占有しているような使い方で利用できるレンタルサーバーのサービスがイメージしやすいでしょうか。
わかりやすくするためにレンタルサーバーと言いましたが、単純にサーバーの時間貸しではなく、仮想データセンターサービスと言った方がよいかもしれません。
リアルな世界では、普通の企業がデータセンターを利用する場合は、データセンター事業者の建物フロアに横幅１９インチのサーバーラックを１つとか複数配置して、そのラック内に自社で利用するインターネット回線を引き込み、ネットワーク機器やサーバーを設置します。ラックの中に何を設置しても基本自由です。自社のサテライトオフィスのようなものです。
よって、データセンターを利用するときは、回線手続きが必要で、機材の運搬も必要です。当然それらの設定も必要になります。これは大変骨の折れることです（私が嫌なのはケーブルの始末です）。また、最低限利用するには契約金を含めると人件費を除いても初期費用５０万、月額でも７、８万は必要です。
これに対し、「クラウド・エヌ」を利用すると、非常に簡単に、リアルなデータセンター利用と同じことが机に座っていたままで出来てしまいます。
使い方は本当に簡単です。クラウド・エヌの申込みをしてＩＤを取得したら、そのＩＤが１９インチラックの鍵だと思えばいいです。あとは、その中に仮想サーバーを設置できます。ＶＰＮのために仮想ルーターを設置できます。バックアップのための仮想ディスクも設置できます。あの煩わしい運搬やケーブリングをしなくても済みます。これは驚異的なことです。
更に嬉しいのはコストです。利用にかかるためのコストは人件費を除けば０円です。初期費用が５０万円かかるのに対し、０円です。また、月額の利用料金も仮想のリソースを稼働させている時間だけ課金されるので、不要な時はサーバーを停止させておけば料金が発生しません。
ただし、本格的にフルタイムで利用したり、仮想サーバーの数が増えると、費用は通常のレンタルサーバーと変わらないか、リアルなデータセンターの集積度を上げればその方が安いかもしれません。
同種のサービスではAmazon EC2がパイオニアです。その他、国内ではGMOクラウドや、最近ではNiftyクラウドも登場しました。クラウド・エヌ以外のサービスは詳しくは知らないのですが、このクラウド・エヌのすごいところは、サーバー周辺のネットワーク、ＤＮＳやディスクなどのサービスが充実していることです。事業運営に必要なＩＴリソースはすべてあるという感じです。
更に興味深いのは、どのサービスも仮想マシンを操作するＧＵＩは同じように思えます。勉強不足で知らないのですが、仮想マシンを運用する共通のプラットフォームがあるということかもしれません。それは何なのか。もしかしたらそれはAmazonのソフトウェアなのかもしれない。とすると、それさえも売り物にしてしまうAmazonという企業は空恐ろしい感じがします。
話は戻りますが、「クラウド・エヌ」では自分でＯＳイメージをアップロードすることができますので、Windows XPやWindows7も利用することができます。ベンダーに依らないので、ベンダーロックだ、と言っています。
１５年くらい前にWindowsのリモートデスクトップが登場した当時、すべてのＰＣを仮想化して、ということが話題となりました。使う側はシンクライアントです。当時のサーバー技術はブレードサーバーなどでハードウェアの集積化でした。今もそれは同じかもしれませんが、ハードウェアは完全に表に出なくなりました。
ここで今日のタイトルです。「デスクトップＰＣが無くなる」日が本当に来るかもしれません。ほとんどのデスクトップＰＣはクラウドということも現実的になったと思います。
さて、この便利な「クラウド・エヌ」の使い方も重要です。これらのサービスを使う目的は何でしょうか？思いつくもので以下の３つです。
①障害に強いシステムの構築
②自由度が高くスピーディーな環境の構築
③上記の低コストでの実現
①は事業が大きくなればなるほど最重要ですが、小規模企業や個人事業レベルでは②、③が重要です。本当に個人レベルでも大企業レベルのインフラが利用できるようになりました。
ここで重要なのは、何か事業をしていないと全く活用する機会がないということです。例えば派遣に出ているエンジニアが、就業時間外に自己負担でこのようなサービスを利用して学習したり仕事の問題解決にあたったりという活用ができます。（もちろんデータの持ち出しはダメです！）これは個人レベルであっても既に事業の一部と言えると思います。その延長が起業です。
所属会社や大きな組織に依らずに今まで出来なかったことができるようになります。逆に言うと、できなかった理由がなくなっていくということなので、言い訳ができなくなってくるということです。やる者とやらない者の差は今まで以上に大きくなるのかなという気がします。
当社もデータセンターはいくつか契約していますが、１年くらいかけてIaaSに移行をしていきます。しかし、そうなると５月に一度はやめようと思った台湾の小さいデータセンターはコストも小さく台湾に行く理由にもなるので、そのまま継続した方がいいかもしれません（こういうのを付加価値というのだろうか）。
一方、当社で手掛けているデジタルサイネージ事業はまだまだハードウェアを使う事業なので、流れに反してはいますがその分参入が難しく、エンジニアとしても面白味があります。やっぱり自動車レースが全部ゲームセンターになったら面白くないです。とにかく特色ある事業を展開したいものです。
※本記事はメールマガジン『インスクエア ビジネスニュース』に寄稿しました。
レンタルサーバーとＤＮＳ
以下は直近１年間で対応したインターネット関連サーバー移転の主な案件です。
・レンタルサーバーの利用プラン打ち切りによるサーバー移転
・Ｅコマース用のサーバーの既存ドメインでの構築
・異なるＵＲＬのウェブサイトの統合
・ウェブサイトのテスト用サーバーの構築
・グループウェアサーバーの自社ドメインでの構築
・メールセキュリティの強化（２案件）
サーバー移転というのは結果であって、要件はサービスの移転や内容変更です。その結果としてサーバーを丸ごと変更したり複数のサーバーに分散させたり、クラウドのアプリケーションサービスを利用したりと、その実現方法には様々な形態があるわけです。
サーバーの移転のお話しをすると、それほど難しい仕事ではないと思われる方が結構いらっしゃいます。特に、ウェブのご自身で運営さえている方やその知識がある方はそういう傾向にあると思われます。恐らく、ご自身で多少なりとも知識や経験があるからだと思います。
そういう方々とお話しをしていて、非常に重要な機能でほとんどの方が理解できないのがＤＮＳです。ＤＮＳはDomain Name Systemの略です。なぜＤＮＳが関係するかというと、ほとんどのレンタルサーバーはサーバーの利用とドメイン管理とＤＮＳがセットになっていて、レンタルサーバーの業者を変更するということは、ほぼ、そのドメインが利用するＤＮＳサーバーも一緒に移転しなくてはならないケースが多いからです（もちろんそうならないようにもできます）。
そのことがわからないのでずっと同じレンタルサーバーを利用しているという企業も多いと思います。そういう方は一度ご相談ください。
ウェブデザイナーや経験の浅いネットワークの技術者ではドメインやＤＮＳの移転の方法は経験がない人も多いのではないかと想像します。
ドメイン名というのはほとんどの方がご存じだと思いますが、ＤＮＳというのは聞いたことはあっても何をしているかよくわからない方が多いと思います。そして、その制度としくみになるとほぼ専門家の世界となります。
簡単にいうと、ＤＮＳというのはそれぞれのドメインのサーバー（ホスト名）がどのＩＰアドレスを使っているかという、ホスト名とＩＰアドレスを関連付けるしくみであって、ＤＮＳサーバーというのは辞書サーバーのようなものです。ＤＮＳの技術的なしくみについてはネットにたくさん記事がありますので、興味のある方は検索してみてください。
インターネットで利用するサーバーには必ずＩＰアドレスが割り当てられています。ドメイン名とＩＰアドレスを関連付けるＤＮＳサーバーにも当然ＩＰアドレスが割り当てられています。
ドメイン名はレジストラや指定管理事業者と呼ばれるばれる認定された会社（以降レジストラ）がドメイン申請企業からの依頼に基づき発行します（もちろん有料）。レジストラとして有名な会社は「お名前.com」などがあります。
そして、ドメイン名と、それぞれのドメイン名が利用するＤＮＳサーバーを関連付ける最上位のＤＮＳサーバーがありますが、この運営はレジストラ企業が共同で行っています。レジストラは自社が発行したドメイン名に限り、そのドメイン名のＤＮＳサーバーの登録や変更が行えます（ドメイン管理業務）。
自社ドメインのＤＮＳサーバーなんて知らないよ、という方もおられると思いますが、レジストラはそれぞれに利用者向けのＤＮＳサーバーを独自で運営していますので、ドメイン名だけを取得した場合や、ドメイン名取得とレンタルサーバー利用を同時に申し込んだ場合は、レジストラ独自のＤＮＳを利用していることがほとんどです。これはほとんど意識されません。
しかし、ＥＣや複数ドメイン利用などを効率よく運営しようとすると、ウェブやメールのサーバーとＤＮＳサーバーが一緒では自由度がなく何かと不都合です。そこで、本格的なネットワークサービスではＤＮＳとその他のサーバーを切り離します。レジストラが異なる複数ドメインの運用や障害対策などメリットがあります。
一方、ＤＮＳサーバーを自社で運営するというのは注意が必要です。ＤＮＳサーバーを乗っ取られるということはそのドメインで利用しているサーバーすべてを乗っ取られるようなものです。また、ＤＮＳサーバーのセキュリティが甘いと他のドメインのＤＮＳサーバーとして機能してしまったりして迷惑をかけることになります。ＤＮＳサーバーはなるべくレジストラが提供するサーバーを利用した方がよいでしょう。
では、複数のドメインを異なるレジストラから取得している場合はどうしたらいいか。レジストラは変更が可能なのでレジストラの変更をしてなるべく一つのレジストラに集約し、ＤＮＳサーバーもそのレジストラのサーバーに集約するのがよいと思います。レジストラが提供するＤＮＳサーバーはそれほど専門知識がなくても設定の変更ができる管理ページがありますので（その操作を覚えることは大変ですが）、サポートを受けながらであれば自主運営が可能だと思われます。
これ以上書くと訳が分からなくなるので以上です。
今日から９月で、３月決算の企業は上期の最終月です。
涼しくなり仕事もやりやすくなりましたから、集中して仕事に取り組みたいものです。
※本記事はメールマガジン『インスクエア ビジネスニュース』に寄稿しました。
