皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は一昨日投稿した記事の続報になります。

メールアカウントエラーは原因不明のまま

このメールアカウントエラーは何故起きたのかは現在も原因不明なままですが。以下のことから推察できる可能性は何であると思いますか？

１．インターネット回線上に障害はなかった

２．モバイルデータ通信上にも障害はなかった

３．ルータが特定のポートのみ不具合を起こすことはメーカーの過去の事例にない

４．WWW、FTP、POP、SMTPなど他のプロトコル（ポート）は正常であった

これらから考えると、通常はメールサーバに何らかの問題が発生していたとしか考えにくのですが、ホスティング業者はそれは否定しています。

結果的にこの問題は迷宮入りとなる可能性大です。

さて、ではこのような原因不明の状態に陥ってしまった場合にはどのようにしたら良いか？

１．PCやモバイルデバイスを再起動してみる

２．ルータを再起動してみる

３．インターネット回線で他のプロトコル（ポート）が正常が確認してみる

４．モバイルデータ通信で他のプロトコル（ポート）が正常か確認してみる

５．アカウントエラーになっているホストに疎通確認をしてみる

６．アカウントエラーになっているホストにポート番号を指定して疎通確認をしてみる

このようなことを確認してみると良いです。

特に前述のような一部のプロトコル（ポート）のみに問題が起きている場合、6番目のポート番号を指定して疎通確認をしてみると判断し易いかもしれません。

方法としてはWindowsの『PowerShell』で『Test-NetConnection』コマンドを使うと簡単に確認できます。

例：PS C:\> Test-NetConnection -ComputerName ホスト名 or ホストIP -Port ポート番号

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は私も経験した『電子メールのアカウントエラー』に関してお伝えします。

それはある日突然起きました。

メールアカウントエラーは突然に

まず、私が『メールのアカウントエラー』を経験した際の使用環境を記載します。

・PC-1：Windows 10 Pro 1803、Thunderbird 60.6.1 64bit、有線LAN

・PC-2：MacBook Pro BootCamp Windows 10 Pro 1803、Thunderbird 60.6.1 64bit、Wi-Fi（無線LAN）

・iPhone：iOS 12.3、標準メールアプリ、Wi-Fi（無線LAN）＆モバイルデータ通信

こんな感じです。

『メールのアカウントエラー』はこのすべて、かつWi-Fi（無線LAN）とモバイルデータ通信で起きていました。

この段階で言えるのは、

１．PCやiPhoneの個別環境の問題ではない

２．セキュリティソフトの影響でもない

３．社内ネットワークの問題でもない

ということです。

デバイスの個別の問題であれば他のデバイスでは起きなく、セキュリティソフトの影響であればiPhoneでは起きないはずですし、社内ネットワークの問題であればモバイルデータ通信では正常に使用が可能なはずです。

疑わしきはメールサーバか？！

しかし、メールサーバ（私の場合『IMAPサーバ』）のログを確認してもらったが正常稼働しており問題が確認できない。。。

？？？

pingも通ればWebやFTPなどの他のプロトコルにも問題は出ていないし、ルータも再起動している。

＆、ファイアウォール設定も変更はされていない。

さて、何が問題なのでしょうか。。。

この続きは近日投稿します。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日々業務で使われるメールですが、思わぬところで受信されないケースが出てくることがあります。

メールにおけるフィルタ設定問題

契約されているサーバによっては、迷惑メールの対策として受信メールのフィルタリング設定がカスタムできるものがあります。

その場合、設定内容によっては一部のメールが突然受信されなくなることもあり、その原因はいくつか考えられます。

１．メールサーバ側のスパム判定が変わった

２．設定されているフィルタ項目の文字列にたまたま引っかかった

３．誤判定によるもの

４．他のフォルダに振り分けられていた

５．etc…

これにプラスして、処理方法が『削除』する設定を行っていた場合、メールは受信されずに削除されます。

（当り前ですが。）

このような場合、

１．スパムの判定レベルを調整し直す

２．フィルタ設定されている処理方法を変更する

３．フィルタ設定の対象を変更する

４．サーバ会社に確認依頼をする

５．etc…

といった感じです。

では、こういったことが起きてしまった場合には何を見るか？ですが、フィルタ処理されているもののログを確認していくしかありません。

送信者に送信日時を確認し、該当するメールに対する処理を1行ずつチェックしていくことです。

それをチェックすれば、必ずマッチしてしまった部分がどのフィルタリングかがわかりますので、その部分を見直すことになります。

もし単なる誤判定ということであればサーバ会社からの回答を待って対処するしかない可能性もあります。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日の記事ですが、中小・零細企業、小規模事業者において『DKIM』まで導入することは難しい（レンタルサーバが対応していない場合が多い）などの理由から、それが行えない前提として読んでください。

『DKIM』導入可能な場合においては下記の限りではありません。

さて、自社や自店のドメインが偽装されたメールなどに使われていたことを知っても、ある意味では八方塞がりになってしまう可能性があります。

それはどういった状態だと思いますか？

DMARCのポリシーは受信者の協力も必要

