2019年02月07日
当社宛の請求書、領収証、見積書等の日付は「西暦」で表記して下さい。
2017年度下期より、当社は、業務効率化の為、「和暦」を廃止し、「西暦」に一本化しました。
【2019/05/20追記】 請求書、領収証に加え、「見積書等」を追加。取引先より「見積書」は対象でないのでは？ との問い合わせがあった為。
2019年02月07日
当社宛の請求書、領収証、見積書等の日付は「西暦」で表記して下さい。
2017年度下期より、当社は、業務効率化の為、「和暦」を廃止し、「西暦」に一本化しました。
【2019/05/20追記】 請求書、領収証に加え、「見積書等」を追加。取引先より「見積書」は対象でないのでは？ との問い合わせがあった為。
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、郵送等を通じて行う事。
2016年08月05日
一般的な公開ページであっても、https (セキュア) 接続が重視される様になった事を受け、従前「www. あり」になっていた URL 表記を、「www. なし」に変更します。
サーバー側でリダイレクト(転送)を行いますので、利用者様は何もしなくて結構です。
当社のサーバーは、電子証明書の制限から、「nitsuki.com」以外のサブドメインを利用出来ません。この為、セキュア接続を実現するには、https://nitsuki.com を使わざるを得ません。
この為、通常の接続も、「www. なし」に方針変更します。
sitemapxml.jp 様のツールを使わせて頂き、各検索エンジンへのサイトマップ登録を変更します。
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の社内利用から距離を置く様にします。
2013年07月19日。2013年12月18日 加筆修正。
弊社の電子メール・サービスには、前段に「迷惑メールフィルタリング・サーバー」が搭載されています。可否判定の1つに、送信元DNSサーバーの「SPFレコード」記述を利用していますが、この部分のプログラムに、導入当初から、ある不具合が発生していた事が判明しました。
得意先の茨城大学様より、「送信したメールが、(弊社に) 届かない」と連絡があり、2013年05月末頃に発覚。当初はサーバーの設定ミスか、相性問題と思われていましたが、互いのサーバー提供先同士で接続テストを行った結果、「迷惑メールフィルター」の判定プログラムにミスがある事が判明。2013年06月21日に修正され、以降は正しく処理される様になりました。
Windowsの場合の確認方法：
コマンドプロンプトで、nslookup -q=txt 送信サーバー名
Linuxの場合の確認方法：
コマンドライン・ターミナルで、dig -t TXT 送信サーバー名
起きていた現象：
SPFレコード記述に「+ の限定子」を持つ IPv6 記述が存在していた場合 (「+ip6」の記述があった場合)、迷惑メールフィルター側のプログラム・ミスにより正常な処理が出来ず、正しい IPv6 アドレスであるにも係わらずエラーとなっていました。この結果、「-all」でハードフェイル (Hard Fail) 設定をしていた場合、弊社宛のメールが一切届かなかったとの事です。
※下記はいずれも正しい記述であり、不達原因はあくまで当方ホスティングの不具合です。
"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" … (成功) 正しく処理され、送信可能でした
"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日の間に、この不具合の影響を受けた確率は、現段階ではそれ程、高く無い物と思われます。
Japanese
English