Page Top
Page Top

情報システム関連

 

Indeed で知られる「ジョブプロジェクト株式会社」を遮断

2018年11月05日

「製品についてのお問い合わせ」フォームに、許可無くメルマガを送り付ける違法行為を行った為。
特定電子メール法違反で、関係省庁に通報を行いました。
下記ドメインについて、拒否リストへ投入しました。
job-project.com を遮断。
indeed.com を遮断。
メルマガ配信に使われているドメイン itm-asp.com の envelope を禁止。

光コラボの迷惑電話番号を遮断

2018年01月15日

080-0300-4401。当社はフレッツ光を利用していないにもかかわらず、何度もしつこく電話してくる為。古い名簿業者から情報を買ったと思われる。

ヴィッテンシュタイン・ターナリー株式会社との通信を遮断

2017年03月30日

ヴィッテンシュタイン・ターナリー株式会社
ドメイン wittenstein-ternary.jp を遮断した。

理由:許可無く、未承諾広告を送信した為。

株式会社システムインテグレータとの通信を遮断

2017年01月26日

株式会社システムインテグレータ
〒330-6032 埼玉県さいたま市中央区新都心11番地2
ランド・アクシス・タワー(明治安田生命さいたま新都心ビル)32階

上記の者は、個人情報保護法および特定電子メール法に違反する行為を二度にわたって行った。
よって、ドメイン sint.co.jp を、社内のDNSから遮断すると共に、メールのフィルタリングに登録し、当該ドメインからのメールを直ちに削除する対応をサーバー側で行った。
以後のやり取りは、電話、FAX、郵送等を通じて行う事。

www.nitsuki.com から nitsuki.com 表記へ

2016年08月05日

 一般的な公開ページであっても、https (セキュア) 接続が重視される様になった事を受け、従前「www. あり」になっていた URL 表記を、「www. なし」に変更します。
 サーバー側でリダイレクト(転送)を行いますので、利用者様は何もしなくて結構です。
 当社のサーバーは、電子証明書の制限から、「nitsuki.com」以外のサブドメインを利用出来ません。この為、セキュア接続を実現するには、https://nitsuki.com を使わざるを得ません。
 この為、通常の接続も、「www. なし」に方針変更します。

MSのブラウザ乗っ取りへの対抗措置として、社内DNSでMSNを遮断

2016年04月13日


Internet Explorer 11の新たな保護と称して、トップページをMSNやマイクロソフトの検索に勝手に書き換える、悪質な初期画面が出て来たかと思います。この行為を、当社では独占企業による「乗っ取り行為」と解釈しました。よって、下記のドメインへの社内からの接続を遮断しました。


 当該画面は出来が悪く、「標準ユーザー」で動作している環境で、OKボタンが押せない事例が出ました。現状のままにチェックをして Enter したにもかかわらず、「マイクロソフトに書き換えます」が優先する形で乗っ取られました。
 この様な形で表示されたサイトで、MSが利益が上げる事が無い様、遮断します。

 マイクロソフトの検索エンジン bing も、アドオンから削除する事を推奨します。追加の検索エンジンは手動で https://www.microsoft.com/ja-jp/iegallery へ行けば、入手出来ます。同・解説はこちら です。

 Googleリモートデスクトップや、TeamViewer等、ファイアーウォールに穴を開ける迷惑なソフトを遮断するには、DNSサーバーを内部で構築して、ルーターの標準設定とし、接続させたくないドメインを、内部(localhost) に強制コールバックして、外に出て行けない様にする必要があります。近年、市場を独占するソフトウェア企業による、違法まがいの問題行為が目立っている印象があり、異例ですが、対抗措置をとる事にしました。

 Google Chrome もリフレッシュ直後の Windows 7 でレジストリを破壊し、再インストールを余儀なくされる等、動作速度はともかく、長期の検証が不十分です。今後、社内の標準ブラウザーは、Firefox に一本化します。「ユーザーが望まない機能」を確実に止める事が出来るので、結果的に安全性が高まります。それ以外のブラウザーの利用は、入札やEB等、IEでしか動かない場合を除き、避けて下さい。
 go.microsoft.com (リダイレクト) も当分遮断し、IEの社内利用から距離を置く様にします。