事業者が使っているドメインであれば、DNSのTXTレコードにSPF認証に関する記述が加えられていることは昨今においては普通のことと言えます。

逆に、記述がないのであれば追加しておくべきです。

例：example.com. IN TXT “v=spf1 ip4:***.***.***.*** include:example.com -all”

（***.***.***.***の部分はv4のIPアドレスが入ります。）

さて、このSPFに関する記述が入っている場合でDMARCの記述も追加されている場合、Appleなどはポシリーを『none（指定なし）』にしていますが、MicrosoftやGoogleは『reject（拒否）』にしています。

これ、受信者が転送処理などを行わずにストレートにメールを受信している場合においては『none（指定なし）』から『quarantine（隔離）』、『quarantine（隔離）』から『reject（拒否）』と、フィルター処理の割合を組み合わせながら段階的にポリシー変更を行っていけば良いですが、受信者が転送処理などを行っている場合、相手のサーバ設定によっては『none（指定なし）』から他に変更することで問題が生じます。

例えば、受信者が自動転送設定をしていた場合で、その際のIPアドレスの出力を転送元IPアドレスとしていた場合、送信元ドメインとそのIPアドレスが一致せず、SPF認証は『Pass』とならないため受信者がメールを受け取れない可能性が出てきます。

（DMARCのフィルター処理（PCT）の設定値にもよります。）

このような場合においては正直八方塞がりのような状態になります。

従って、受信者側に自動転送をやめてもらうか、受信者側に転送先メールアドレスを開示いただくか、何らかの協力をお願いすることになります。

（メールサーバの仕様を簡単に変更するわけにもいきませんので。）

まずは偽装されたメールが出回っていることをアナウンスすることからスタートですが、『全く関係のない消費者などが被害にあわない』、『自社や自店のドメインを傷つけない』ためには、最終的にはDMARCのポリシーを『reject（拒否）』にできる環境整備を行っていく必要性があるでしょう。

また、冒頭でも書きました通り、これを送信者側のみで解決しようとした場合は『DKIM』の導入が必要となります。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

頻繁に送られてくる『楽天市場』を装ったスパムメールですが、昨日と今日に渡り、執拗なまでに拡散しているように思われます。

楽天市場を装ったフィッシングメール

現時点においては、4月24日（火）、25日（水）と、連日に渡って何通もの『楽天市場』を装ったスパムメールが拡散しています。

このメール、パッと見た限りではわかりにくく、本文中に張られたリンク先をクリックさせるフィッシングメールと思われます。

件名：【楽天市場】注文内容ご確認（自動配信メール）

差出人：楽天市場

本文：本当の楽天市場から送られてくる自動配信メールに酷似したHTML形式のもので、ショップ名は複数あるため固定ではありません。

ただし、購入したことにされている商品が、3万数千円程度（34,800円であったり、38,800円であったり）の『40V型LEDフルハイビジョン液晶テレビ（微妙に書き方が違う場合あり）』であることは共通しているように見受けられます。

メールのヘッダー情報を見ると、SPF認証には成功していない『Received-SPF: softfail』、IPアドレスは本当の楽天市場では使われていない海外（ロシアやブルガリアあたり）のIPアドレスが多く見受けられます。

このスパムメールは添付ファイルもありませんので、リンクをクリックしなければ何も問題は起きません。

また、受け取ることすら拒否したい場合、メールサーバにてフィルタリングすることで対応は可能です。

ただし、送信元のドメインを拒否してしまうと本当の『楽天市場』からのメールがすべて届かなくなってしまいますので、『SPF: pass』を『含まない』や、IPアドレスを交えた条件を指定する必要があります。

では、これらのウイルスメールにはどのように対処したら良いのでしょうか？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭でも書きました通り、ウイルスメールの拡散は非常に多い状況にあります。

それらの被害を軽減するには、UTM（統合脅威管理）を導入するなどしてそれらを排除してしまうことが手っ取り早い方法ではありますが、これには導入時のイニシャルコストや保守費用としてのランニングコストが掛かります。

費用面などのこともあり、なかなか導入に踏み切れないところもあるでしょう。

また、UTM（統合脅威管理）を導入したからと言って、必ずしも万全な体制が整備されるかと言うと、そうではありません。

（※　お勧めではありますので、費用面などにおいて余裕があるのであれば導入をお勧めします。）

では、何か他に良い方法はないものでしょうか？

ウイルスメールの受信率を下げる

まず大前提として、社内のインターネットセキュリティ、端末におけるエンドポイントセキュリティは絶対条件です。

小規模であれば、インターネットセキュリティとアンチウイルスソフトなどが1つにまとめられているパーソナル向けのセキュリティでも構いませんので、各端末への導入は必須です。

さて、それを前提とした上でウイルスメールの受信率を下げるとはどういうことでしょうか？

ウイルスメールになり得るのは、zipファイルやExcel・Word、.exeや.comなどの添付ファイルが付いたメールか、メールの本文にウイルス感染への導線となるURLが書かれているかの2つになります。

