2008年4月22日時点での日経225採用銘柄におけるSPFレコード登録の状況は、全体で33件となり、設定率は14.6%となりました。この数字は、3月の調査から比較して1件の増加ということになります。（本調査は、HDEが非公式に、毎月20日頃に日経225採用銘柄のドメインに対し、SPFレコードが設定されているかどうかを独自調査し、主要企業の対応動向を毎月レポートするものです）
三越と伊勢丹、三井住友海上火災保険を除外し、ユニーと三越伊勢丹ホールディングス、三井住友海上グループホールディングスを採用する
April 2008 Archives
前回の予告通り「「Google App EngineでHello World!! + ローカルLinux環境」をやっていて出たエラーの Q & A」です。
Continue reading 「Google App EngineでHello World!! + ローカルLinux環境」をやっていて出たエラーの Q & A.
前回に引き続きGoogle App EngineでHello World!!です。
実際にGoogle App Engineにアップロードしてみましょう。
注意 ： Googleアカウントをすでに取得しており、Google App Engineからメールで招待されている事を前提としています。
Googleアカウントでログインした状態で、以下の画面にアクセスし、ボタンを押しておくと2-3日でメールが届きます。
実際にGoogle App Engineにアップロードしてみましょう。
注意 ： Googleアカウントをすでに取得しており、Google App Engineからメールで招待されている事を前提としています。
Googleアカウントでログインした状態で、以下の画面にアクセスし、ボタンを押しておくと2-3日でメールが届きます。
Continue reading Google App EngineでHello World!! + ローカルLinux環境 ( 2 ).
Google App Engineのライセンスが届いたので、Hello Worldしてみました。
WindowsやMacのローカル環境構築は、他のサイトにありましたがLinux環境はなかったので一緒に作ってみます。
環境
OS : CentOS 32bit(i386)
Python : 2.5.2
注意 ： すでにVMWareかなにかでCentOSが導入されていることを前提に書いていきます。
WindowsやMacのローカル環境構築は、他のサイトにありましたがLinux環境はなかったので一緒に作ってみます。
環境
OS : CentOS 32bit(i386)
Python : 2.5.2
注意 ： すでにVMWareかなにかでCentOSが導入されていることを前提に書いていきます。
Continue reading Google App EngineでHello World!! + ローカルLinux環境.
迷惑メールのほとんどは、送信元情報を詐称して送られています。このような状況を踏まえて、2007年10月号のHDEコラム - 迷惑メール撲滅への第一歩を踏み出そう！では、送信ドメイン認証で送信元を認証することが、迷惑メール対策に非常に有効であるとご紹介しました。
また、弊社の小椋のブログ、テクノロジー解放日記 - SPF対応企業が11月に急増でも書かいているように、NTTドコモが2007年11月1日からSPFによるなりすましメールの拒否機能を無料提供しています。NTTドコモのなりすましメールの拒否機能は、SPFを登録しておらず、正当なメールサーバーから送信されたことが判別できないメールもなりすましメールと扱われるため、送信ドメイン認証の導入は必須となったと言えるかもしれません。
今回は、送信ドメイン認証を導入後、営業の方などが、社外から会社のメールアドレスを使用して、メールを送信する場合に想定される問題点とその対策をご紹介します。
営業の方などが、社外（ISP業者のネットワーク）から会社のメールアドレスを使用してメールを送信する場合に、ISP業者のメールサーバーを使用すると、送信ドメイン認証において送信元情報詐称と判断されたり、会社のメールサーバーで全てのメールをアーカイブすると決められていても、会社のメールサーバーを経由しないため、アーカイブの対象にならないということが発生します。
このような問題点は、会社のメールサーバーを使用することで解決できます。
しかし、近年、ISP業者では迷惑メール対策の一環として、ISPが提供するメールサーバー以外のメール受付ポート（25番ポート）との通信を禁止するOP25B（Outbound Port 25 Blocking）を採用しているため、会社のメールサーバーのメール受付ポートにはアクセスできません。
このため、VPN環境を用意するか、会社のメールサーバー側で、メール受付ポートとは別のポート（Submission）でメールを受け付けるようにした上で、SMTP AUTHで正規ユーザーのメールだけを受けるという対応が必要になります。
また、SubmissionポートでのSMTP AUTH時に、ユーザーIDやパスワードが通信データとして流れるため、SSLによる通信データの暗号化を行い、経路上での盗聴を防ぐことも忘れずに行う必要があります。
メールクライアント側では、Submissionポート、SMTP AUTH、SSLを使用するように設定しておけば、使用しているネットワークが社内ネットワークであるか、ISP業者のネットワークであるかということを意識することなく、常に会社のメールサーバーを使用してメール送信できます。
HDE Anti-Spam 2 for Gatewayでは、Submissionポートでのメール受付、SMTP AUTH、SSLによる通信データの暗号化といった環境を、非常に簡単に構築できます。
評価版もございますので、是非お試し頂ければと思います。
また、弊社の小椋のブログ、テクノロジー解放日記 - SPF対応企業が11月に急増でも書かいているように、NTTドコモが2007年11月1日からSPFによるなりすましメールの拒否機能を無料提供しています。NTTドコモのなりすましメールの拒否機能は、SPFを登録しておらず、正当なメールサーバーから送信されたことが判別できないメールもなりすましメールと扱われるため、送信ドメイン認証の導入は必須となったと言えるかもしれません。
今回は、送信ドメイン認証を導入後、営業の方などが、社外から会社のメールアドレスを使用して、メールを送信する場合に想定される問題点とその対策をご紹介します。
営業の方などが、社外（ISP業者のネットワーク）から会社のメールアドレスを使用してメールを送信する場合に、ISP業者のメールサーバーを使用すると、送信ドメイン認証において送信元情報詐称と判断されたり、会社のメールサーバーで全てのメールをアーカイブすると決められていても、会社のメールサーバーを経由しないため、アーカイブの対象にならないということが発生します。
このような問題点は、会社のメールサーバーを使用することで解決できます。
しかし、近年、ISP業者では迷惑メール対策の一環として、ISPが提供するメールサーバー以外のメール受付ポート（25番ポート）との通信を禁止するOP25B（Outbound Port 25 Blocking）を採用しているため、会社のメールサーバーのメール受付ポートにはアクセスできません。
このため、VPN環境を用意するか、会社のメールサーバー側で、メール受付ポートとは別のポート（Submission）でメールを受け付けるようにした上で、SMTP AUTHで正規ユーザーのメールだけを受けるという対応が必要になります。
また、SubmissionポートでのSMTP AUTH時に、ユーザーIDやパスワードが通信データとして流れるため、SSLによる通信データの暗号化を行い、経路上での盗聴を防ぐことも忘れずに行う必要があります。
メールクライアント側では、Submissionポート、SMTP AUTH、SSLを使用するように設定しておけば、使用しているネットワークが社内ネットワークであるか、ISP業者のネットワークであるかということを意識することなく、常に会社のメールサーバーを使用してメール送信できます。
HDE Anti-Spam 2 for Gatewayでは、Submissionポートでのメール受付、SMTP AUTH、SSLによる通信データの暗号化といった環境を、非常に簡単に構築できます。
評価版もございますので、是非お試し頂ければと思います。
Linuxを使っていれば、ログファイルのようにどんどん増え続けるファイルの内容を視認するために、「tail」コマンド「-f」オプションを使用して監視する場面が多いと思います。
「tail -f」コマンドは監視対象のファイルのサイズが小さくなっても自動末尾を検知し、そこから読み込みを再開します。
さらに、「--retry」オプションを使用すれば、監視対象のファイルが削除・リネームされても同じ名前のファイルが作成されると再び監視を開始するので、ログのローテーションにも対応できるというわけです。
Continue reading ERRORログをメールで通知する ～tailコマンド編～.