迷惑メールフィルターのSPFレコード解釈に、一部不具合が発生していました

2013年07月19日。2013年12月18日 加筆修正

 弊社の電子メール・サービスには、前段に「迷惑メールフィルタリング・サーバー」が搭載されています。可否判定の1つに、送信元DNSサーバーの「SPFレコード」記述を利用していますが、この部分のプログラムに、導入当初から、ある不具合が発生していた事が判明しました。
 得意先の茨城大学様より、「送信したメールが、(弊社に) 届かない」と連絡があり、2013年05月末頃に発覚。当初はサーバーの設定ミスか、相性問題と思われていましたが、互いのサーバー提供先同士で接続テストを行った結果、「迷惑メールフィルター」の判定プログラムにミスがある事が判明。2013年06月21日に修正され、以降は正しく処理される様になりました。


弊社にメールを送信する方が、加入しているプロバイダーの、DNSサービスの記述に依る:
  • Windowsの場合の確認方法:
    コマンドプロンプトで、nslookup -q=txt 送信サーバー名

  • Linuxの場合の確認方法:
    コマンドライン・ターミナルで、dig -t TXT 送信サーバー名


起きていた現象:
 SPFレコード記述に「+ の限定子」を持つ IPv6 記述が存在していた場合 (「+ip6」の記述があった場合)、迷惑メールフィルター側のプログラム・ミスにより正常な処理が出来ず、正しい IPv6 アドレスであるにも係わらずエラーとなっていました。この結果、「-all」でハードフェイル (Hard Fail) 設定をしていた場合、弊社宛のメールが一切届かなかったとの事です。


2013年06月20日以前 (2009年のサービス開始より)

※下記はいずれも正しい記述であり、不達原因はあくまで当方ホスティングの不具合です。

"v=spf1 +ip6:(IPv6アドレス) -all"(不達) 正しい送信元でも送信出来ませんでした
"v=spf1 +ip6:(IPv6アドレス) ~all"(セーフ) 正しく処理できず、送信元判定はエラーになりますが、エラーでも送信を許可する「~all」に救われ、送信は可能でした
"v=spf1 ip6:(IPv6アドレス) -all"(成功) 正しく処理され、送信可能でした
"v=spf1 +ip4:(IPv4アドレス) -all"(成功) 正しく処理され、送信可能でした
"v=spf1 ip4:(IPv4アドレス) -all"(成功) 正しく処理され、送信可能でした

現在 (2013年06月21日以降)

"v=spf1 +ip6:(IPv6アドレス) -all"(成功) 正しく処理され、送信可能です
"v=spf1 +ip6:(IPv6アドレス) ~all"(成功) 正しく処理され、送信可能です
"v=spf1 ip6:(IPv6アドレス) -all"(成功) 正しく処理され、送信可能です
"v=spf1 +ip4:(IPv4アドレス) -all"(成功) 正しく処理され、送信可能です
"v=spf1 ip4:(IPv4アドレス) -all"(成功) 正しく処理され、送信可能です


 発生期間は、2009年のサービス開始から、2013年06月20日までと、かなりの長期に亘ります。それ以後は、解消しております。この間、弊社宛に送ったメールで、上記例に該当する物は、弊社には到着していません。接続自体が失敗する形になる為、ログも全く残りません。


推定される発生件数は、ごく少数:
 コンテンツ配信サービスの世界では着々と導入が進む IPv6 ですが、既存の IPv4 と互換性が無い為、相互接続が欠かせない電子メールの世界では、採用例は非常に限られます。IPv4/IPv6 併用は、IPv6 を IPv4 にトンネリングさせる必要があり、処理速度が大きく落ちます。この為、稼働していても、実験環境に過ぎない事が殆どです。大手通信会社でも、IPv4 と同等の IPv6 サービスを展開している所は皆無で、実例不足から来る不具合も多いです。些細なバグでも送信に失敗する「-all」(ハードフェイル) を IPv6 に設定するのは危険が伴う為、世界的なプロバイダーですら、「~all」(ソフトフェイル) を設定しています。従って、2009年~2013年06月20日の間に、この不具合の影響を受けた確率は、現段階ではそれ程、高く無い物と思われます。


更新日:2018年11月05日(月)