そこから考えると、そもそもそれらを受信しなければ、メール経由でのウイルス感染は確率的に減少することになります。

例えば、最近最も多いウイルスメールとしてはzipファイルが添付されたものが多いですが、これをメールサーバーに届いた段階で専用アカウントに転送してしまうか、無条件で削除してしまうなどの対策をすればウイルスメールの端末（クライアントパソコン）での受信率は下がります。

クライアントパソコンでそれらを受信することがなければ、誤って添付ファイルを開いてしまうこともなくなるわけです。

ウイルス対策ソフトも絶対的に保護されることを約束されているものではありません。

タイミングなどによっては検知・駆除されない場合もありますので、端末（クライアントパソコン）で受信する前段階における対策も1つの方法と言えるでしょう。

メールサーバにおける設定方法などは明日のブログにおいてご紹介しますので、是非、明日の投稿もお読みください。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

近年では、取引先とのやりとりをメールで行うことは当り前の時代になっていますが、今まで送れていたメールが突然エラーとなって返ってくることになったら困りますよね。

今日はそんな事例をお話しします。

セキュリティ製品の導入

メールを受信する側が何らかのセキュリティ製品を新たに導入した場合、送信したメールがブロックされてしまうことがあります。

セキュリティ製品を専門で取り扱っているベンダーはスパムメールに対するデータベースを保持しており、日々それを更新してユーザーが利用するセキュリティ製品に配信したりしています。

その影響により、今まで普通に送信できていたメールが突然相手側でブロックされてしまうといったことも起きてしまうケースがあります。

つまり、セキュリティベンダーのデータベース上にスパムリストとして登録されてしまっていることがあるのです。

もちろん、それに検知されない＝それを利用していない相手への送信はブロックされません。

（それ以外にもスパムリスト入りしているものがあれば別です。）

リレーサーバなどのスパムリスト入り

中小・零細、小規模事業者などの場合においては、自社にメールサーバを立てたり専用サーバを借りるケースは少なく、大半は共用型のレンタルサーバを契約し、その中でメール設定をして利用するケースが多いです。

この場合、DNSなどの設定上は独自ドメインであったとしても、実際にはレンタルサーバ会社側にて異なる設定をしているケースがあります。

例えば、レンタルサーバのIPアドレスが何らかの原因で一部のスパムリストに登録されてしまったとします。

その場合、そのIPアドレスの情報を持つメールからの受信を拒否してしまう相手もいます。

（相手側の契約しているレンタルサーバなどがそのスパムリストを参照している。）

これを回避するため、原因の特定と問題の解消がなされるまでの間、一時的にリレーサーバ経由にてメールの送信を行うようにしたりすることがあるのですが、その場合、相手側に届くメールのIPアドレスの情報はリレーサーバのものとなり、そのIPアドレスやリレーサーバのサブドメインなどがスパムリスト入りしていることによってブロックされてしまうこともあるのです。

（前述のものを含め、これらは解除申請をしないと正常には戻りません。）

このようなケースの場合、一部の相手だけに対してメールが送信できずにエラーで返ってきてしまうわけですから、どこかのスパムリストに入ってしまっている可能性が高いです。

その場合であっても、自身で勝手に解除申請をしてはいけません。

これらは問題解決がなされていることを前提に解除申請を行いますので、まずは契約のレンタルサーバ会社などに相談し、適切な対処を行ってもらうことが一番です。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

2010年以降減少傾向にあった迷惑メールの検知数は、2016年に入って再び上昇し、増加しています。

そして、中でも多いのは『なりすましメール』と呼ばれるものです。

この『なりすましメール』を排除していくには、メールの送信側と受信側における連携が必要であり、送信側においては送信するメールの正しい情報を提供することが必要になります。

送信ドメイン認証の仕組み

前述の通り、まずは送信側において正しい情報を提供する必要があります。

その第一歩として送信ドメイン認証を使ったりしますが、その場合には下記のような状態となります。

※前提：送信側・受信側ともにSPFを導入済み

１．送信側のA社が受信側B社にメールを送ります

２．受信者側のB社はA社のDNSサーバに問い合わせを行います

３．２の要求に対し、A社のDNSサーバが送信用メールサーバに関する情報を返します

４．３の確認結果に基づきメールを配信する

SPFレコードの設定方法

送信側の設定としてはDNSサーバにSPFレコードを追加します。

そこに、SPFもしくはTXTとして以下の記述を追加します。

※前提：送信用メールサーバのIPアドレスが192.1.1.1の場合で、ドメインがexample.comの場合

“v=spf1 +ip4:192.1.1.1 -all”

これを追加するだけです。

また、受信側としてSPFの検証機能を導入すれば『なりすましメール』を区別できるようになりますが、メールサービスやメールサーバソフトによって異なりますので、ご利用のレンタルサーバ会社へ問い合わせることなどが必要です。

（レンタルサーバ側にて導入済みであれば、受信側としては何も行うことはありません。）

ただし、昨今SPFだけでは不十分ということも指摘されており、近いうちにそれを補うものをご紹介できればと思います。