12/02: 一斉メールの送信方法
Category: General
Posted by: Hatchobori
----- 近所のスーパーに行くためにポルシェを買う必要はない -----
多くの企業は、何らかの方法でお客様やお取引先にメールを送信していると思います。
当社のBitMailPROのような専用ソフトウェアを使用している場合もあるでしょうし、メール配信のASPやSaaS型のサービスを利用している場合もあるでしょう。
中には、OutlookなどのメールソフトのBCC機能で送信している場合もあるかもしれません。
どの方法でメールを送信するかにより、個人情報の管理や送信費用、そして送信スピードなども異なってきますので使い方や目的に合った方法を選択することが大事です。
送信先が何十万件もあり、短時間に送信しなければならないということであれば、ASPやSaaS型のサービス。
数万件以下でそれほど短時間で送信する必要がなければ専用ソフトウェア。
100件程度であれば、メールソフトのBCC機能といったところで概ね判断できます。
但し、お客様やお取引先のメールアドレスなどの個人情報をどのように扱うかは、各企業の個人情報管理運営ポリシーがあると思いますので、外部のサービスに情報が出せない場合もあると思います。
そのような場合は、送信件数やスピード的にはASPやSaaS型を選択すべき場合でも、個人情報管理を優先して専用ソフトウェアを利用することも考えなければなりません。
また、コストも大切な判断材料です。
ASPやSaaS型のサービスは、月間配信数により月額費用が変わるタイプや、送信リストの件数よるもの、その月の1回あたりの最大送信件数により料金が決まるものなど様々で、費用は、毎月数千円から数万円、年間では数万円から数十万円かかる場合が多いようです。
一方、専用ソフトウェアは、当社のBitMailPROが2万円程度で、他社のソフトもおおむねその程度の金額です。
ソフトを購入すれば、通常はランニングコストがかかりませんので、送信回数や件数を気にすることなく何度でもメール送信できます。
もちろん、通常使っているOutlook等のBCCで送信するのであれば、費用は無料です。
但し、BCC機能で送信する場合、操作を誤ってCCやToにあて先を入れて送信してしまうといった情報漏洩の危険性があるのでできれば避けた方がいいでしょう。
ところで大企業は別として、中小企業はメールを何十万～何百万件も送信するほどリストがあるでしょうか？
一昔前なら、リストを業者から購入して一斉配信ということもあったかもしれませんが、メール受信者の同意なくメールを送信することが違法となっている現状では、ほとんどの企業の送信リストの件数は数万件以下だと思われます。
つまり、ASPやSaaS型のサービスは、オーバースペックになってしまう可能性が高いわけで、日本の約99%を占める中小企業の大半は専用ソフトウェアで事足りるのではないかと思います。
近所のスーパーに行くためにポルシェのような高性能の車を買う必要はなく、普通の車で十分だということです。
まずは専用ソフトウェアで送信してみて、対応しきれない送信件数だとしたらASPやSaaS型のサービスに移行すればいいのです。
最後に宣伝になりますが、当社のBitMailPROは、「個人情報漏洩リスク「ゼロ」の同報メール送信ソフト」として上場IT企業をはじめ多くの企業に採用されている一斉メール送信ソフトです。
30日間機能制限なく無料でお試しいただけますので、ぜひダウンロードしてみてください。
http://www.newsbit.co.jp/software/bmp/index.html
多くの企業は、何らかの方法でお客様やお取引先にメールを送信していると思います。
当社のBitMailPROのような専用ソフトウェアを使用している場合もあるでしょうし、メール配信のASPやSaaS型のサービスを利用している場合もあるでしょう。
中には、OutlookなどのメールソフトのBCC機能で送信している場合もあるかもしれません。
どの方法でメールを送信するかにより、個人情報の管理や送信費用、そして送信スピードなども異なってきますので使い方や目的に合った方法を選択することが大事です。
送信先が何十万件もあり、短時間に送信しなければならないということであれば、ASPやSaaS型のサービス。
数万件以下でそれほど短時間で送信する必要がなければ専用ソフトウェア。
100件程度であれば、メールソフトのBCC機能といったところで概ね判断できます。
但し、お客様やお取引先のメールアドレスなどの個人情報をどのように扱うかは、各企業の個人情報管理運営ポリシーがあると思いますので、外部のサービスに情報が出せない場合もあると思います。
そのような場合は、送信件数やスピード的にはASPやSaaS型を選択すべき場合でも、個人情報管理を優先して専用ソフトウェアを利用することも考えなければなりません。
また、コストも大切な判断材料です。
ASPやSaaS型のサービスは、月間配信数により月額費用が変わるタイプや、送信リストの件数よるもの、その月の1回あたりの最大送信件数により料金が決まるものなど様々で、費用は、毎月数千円から数万円、年間では数万円から数十万円かかる場合が多いようです。
一方、専用ソフトウェアは、当社のBitMailPROが2万円程度で、他社のソフトもおおむねその程度の金額です。
ソフトを購入すれば、通常はランニングコストがかかりませんので、送信回数や件数を気にすることなく何度でもメール送信できます。
もちろん、通常使っているOutlook等のBCCで送信するのであれば、費用は無料です。
但し、BCC機能で送信する場合、操作を誤ってCCやToにあて先を入れて送信してしまうといった情報漏洩の危険性があるのでできれば避けた方がいいでしょう。
ところで大企業は別として、中小企業はメールを何十万～何百万件も送信するほどリストがあるでしょうか？
一昔前なら、リストを業者から購入して一斉配信ということもあったかもしれませんが、メール受信者の同意なくメールを送信することが違法となっている現状では、ほとんどの企業の送信リストの件数は数万件以下だと思われます。
つまり、ASPやSaaS型のサービスは、オーバースペックになってしまう可能性が高いわけで、日本の約99%を占める中小企業の大半は専用ソフトウェアで事足りるのではないかと思います。
近所のスーパーに行くためにポルシェのような高性能の車を買う必要はなく、普通の車で十分だということです。
まずは専用ソフトウェアで送信してみて、対応しきれない送信件数だとしたらASPやSaaS型のサービスに移行すればいいのです。
最後に宣伝になりますが、当社のBitMailPROは、「個人情報漏洩リスク「ゼロ」の同報メール送信ソフト」として上場IT企業をはじめ多くの企業に採用されている一斉メール送信ソフトです。
30日間機能制限なく無料でお試しいただけますので、ぜひダウンロードしてみてください。
http://www.newsbit.co.jp/software/bmp/index.html
Category: 備忘録
Posted by: Hatchobori
■CSR作成
まずは、CSRの作成手順ですが、結構いろいろと説明しているサイトがあるのですが、どれも微妙に違うところがあってわかりにくかったので、私が実際にやったやり方を記録しておきます。
ちなみに、今回の私の環境は、さくらインターネットのVPSで、CentOS5+Apache2の環境です。
証明書は、RapidSSLでapacheとOpenSSLはインストールしてある状態です。
さて、まずはじめにCSR作成の途中で入力しなければならない次の項目についてあらかじめ準備しておきます。
コモンネーム sample.jp
confまでのパス /etc/httpd/conf/
秘密鍵ファイル名 samplejp.2011.key
秘密鍵ファイル名(パスフレーズ) samplejp.2011_withpass.key
CSRファイル名 samplejp.2011.csr
証明書ファイル samplejp.2011.crt
中間証明書ファイル名 samplejp.2011.cst
CSRディレクトリ /etc/httpd/conf/ssl.csr/
証明書ディレクトリ /etc/httpd/conf/ssl.crt/
パスワード ************
※注意点
コモンネームは、wwwを付けるかつけないかは、悩みどころです。www付でCSRを作成するとhttps://www.sample.jpは当然OKですが、https://sample.jpはNGとなります。
www付のサイトが多いようですが、mixi.jpなどはwwwがついていないようです。
今回、少し悩みましたがURLを短くしたかったので、wwwなしで作成しました。
次に、秘密鍵や証明書、中間証明書のファイル名やディレクトリ名は、わかりやすければ何でも構わないということです。
私は、毎年更新することを考えて、年度を入れていますが、このやり方だと毎年ssl.confなどを聞き替えなければならないので、面倒だと思う方は、年度を入れない方がいいと思います。
準備ができたら、いよいよCSRの作成に入ります。
# CSR用ディレクトリを作成します。
$ mkdir /etc/httpd/conf/ssl.csr/
# CSR用ディレクトリに移動します。
$ cd /etc/httpd/conf/ssl.csr
# キーペア（秘密鍵）の作成（2048bitの秘密鍵）
$ openssl genrsa -des3 2048 > samplejp.2011.key
Generating RSA private key, 2048 bit long modulus
.......+++
...........................................................+++
e is 65537 (0x10001)
Enter pass phrase:************（パスワード入力）
Verifying - Enter pass phrase:************（パスワード入力）
$
# キーペア（秘密鍵）を元にしたCSRの作成
$ openssl req -new -key samplejp.2011.key -out samplejp.2011.csr -sha1
Enter pass phrase for test.key:************（パスワード入力）
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:AAAAA-ku
Organization Name (eg, company) [My Company Ltd]:AAAAAAAA Ltd.（会社名）
Organizational Unit Name (eg, section) []:System（なんでもかまいません）
Common Name (eg, your name or your server's hostname) []:sample.jp
Email Address []:（何も入力せずエンター）
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:（何も入力せずエンター）
An optional company name []:（何も入力せずエンター）
$
※注意事項
Common Nameが間違えていると、再申請になってしまいますので、www付にするかどうかも含めて、間違いが無いようにしてください。
Organizational Unit Nameは、特に神経質になることはなく、何でもいいようです。
キーペア（秘密鍵）にパスワードを埋め込む
$ openssl rsa < samplejp.2011.key > samplejp.2011_withpass.key
Enter pass phrase:************（パスワード入力）
writing RSA key
$
samplejp.2011_withpass.keyが、パスワードの埋め込まれたキーペア（秘密鍵）です。
※パスワードの埋め込まれたキーペア（秘密鍵）を使用すると、 Apacheの起動時にパスワードの入力を省略できます。
これで、CSRの作成は完了なので、問題が無ければ/etc/httpd/conf/ssl.csr/のフォルダに次の3つのファイルが作成されているはずです。
samplejp.2011.csr
samplejp.2011.key
samplejp.2011_withpass.key
# CSRを確認
$ cat samplejp.2011.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICszCCAZsCAQAwbjELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMRAwDgYD
VQQHEwdDaHVvLWt1MRkwFwYDVQQKExBOZXdzYml0IGNvLixsdGQuMQ8wDQYDVQQL
EwZTeXN0ZW0xETAPBgNVBAMTCGZyZWNvLmpwMIIBIjANBgkqhkiG9w0BAQEFAAOC
------中間省略------
4DPqUdTKd9D58MyIPm08U+LtV6nxkEZCet4yV4kQ3TzLEnC9j+c7LcsLV4VjTJ/d
d5JJa3kfTLnBcdVd7dQBG5xFiSsFsD2fTI79sNZjeOotNp9zsDtqj6e3DSh4kmwN
/Of1R6RMwB/FkDUt2qoC1GomFrPidRk=
-----END CERTIFICATE REQUEST-----
最初の-----BEGIN CERTIFICATE REQUEST-----から、最後の-----END CERTIFICATE REQUEST-----までがCSRです。
SSL証明書の申請をして代金を振り込むと、証明書が発行されてきます。
■サーバー証明書のインストール
サーバー証明書が届いたら、さっそくサーバーにインストールです。
# 証明書用ディレクトリを作成します。
$ mkdir /etc/httpd/conf/ssl.crt/
# 証明書用ディレクトリに移動します。
$ cd /etc/httpd/conf/ssl.crt/
# 証明書ファイルを作成し、証明書を貼り付けます。
$ vi samplejp.2011.crt
-----BEGIN CERTIFICATE-----
MIIEuTCCA6GgAwIBAgIDA6x0MA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew
HhcNMTExMDIxMTI1MzEwWhcNMTIxMDIzMDkzMDQwWjCB1zEpMCcGA1UEBRMgakx0
bi96WThRQzFpTG11RWpubk1Ma1ZFaUtkbFlIVEoxCzAJBgNVBAYTAkpQMREwDwYD
------中間省略------
eSjcS4o1K5gTCDnbCJrb1frdjJgpiorkl7TfF65DsNpzk6Qd991zps2aW3UE/iCP
t5dFRErjQqj3zDvFX5t+xnc7q1LBOFgBXHyu/j5i8dZD1nFgWHhSwNg2IYo28VnQ
Sy/zEXFwltUkhhNejie8fRol1fPzMbmwl0s+H76Dq8vD6Wph9Uolqj2OXyX9LV3u
VUfegqE7HQT5UEJ+DgtF6MvQs3+gxf7hCkC0UmmDhGk1Go6srq8CAGSdYz7uKCxE
FEX862xhpiH+VwGoGw==
-----END CERTIFICATE-----
中間証明書は、なくてもいいのかもしれないが、今回は設置することに。
クロスルート対応というものらしく、2ブロックになっているが、全部まとめてファイルに貼り付けます。
# 中間証明書ファイルを作成します。
$ vi samplejp.2011.cst
-----BEGIN CERTIFICATE-----
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTAwMjE5MjI0NTA1WhcNMjAwMjE4MjI0NTA1WjA8MQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOR2VvVHJ1c3QsIEluYy4xFDASBgNVBAMTC1JhcGlkU1NM
------中間省略------
SUNjpWxOJ4cl61tt/qJ/OCjgNqutOaWlYsS3XFgsql0BYKZiZ6PAx2Ij9OdsRu61
04BqIhPSLT90T+qvjF+0OJzbrs6vhB6m9jRRWXnT43XcvNfzc9+S7NIgWW+c+5X4
knYYCnwPLKbK3opie9jzzl9ovY8+wXS7FXI6FoOpC+ZNmZzYV+yoAVHHb1c0XqtK
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw
WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE
------中間省略------
dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB
AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL
NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----
これで、ファイルがすべてそろいました。
ところで、httpsを有効にするためには、apacheだけでなくmod_sslがインストールされている必要があります。
念のため、mod_sslがインストールされているか確認してみます。
$ rpm -qa | grep mod_ssl
mod_ssl-2.2.3-53.el5.centos.3
もし、mod_ssl-2.2.3-53.el5.centos.3というような表示が出なければ、インストールされていないので、下記のコマンドでインストールします。
apacheの再インストールなどは必要なく、下記のコマンドだけでOKです。
$ yum -y install mod_ssl
次は、ssl.confの編集です。
通常は、/etc/httpd/conf.dのフォルダにssl.confというファイルがあるはずですので、このファイルを編集します。
編集するところは、次の3か所で、
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
↓
SSLCertificateKeyFile /etc/httpd/conf/ssl.csr/samplejp.2011_withpass.key
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
↓
SSLCertificateFile /etc/httpd/conf/ssl.crt/samplejp.2011.crt
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
↓
SSLCertificateChainFile /etc/httpd/conf/ssl.crt/samplejp.2011.cst
3か所の修正が終わったら、下記フォルダにあるファイルをchown root:root および chmod 400しておきます。
/etc/httpd/conf/ssl.csr/
/etc/httpd/conf/ssl.crt/
最後にapacheの再起動
/etc/rc.d/init.d/httpd restart
これで、https://sample.jpがブラウザで鍵がついて表示されるはずです。
まずは、CSRの作成手順ですが、結構いろいろと説明しているサイトがあるのですが、どれも微妙に違うところがあってわかりにくかったので、私が実際にやったやり方を記録しておきます。
ちなみに、今回の私の環境は、さくらインターネットのVPSで、CentOS5+Apache2の環境です。
証明書は、RapidSSLでapacheとOpenSSLはインストールしてある状態です。
さて、まずはじめにCSR作成の途中で入力しなければならない次の項目についてあらかじめ準備しておきます。
コモンネーム sample.jp
confまでのパス /etc/httpd/conf/
秘密鍵ファイル名 samplejp.2011.key
秘密鍵ファイル名(パスフレーズ) samplejp.2011_withpass.key
CSRファイル名 samplejp.2011.csr
証明書ファイル samplejp.2011.crt
中間証明書ファイル名 samplejp.2011.cst
CSRディレクトリ /etc/httpd/conf/ssl.csr/
証明書ディレクトリ /etc/httpd/conf/ssl.crt/
パスワード ************
※注意点
コモンネームは、wwwを付けるかつけないかは、悩みどころです。www付でCSRを作成するとhttps://www.sample.jpは当然OKですが、https://sample.jpはNGとなります。
www付のサイトが多いようですが、mixi.jpなどはwwwがついていないようです。
今回、少し悩みましたがURLを短くしたかったので、wwwなしで作成しました。
次に、秘密鍵や証明書、中間証明書のファイル名やディレクトリ名は、わかりやすければ何でも構わないということです。
私は、毎年更新することを考えて、年度を入れていますが、このやり方だと毎年ssl.confなどを聞き替えなければならないので、面倒だと思う方は、年度を入れない方がいいと思います。
準備ができたら、いよいよCSRの作成に入ります。
# CSR用ディレクトリを作成します。
$ mkdir /etc/httpd/conf/ssl.csr/
# CSR用ディレクトリに移動します。
$ cd /etc/httpd/conf/ssl.csr
# キーペア（秘密鍵）の作成（2048bitの秘密鍵）
$ openssl genrsa -des3 2048 > samplejp.2011.key
Generating RSA private key, 2048 bit long modulus
.......+++
...........................................................+++
e is 65537 (0x10001)
Enter pass phrase:************（パスワード入力）
Verifying - Enter pass phrase:************（パスワード入力）
$
# キーペア（秘密鍵）を元にしたCSRの作成
$ openssl req -new -key samplejp.2011.key -out samplejp.2011.csr -sha1
Enter pass phrase for test.key:************（パスワード入力）
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:AAAAA-ku
Organization Name (eg, company) [My Company Ltd]:AAAAAAAA Ltd.（会社名）
Organizational Unit Name (eg, section) []:System（なんでもかまいません）
Common Name (eg, your name or your server's hostname) []:sample.jp
Email Address []:（何も入力せずエンター）
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:（何も入力せずエンター）
An optional company name []:（何も入力せずエンター）
$
※注意事項
Common Nameが間違えていると、再申請になってしまいますので、www付にするかどうかも含めて、間違いが無いようにしてください。
Organizational Unit Nameは、特に神経質になることはなく、何でもいいようです。
キーペア（秘密鍵）にパスワードを埋め込む
$ openssl rsa < samplejp.2011.key > samplejp.2011_withpass.key
Enter pass phrase:************（パスワード入力）
writing RSA key
$
samplejp.2011_withpass.keyが、パスワードの埋め込まれたキーペア（秘密鍵）です。
※パスワードの埋め込まれたキーペア（秘密鍵）を使用すると、 Apacheの起動時にパスワードの入力を省略できます。
これで、CSRの作成は完了なので、問題が無ければ/etc/httpd/conf/ssl.csr/のフォルダに次の3つのファイルが作成されているはずです。
samplejp.2011.csr
samplejp.2011.key
samplejp.2011_withpass.key
# CSRを確認
$ cat samplejp.2011.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICszCCAZsCAQAwbjELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMRAwDgYD
VQQHEwdDaHVvLWt1MRkwFwYDVQQKExBOZXdzYml0IGNvLixsdGQuMQ8wDQYDVQQL
EwZTeXN0ZW0xETAPBgNVBAMTCGZyZWNvLmpwMIIBIjANBgkqhkiG9w0BAQEFAAOC
------中間省略------
4DPqUdTKd9D58MyIPm08U+LtV6nxkEZCet4yV4kQ3TzLEnC9j+c7LcsLV4VjTJ/d
d5JJa3kfTLnBcdVd7dQBG5xFiSsFsD2fTI79sNZjeOotNp9zsDtqj6e3DSh4kmwN
/Of1R6RMwB/FkDUt2qoC1GomFrPidRk=
-----END CERTIFICATE REQUEST-----
最初の-----BEGIN CERTIFICATE REQUEST-----から、最後の-----END CERTIFICATE REQUEST-----までがCSRです。
SSL証明書の申請をして代金を振り込むと、証明書が発行されてきます。
■サーバー証明書のインストール
サーバー証明書が届いたら、さっそくサーバーにインストールです。
# 証明書用ディレクトリを作成します。
$ mkdir /etc/httpd/conf/ssl.crt/
# 証明書用ディレクトリに移動します。
$ cd /etc/httpd/conf/ssl.crt/
# 証明書ファイルを作成し、証明書を貼り付けます。
$ vi samplejp.2011.crt
-----BEGIN CERTIFICATE-----
MIIEuTCCA6GgAwIBAgIDA6x0MA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew
HhcNMTExMDIxMTI1MzEwWhcNMTIxMDIzMDkzMDQwWjCB1zEpMCcGA1UEBRMgakx0
bi96WThRQzFpTG11RWpubk1Ma1ZFaUtkbFlIVEoxCzAJBgNVBAYTAkpQMREwDwYD
------中間省略------
eSjcS4o1K5gTCDnbCJrb1frdjJgpiorkl7TfF65DsNpzk6Qd991zps2aW3UE/iCP
t5dFRErjQqj3zDvFX5t+xnc7q1LBOFgBXHyu/j5i8dZD1nFgWHhSwNg2IYo28VnQ
Sy/zEXFwltUkhhNejie8fRol1fPzMbmwl0s+H76Dq8vD6Wph9Uolqj2OXyX9LV3u
VUfegqE7HQT5UEJ+DgtF6MvQs3+gxf7hCkC0UmmDhGk1Go6srq8CAGSdYz7uKCxE
FEX862xhpiH+VwGoGw==
-----END CERTIFICATE-----
中間証明書は、なくてもいいのかもしれないが、今回は設置することに。
クロスルート対応というものらしく、2ブロックになっているが、全部まとめてファイルに貼り付けます。
# 中間証明書ファイルを作成します。
$ vi samplejp.2011.cst
-----BEGIN CERTIFICATE-----
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTAwMjE5MjI0NTA1WhcNMjAwMjE4MjI0NTA1WjA8MQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOR2VvVHJ1c3QsIEluYy4xFDASBgNVBAMTC1JhcGlkU1NM
------中間省略------
SUNjpWxOJ4cl61tt/qJ/OCjgNqutOaWlYsS3XFgsql0BYKZiZ6PAx2Ij9OdsRu61
04BqIhPSLT90T+qvjF+0OJzbrs6vhB6m9jRRWXnT43XcvNfzc9+S7NIgWW+c+5X4
knYYCnwPLKbK3opie9jzzl9ovY8+wXS7FXI6FoOpC+ZNmZzYV+yoAVHHb1c0XqtK
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw
WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE
------中間省略------
dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB
AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL
NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----
これで、ファイルがすべてそろいました。
ところで、httpsを有効にするためには、apacheだけでなくmod_sslがインストールされている必要があります。
念のため、mod_sslがインストールされているか確認してみます。
$ rpm -qa | grep mod_ssl
mod_ssl-2.2.3-53.el5.centos.3
もし、mod_ssl-2.2.3-53.el5.centos.3というような表示が出なければ、インストールされていないので、下記のコマンドでインストールします。
apacheの再インストールなどは必要なく、下記のコマンドだけでOKです。
$ yum -y install mod_ssl
次は、ssl.confの編集です。
通常は、/etc/httpd/conf.dのフォルダにssl.confというファイルがあるはずですので、このファイルを編集します。
編集するところは、次の3か所で、
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
↓
SSLCertificateKeyFile /etc/httpd/conf/ssl.csr/samplejp.2011_withpass.key
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
↓
SSLCertificateFile /etc/httpd/conf/ssl.crt/samplejp.2011.crt
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
↓
SSLCertificateChainFile /etc/httpd/conf/ssl.crt/samplejp.2011.cst
3か所の修正が終わったら、下記フォルダにあるファイルをchown root:root および chmod 400しておきます。
/etc/httpd/conf/ssl.csr/
/etc/httpd/conf/ssl.crt/
最後にapacheの再起動
/etc/rc.d/init.d/httpd restart
これで、https://sample.jpがブラウザで鍵がついて表示されるはずです。
10/14: スパムメールと判断されないための注意点
Category: 備忘録
Posted by: Hatchobori
メールを送ったのに、相手から「届いていない」と言われた経験は誰でも一度や二度はあると思います。
念のためスパムフォルダを見てもらうとそこにあったりします。
これを完全に防止することは難しいのですが、スパム扱いされにくくすることは可能です。
メールを送信するときに次の点に注意するのです。
1.「こんにちは」「お世話になります」 「ありがとうございました」など本物のスパムメールに使われそうな件名を使わない
2.本文内に必要以上にリンクを張らない
3.本文にスパムに使われるような単語をできるだけ使用しない
4.本文や件名を空で送らない
5.フリーのメールドレスを使わない
6.HTML形式ではなくテキスト形式とする
7.署名をつける
8.送信者名（差出人）に英語ではなく日本語を使用する
9.doc、xls 、exeなどのファイルを添付するときは、zipやlzhで圧縮する。
ビジネスメールで、メールが確実に届かないということになると信用問題にもなりますので、できるだけスパムメール扱いされない工夫をして送信することは大切なことです。
また、よくメールをやり取りする方のメールについては、ホワイトリストに登録してスパムと判断されないようにすることをお勧めします。
念のためスパムフォルダを見てもらうとそこにあったりします。
これを完全に防止することは難しいのですが、スパム扱いされにくくすることは可能です。
メールを送信するときに次の点に注意するのです。
1.「こんにちは」「お世話になります」 「ありがとうございました」など本物のスパムメールに使われそうな件名を使わない
2.本文内に必要以上にリンクを張らない
3.本文にスパムに使われるような単語をできるだけ使用しない
4.本文や件名を空で送らない
5.フリーのメールドレスを使わない
6.HTML形式ではなくテキスト形式とする
7.署名をつける
8.送信者名（差出人）に英語ではなく日本語を使用する
9.doc、xls 、exeなどのファイルを添付するときは、zipやlzhで圧縮する。
ビジネスメールで、メールが確実に届かないということになると信用問題にもなりますので、できるだけスパムメール扱いされない工夫をして送信することは大切なことです。
また、よくメールをやり取りする方のメールについては、ホワイトリストに登録してスパムと判断されないようにすることをお勧めします。
10/13: ホームページの各ページにページ番号を付ける
Category: 仕事
Posted by: Hatchobori
携帯サイトやスマホ用のサイトは、トップページでそれほど多くのメニューやボタンを設けられませんので、どうしても階層が深くなりがちです。
そのため、最初にクリックするところ、つまり、入り口を間違えるとなかなか見たいページにたどり着くことができません。
たとえば、ファミリーレストランなどで会員登録する場合など空メールの自動返信を受信できるようにするために、ドメインを登録することがあると思いますが、メニューから何度もクリックしないとドメインを指定する画面にたどり着かないので、いつも悩みます。
頻繁に設定するものではないので、操作手順がわからなくなってしまうのです。
ドメインの登録画面については、パケットがかからないとしても、一般のページだとしたら大変です。
パケ放題に入っているので、いくら無駄にアクセスしても平気という考え方もできますが、無駄な時間がかかります。また、パケ放題に入ってない人にとっては通信費が高くなりますし、悩まずに進めたとしても途中のページのパケット代が無駄になります。
多くの方が大量のデータをやり取りすれば、回線がパンク状態になる可能性も高くなるのです。
そうした問題を解決するには、やはりページ番号ではないかと思うのです。
ページ番号を入れればどんなに深い階層のページでもダイレクトにアクセスできるようになりますし、トップページには、番号の入力数ボックスとボタンがあればいいだけなので、すっきりしたデザインにすることもできます。
各ページにもページ番号のシステムを入れておけば、いちいちトップページに戻らなくても次のページに遷移することもできるようになります。
どうでしょう。かなり、便利になると思うのですがいかがでしょう？
これから携帯サイトやスマホサイトを作るご予定の方は、ぜひご検討ください。
もちろん、すでにあるページに利用することもできます。
W3Nのページ
http://www.w3navi.com/
そのため、最初にクリックするところ、つまり、入り口を間違えるとなかなか見たいページにたどり着くことができません。
たとえば、ファミリーレストランなどで会員登録する場合など空メールの自動返信を受信できるようにするために、ドメインを登録することがあると思いますが、メニューから何度もクリックしないとドメインを指定する画面にたどり着かないので、いつも悩みます。
頻繁に設定するものではないので、操作手順がわからなくなってしまうのです。
ドメインの登録画面については、パケットがかからないとしても、一般のページだとしたら大変です。
パケ放題に入っているので、いくら無駄にアクセスしても平気という考え方もできますが、無駄な時間がかかります。また、パケ放題に入ってない人にとっては通信費が高くなりますし、悩まずに進めたとしても途中のページのパケット代が無駄になります。
多くの方が大量のデータをやり取りすれば、回線がパンク状態になる可能性も高くなるのです。
そうした問題を解決するには、やはりページ番号ではないかと思うのです。
ページ番号を入れればどんなに深い階層のページでもダイレクトにアクセスできるようになりますし、トップページには、番号の入力数ボックスとボタンがあればいいだけなので、すっきりしたデザインにすることもできます。
各ページにもページ番号のシステムを入れておけば、いちいちトップページに戻らなくても次のページに遷移することもできるようになります。
どうでしょう。かなり、便利になると思うのですがいかがでしょう？
これから携帯サイトやスマホサイトを作るご予定の方は、ぜひご検討ください。
もちろん、すでにあるページに利用することもできます。
W3Nのページ
http://www.w3navi.com/
06/01: DSJ2011（デジタルサイネージ）について
Category: 仕事
Posted by: Hatchobori
DSJ2011（デジタルサイネージ）が6月8日～10日で幕張メッセで開催されますが、2011年6月10日（金）の14:40-16:10の専門コンファレンスでマンション管理組合専用WEBシステム「マンボー」について講演することになりました。
http://www.f2ff.jp/dsj/conference/index.html
http://www.f2ff.jp/dsj/conference/index.html
04/08: 緊急連絡（生徒や保護者から学校への連絡）
Category: 余談
Posted by: Hatchobori
緊急連絡は、学校から生徒や保護者に向けて発信するものと考えがちですが、安否の確認を必要とするような大規模な災害時には、生徒や保護者から無事を学校に知らせる方法をあらかじめ決めておくという方法もあります。
学校からメールを送ってそれに対して返信してもらうのではなく、学校からの連絡の有無にかかわらず生徒や保護者から学校へ連絡するのです。
特に、緊急連絡をメールで行う場合には、電話による連絡網と違いメールが確実に届いて連絡が伝わったのかどうかがわかりません。
そのため、メールを受信した生徒や保護者はメールを見たら学校に返信するなど何らかのアクションを起こす必要があるのです。
しかし、大規模災害時はただでさえ通信網は混雑しメールを送っても遅延等が発生する可能性もあります。その上、その返信を待つのでは連絡が取れるまでにかなり時間がかかる可能性もあるのです。
そこで、学校であらかじめ緊急時の連絡先メールアドレスを用意しておき、大規模な災害発生時にはそのアドレスに生徒や保護者が安否の連絡をするのです。
そうすることで、災害発生直後に生徒や保護者から安否の連絡メールが届くことになり学校ではいち早く安否状況を確認できるようになります。
もちろん、ただ単に送られてきたメールを通常のメーラー（たとえば、Outlook等）で受信したのでは、生徒や保護者の特定が困難で照合等の作業が非常に混乱する可能性があります。
また、件名や本文にきちんとした情報が記載されていない可能性もあり、緊急時ということも考えると空メールでも発信者の特定ができなければなりません。
そう考えると、どんなメールにも必ずあるメールのヘッダーのFromからメールの送信者のメールアドレスを取得し、あらかじめ学校側で登録しておいた生徒や保護者のデータベースのメールアドレスリストと照合し、誰から連絡が来て、誰からまだ連絡が来ていないのかがリアルタイムでわかるようにする必要があるのです。
では、実際どのようにすればいいかということになりすが、当社が無料提供している教育機関向け緊急連絡用データベース「bmpSchool」に生徒や保護者などのメールアドレスをあらかじめ登録しておいて、はやり当社のBitplusPROという受信専用の特殊機能メーラーでメールを受信すれば、簡単に誰のアドレスからメールが届いたのかをチェックすることができます。
もちろん、今回ご紹介したこの方法で、すべての生徒や保護者の安否確認ができるとは限りません。
メールを送信できない状況にあるかもしれませんし、学校に連絡するのを忘れてしまうかもしれません。メールアドレスがわからなくなってしまう場合もあるでしょう。
ただ、災害時における安否確認をよりスピーディにおこなえる確率は高くなりますので、検討してみる価値はあると思います。
学校からメールを送ってそれに対して返信してもらうのではなく、学校からの連絡の有無にかかわらず生徒や保護者から学校へ連絡するのです。
特に、緊急連絡をメールで行う場合には、電話による連絡網と違いメールが確実に届いて連絡が伝わったのかどうかがわかりません。
そのため、メールを受信した生徒や保護者はメールを見たら学校に返信するなど何らかのアクションを起こす必要があるのです。
しかし、大規模災害時はただでさえ通信網は混雑しメールを送っても遅延等が発生する可能性もあります。その上、その返信を待つのでは連絡が取れるまでにかなり時間がかかる可能性もあるのです。
そこで、学校であらかじめ緊急時の連絡先メールアドレスを用意しておき、大規模な災害発生時にはそのアドレスに生徒や保護者が安否の連絡をするのです。
そうすることで、災害発生直後に生徒や保護者から安否の連絡メールが届くことになり学校ではいち早く安否状況を確認できるようになります。
もちろん、ただ単に送られてきたメールを通常のメーラー（たとえば、Outlook等）で受信したのでは、生徒や保護者の特定が困難で照合等の作業が非常に混乱する可能性があります。
また、件名や本文にきちんとした情報が記載されていない可能性もあり、緊急時ということも考えると空メールでも発信者の特定ができなければなりません。
そう考えると、どんなメールにも必ずあるメールのヘッダーのFromからメールの送信者のメールアドレスを取得し、あらかじめ学校側で登録しておいた生徒や保護者のデータベースのメールアドレスリストと照合し、誰から連絡が来て、誰からまだ連絡が来ていないのかがリアルタイムでわかるようにする必要があるのです。
では、実際どのようにすればいいかということになりすが、当社が無料提供している教育機関向け緊急連絡用データベース「bmpSchool」に生徒や保護者などのメールアドレスをあらかじめ登録しておいて、はやり当社のBitplusPROという受信専用の特殊機能メーラーでメールを受信すれば、簡単に誰のアドレスからメールが届いたのかをチェックすることができます。
もちろん、今回ご紹介したこの方法で、すべての生徒や保護者の安否確認ができるとは限りません。
メールを送信できない状況にあるかもしれませんし、学校に連絡するのを忘れてしまうかもしれません。メールアドレスがわからなくなってしまう場合もあるでしょう。
ただ、災害時における安否確認をよりスピーディにおこなえる確率は高くなりますので、検討してみる価値はあると思います。
04/07: 緊急連絡の仕組みの二重化（冗長化）について
Category: 余談
Posted by: Hatchobori
東日本大震災を経験して、緊急連絡について改めて検討されている教育機関も多いことと思います。
もちろん、すでに緊急連絡のシステムを導入している教育機関もあると思いますが、本当に万全なのかをいま一度考えてみるよい機会ではないでしょうか。
たとえば、今回の福島第一原発の事故でも東京電力は津波の被害を受けた時のトラブルは想定していましたが、それ以上の津波が押し寄せてきたことにより想定以上のダメージを受け今回のような状況になっているのです。
つまり、往々にして「想定外」のことが起きるわけで、想定どおりにならなかった時のことを考えておくことが重要なのです。
とくに、児童や生徒を預かる教育機関では、緊急連絡のシステムが何らかの原因で利用できず児童や生徒が災害に巻き込まれるようなことにでもなれば一大事です。
そう考えると、緊急連絡の方法を準備しておくのは当然で、できれば複数用意して万一の場合に備えることが大切ではないでしょうか。
「そこまでしなくても」と考える方もいるかとは思いますが、人命にかかわることは「想定外でした」で済まされないのです。
まして、ASPのサービス提供会社に責任転嫁しても何の解決にもなりません。
東日本大震災での被災地では固定電話が通じない、基地局が被害を受けたことで携帯電話や携帯メールもつながらないという最悪の状態、つまり、完全に外部との連絡を絶たれた孤立状態になった地域もあります。
そこまで最悪の状況になれば別ですが、東京などでも固定電話も携帯電話もつながらない、携帯メールもなかなか届かないという状況でした。
そうした中でも、インターネットに接続できさえすれば、パソコンのメールやTwitter、Facebook、ミクシィ等のサービスを利用することも可能なのです。
つまり、インターネットに接続できる方法を確保することは非常に重要な危機対策といえるのです。
バッテリーで使えるノートパソコンやスマートフォンなど携帯端末があり、インターネットに接続できれば、なんとか外部と連絡が取れる可能性があるからです。
そのためにもインターネットに接続できる機器を準備することとだけでなく、インターネットに接続するためのプロバイダーなどを複数確保しておくことなど万一の場合に備えておく必要があるのです。
話を緊急連絡に戻しますが、緊急連絡のシステムは、ASPタイプやソフトウェアタイプがあります。
ASPタイプの緊急連絡システムの多くは、サービス提供会社のサーバーに連絡先のアドレス等をあらかじめ登録しておいて、それを外部のパソコンや携帯電話などから操作してメールを送信するものです。
このタイプは、サービス提供会社のサーバーが災害時に正常に稼働していることが大前提となります。サーバーにアクセスが集中し処理が遅れたり、サーバーがダウンしてしまうようなことにでもなれば利用できなくなりますので、ある程度の規模の会社が提供するサービスを選ぶ必要があるでしょう。
ただ、先日のみずほ銀行のシステムトラブルをみてもわかるように、どんなシステムでもトラブルの可能性はあることだけは理解しておく必要があります。
一方、ソフトウェアタイプもパソコンにソフトをインストールして使用することになるため、そのパソコンが故障してしまったり、パソコンを操作できる人がいない状態だと使用することができません。
つまり、どちらのタイプも100%どんな時でもどんな状況でも利用できるという保証はないので、万一の場合に備えて複数の緊急連絡方法を準備しておく必要があるのです。
まだ、緊急連絡の仕組みを準備していないという場合は、コスト的にも安いソフトウェアタイプでもいいのですぐにでも導入すべきですし、ASPタイプをすでに導入している場合でもソフトウェアタイプをバックアップ（予備）として用意することを検討してみてはいかがでしょう。
もちろん、すでに緊急連絡のシステムを導入している教育機関もあると思いますが、本当に万全なのかをいま一度考えてみるよい機会ではないでしょうか。
たとえば、今回の福島第一原発の事故でも東京電力は津波の被害を受けた時のトラブルは想定していましたが、それ以上の津波が押し寄せてきたことにより想定以上のダメージを受け今回のような状況になっているのです。
つまり、往々にして「想定外」のことが起きるわけで、想定どおりにならなかった時のことを考えておくことが重要なのです。
とくに、児童や生徒を預かる教育機関では、緊急連絡のシステムが何らかの原因で利用できず児童や生徒が災害に巻き込まれるようなことにでもなれば一大事です。
そう考えると、緊急連絡の方法を準備しておくのは当然で、できれば複数用意して万一の場合に備えることが大切ではないでしょうか。
「そこまでしなくても」と考える方もいるかとは思いますが、人命にかかわることは「想定外でした」で済まされないのです。
まして、ASPのサービス提供会社に責任転嫁しても何の解決にもなりません。
東日本大震災での被災地では固定電話が通じない、基地局が被害を受けたことで携帯電話や携帯メールもつながらないという最悪の状態、つまり、完全に外部との連絡を絶たれた孤立状態になった地域もあります。
そこまで最悪の状況になれば別ですが、東京などでも固定電話も携帯電話もつながらない、携帯メールもなかなか届かないという状況でした。
そうした中でも、インターネットに接続できさえすれば、パソコンのメールやTwitter、Facebook、ミクシィ等のサービスを利用することも可能なのです。
つまり、インターネットに接続できる方法を確保することは非常に重要な危機対策といえるのです。
バッテリーで使えるノートパソコンやスマートフォンなど携帯端末があり、インターネットに接続できれば、なんとか外部と連絡が取れる可能性があるからです。
そのためにもインターネットに接続できる機器を準備することとだけでなく、インターネットに接続するためのプロバイダーなどを複数確保しておくことなど万一の場合に備えておく必要があるのです。
話を緊急連絡に戻しますが、緊急連絡のシステムは、ASPタイプやソフトウェアタイプがあります。
ASPタイプの緊急連絡システムの多くは、サービス提供会社のサーバーに連絡先のアドレス等をあらかじめ登録しておいて、それを外部のパソコンや携帯電話などから操作してメールを送信するものです。
このタイプは、サービス提供会社のサーバーが災害時に正常に稼働していることが大前提となります。サーバーにアクセスが集中し処理が遅れたり、サーバーがダウンしてしまうようなことにでもなれば利用できなくなりますので、ある程度の規模の会社が提供するサービスを選ぶ必要があるでしょう。
ただ、先日のみずほ銀行のシステムトラブルをみてもわかるように、どんなシステムでもトラブルの可能性はあることだけは理解しておく必要があります。
一方、ソフトウェアタイプもパソコンにソフトをインストールして使用することになるため、そのパソコンが故障してしまったり、パソコンを操作できる人がいない状態だと使用することができません。
つまり、どちらのタイプも100%どんな時でもどんな状況でも利用できるという保証はないので、万一の場合に備えて複数の緊急連絡方法を準備しておく必要があるのです。
まだ、緊急連絡の仕組みを準備していないという場合は、コスト的にも安いソフトウェアタイプでもいいのですぐにでも導入すべきですし、ASPタイプをすでに導入している場合でもソフトウェアタイプをバックアップ（予備）として用意することを検討してみてはいかがでしょう。
Category: 仕事
Posted by: Hatchobori
レストラン専用顧客管理「PLATRANT」のFacebookページも開設しました。
レストラン専用ということで他の業種では使いにくいかもしれませんが、レストランで管理したい項目をまとめました。
すでに、有名レストランでもご利用いただいているソフトで、今後、皆様のご要望を反映して改良していきたいと考えています。
ぜひ、ご興味のある方は、「いいね!」をお願いします。
「PLATRANT」のFacebookページ
レストラン専用ということで他の業種では使いにくいかもしれませんが、レストランで管理したい項目をまとめました。
すでに、有名レストランでもご利用いただいているソフトで、今後、皆様のご要望を反映して改良していきたいと考えています。
ぜひ、ご興味のある方は、「いいね!」をお願いします。
「PLATRANT」のFacebookページ
Category: 仕事
Posted by: Hatchobori
通販管理ソフト「RODB」のFacebookページを開設しました。
内容は、今後充実させていきますが、皆様との情報交換などに活用したいと考えています。
ぜひ、「いいね！」をお願いします。
「RODB」のFacebookページ
内容は、今後充実させていきますが、皆様との情報交換などに活用したいと考えています。
ぜひ、「いいね！」をお願いします。
「RODB」のFacebookページ
03/21: 緊急連絡についての補足
Category: 余談
Posted by: Hatchobori
先日の緊急連絡や災害用伝言板についての補足です。
まず、緊急連絡で携帯電話のメールを使用する場合ですが、受信者が何もしないとメールが届いたとしてもかなり遅れてしまいます。
せっかく送ったメールがタイミングよく届かないのでは役に立ちません。これを回避するには、受信者がただ待っているのではなく「センター問い合わせ」等の新着メールの確認を行う必要があるようです。
ただし、状況としてはキャリアのメールサーバーにかなり負荷がかかっているためにメールの遅延が生じているわけですから、多くの人が何度も新着メールの確認を行うとその分サーバーの負荷が増えてしまうという結果になりかねません。
ある程度間隔をおいて問い合わせするように心がけましょう。
次に、災害用伝言板ですが、音声通話が困難でメールも送れないという状況には非常に便利なサービスですが、問題もあります。
それは、災害用伝言板にメッセージを登録できるのは「災害が発生した地域」に限られるということです。
つまり、あなたの居る場所が「災害が発生した地域」として指定されなければ、利用できないことになり、今回の震災でも当初は指定されないことで利用できなかなった地域があったようです。
NTT東日本、NTT西日本が提供している災害用伝言ダイヤル（171）および災害用ブロードバンド伝言板（web171）も、「災害が発生した地域」や「災害により電話がかかりにくくなっている地域」が対象ですから、指定区域外となっている間は、利用できないことになります。
まず、緊急連絡で携帯電話のメールを使用する場合ですが、受信者が何もしないとメールが届いたとしてもかなり遅れてしまいます。
せっかく送ったメールがタイミングよく届かないのでは役に立ちません。これを回避するには、受信者がただ待っているのではなく「センター問い合わせ」等の新着メールの確認を行う必要があるようです。
ただし、状況としてはキャリアのメールサーバーにかなり負荷がかかっているためにメールの遅延が生じているわけですから、多くの人が何度も新着メールの確認を行うとその分サーバーの負荷が増えてしまうという結果になりかねません。
ある程度間隔をおいて問い合わせするように心がけましょう。
次に、災害用伝言板ですが、音声通話が困難でメールも送れないという状況には非常に便利なサービスですが、問題もあります。
それは、災害用伝言板にメッセージを登録できるのは「災害が発生した地域」に限られるということです。
つまり、あなたの居る場所が「災害が発生した地域」として指定されなければ、利用できないことになり、今回の震災でも当初は指定されないことで利用できなかなった地域があったようです。
NTT東日本、NTT西日本が提供している災害用伝言ダイヤル（171）および災害用ブロードバンド伝言板（web171）も、「災害が発生した地域」や「災害により電話がかかりにくくなっている地域」が対象ですから、指定区域外となっている間は、利用できないことになります。
