SecurityGateway for Email Servers v4.5リリースノート

10年以上に渡るメールセキュリティの専門知識を元に、SecurityGatewayはメールセキュリティを低価格で提供するために開発されました。ビジネスで求められるメールコミュニケーションに対して常に脅威となる、スパム、ウィルス、フィッシング、なりすまり、マルウェアから、システムを保護します。

SecurityGateway for Email Serversについては、こちらをご覧ください .

SecurityGateway 4.5.1 - 2017年05月09日

主な新機能

[15657] SecurityGatewayが新たにRPost®のRMail™サービスと連携

RMail™は直感的に使用する事ができ、受信者側で特別なソフトウェアなども必要ありません。RMail™ は企業規模、業界、職種を問わずご利用頂けます。

RMail™ サービスは RPostの Registered Email® テクノロジを基にしており、メールの配信証明における世界標準サービスです。RMail™ サービスは、貴社のメールシステムへ次の機能を追加します:

無償のRPostアカウントでは、ユーザー毎に月10通までの暗号化メールを送受信できます。追加が必要な場合はRPostから購入できます。メールの最大数を大きくするのに必要な情報や料金については、こちらから詳しい情報を確認して下さい。

RMail™サービスはセキュリティ | RMail™ ページからか、メールのコンテンツフィルタルールのアクションとして設定できます。

変更点と新機能

修正点

SecurityGateway 4.5.0 - 2017年4月4日

特記事項

[18161] 設定/ユーザー |メール設定 |メールプロトコルの「CRAM-MD5の認証方式を許可する」オプションが、セキュリティ及び技術的な理由により、デフォルトで無効化されるようになりました。パスワードを平文で送信せずにすむよう、TLSの利用をお勧めします。

変更点と新機能

修正点

SecurityGateway 4.0.1 - 2016年 7月26日

変更点と新機能

修正点

SecurityGateway 4.0.0 - 2016年 6月14日

主な新機能

[15999] ウェブインターフェイスをアップデートしモバイルファーストのレスポンシブデザインを採用

ウェブインターフェイスをアップデートし、モバイルファーストのレスポンシブデザインを採用しました。対応ブラウザはIE10以上、最新版のChrome、最新版のFirefox、MacとiOSの最新版Safariに限定されます。 Androidの標準ブラウザはスクロールにおける既知の問題が確認されていますが、Android端末に搭載したChromeでは正常動作を確認しています。

このデザインは使用しているウィンドウサイズを元に生成されています。ユーザーが、電話、タブレット、PCのどれを使っていても、ウィンドウサイズに合わせて表示されます。最も重要な変更点はメニューです。 956pixelを境目として、左側のメニューが隠れた状態になります。このメニューを表示するには2つの方法があります。タッチデバイスを使用している場合は、右側でスワイプする事で2つ目のメニューが表示されます。タッチデバイスがどうかに関わらず、左上の画面端にあるメニューボタンを押す事で、2つ目のメニュー表示が行えます。左向きの矢印付で表示されているメニュータイトルをタップ又はクリックする事でメインメニューが表示されます。画面右端にあるヘルプ、about、サインアウトメニューも、画面の幅を元に表示が異なります。768pixelを境目に、ヘルプ、About、サインアウトの文字が表示され、481から767pixelはアイコンのみが表示されます。480pixel以下ではギアアイコンだけの表示になり、これをクリックすると、ヘルプ、About、サインアウトのオプションが表示されます。1行を超える列を表示する場合は、オン/オフボタンを使用します。

[11232] DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance)に対応しました。DMARCとは、メールの送信者が管理しているDNSを使って、送信ドメインレベルのポリシーや設定を表記する事によりメールの送信元である事を証明するためのメカニズムであり、メール受信時にはこれらのポリシーや設定を使ってメッセージの処理効率を向上させる事ができます。DMARCの仕様や、DMARCがどんなものでどのような動きとなるのかについては、 http://www.dmarc.org/ から確認する事ができます。

DMARCを使うと、ドメイン以外から送信したメッセージを、正規のドメインからのメッセージとして証明できるようになります。メッセージ処理のポリシーとして指定できるオプションは「なし」で、SecurityGatewayでは何も行いません。「拒否」でSecurityGatewayはSMTPセッション中にメッセージを受信を拒否し、「隔離」の場合、SecurityGatewayは、各メッセージへ"X-SGDMARC-Fail-policy: quarantine"というヘッダを挿入します。このヘッダはDMARCでの認証に「失敗」した場合で、且つ、DMARCポリシーが「なし」以外の場合にのみ追加されます。DMARC要求で拒否されたメッセージであっても、SecurityGatewayでの受信を許可する事ができ、実際にこの動きがデフォルトとなっています。この場合、より厳しい処理を行おうとする環境用に、SecurityGatewayはメッセージへ「X-SGDMARC-Fail-policy: reject」というヘッダを追加します。

DMARCはADSPと、SPFのメッセージ削除機能の後継として位置づけられています。ただし、DMARCは他の機能と同時に使用する事もできます。DMARC検証を有効にすると、ADSPとSPFのメッセージ拒否はDMARCによる処理へ置き換えられます。

DMARCは「Public Suffix List」の利用に部分的に依存しています。「Public Suffix List」はインターネット利用者が直接名前を登録する事ができるリストです。Public Suffixの例として、.com, .co.uk, pvt.k12.ma.usなどがあります。「Public Suffix List」はパブリックなドメイン拡張子の一覧です。SecurityGatewayではMozilla Foundationコミュニティで管理しているものを使用しています:https://publicsuffix.org/ ここで公開されているリストのコピーが\App\フォルダ内にeffective_tld_names.datとしてインストールされます。現時点で、インターネットコミュニティ用の、総合的かつ正式なリストは存在しません。このファイルの情報は時間の経過に伴って劣化するものであるため、https://publicsuffix.org/list/effective_tld_names.datから最新のものをダウンロードし、\App\フォルダへ保存する事で、入れ替えを行う必要があります。SecurityGatewayは2週間に1度、日時メンテナンスの1つとして、このファイルの自動ダウンロードとインストールを行います。新しいDMARC設定画面では、管理用に様々なオプションが搭載されています。DMARCログ用に、メインUIのセキュリティタブの中に新しくDMARCウィンドウが追加され、アップデートや他のDMARC処理の結果が表示されます。必要に応じて異なるファイルダウンロードURLを指定する事もできますが、ダウンロードしたファイルのデータはMozillaが提供しているファイルで定義しているフォーマットへ準拠している必要があります。前述のURLで詳細をご確認下さい。SecurityGatewayはMozillaで定義した文解析アルゴリズムへ厳密に準拠しています。effective_tld_names.datを入れ替えたり編集したりした後で、再起動を行う事なく設定を再度読み込む場合は、SecurityGatewayの\App\フォルダへ「PUBLICSUFFIX.SEM」という(空の)ファイルを作成して下さい。

DMARCをメールの送信者として使用するにはDMARC TXTレコードをドメインのDNS設定へ含む必要があります。レコードをどのように定義するのかについてはhttp://www.dmarc.orgを参照してください。DMARCをDNSで公開すると、DMARCレポートが異なる複数の送信元から届くようになります。このレポートはDMARCの仕様として定められているXML形式で提供されます。このレポートの処理はSecurityGatewayのDMARCの実装においては対象外ですが、このレポートのデータには、ドメインのメールフロー、不正利用、DKIM署名の整合性、SPFメッセージの整合性や完全性、といった、重要な情報も含まれています。レポートの送信先アドレスはDMARCレコードの作成時に指定したものを使用します。

1つ以上のドメインに対してDMARCレコードを設定する時は、p=rejectの使用にご注意下さい。ドメインを一般的な用途のメールアカウントに使っている場合は特に注意してください。そのようなユーザーがメーリングリストを購読したり、メール転送サービスを利用したり「この記事をシェアする」のボタンと同じような挙動を期待する操作を行おうとしても、DMARCのp=rejectポリシーでは、このような操作を全般的に拒否します。DMARCのp=rejectは、(例えば、トランザクションのメールや人が利用するのではない自動化されたメールアカウントや、外部でメールを使う場合に企業のセキュリティポリシーを強制する手段を検討した際など)メールアカウントの利用方法をドメインレベルでコントロールする場合に限り、大変有効な手段であり、便利な手段でもあります。

DMARCの統計サポートに対応するためSecurityGatewayではDMARCの仕様に基づいたレポート生成を行うために今後必要となり得るデータを保持します。SecurityGatewayはDMARCの"ri=";タグを無視し00:00:00 UTCから23:59:59 UTCの範囲でのみDMARCの統計レポートを生成します。(必ずしもローカル時間である必要はなく)UTCの深夜にSecurityGatewayはこの蓄積されたデータをレポートの生成に使用します。SecurityGatewayがこの時に稼働していないと、データは日々蓄積され、使われる事がありません。そのため、SecurityGatewayを24/7で稼働させていない場合、DMARCの統合レポートは有効にするべきではありません。DMARC統合レポートはデフォルトで無効に設定されています。

DMARCの失敗レポートに対応するため、RFC 5965「An Extensible Format for Email Feedback Reports」, RFC 6591 「Authentication Failure Reporting Using the Abuse Reporting Format」, RFC 6652 「Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format」, RFC 6651 「Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting」, RFC 6692 「Source Ports in Abuse Reporting Format (ARF) Reports」に対応しました。失敗レポートはトリガとなる事象を確認する度にリアルタイムで生成されます。SecurityGatewayではDMARC AFRFタイプの失敗レポートを実装しており、IODEFタイプのレポートではありません。そのため、DMARC "rf=" タグの中では"afrf"の値のみが認識されます。詳細はDMARCの仕様を参照してください。DMARCレコードの"ruf=" タグ内の宛先の数や、"fo=" タグの指定によって、メッセージ処理中に複数回認証失敗が発生し、それにより、複数の失敗レポートが1つのメッセージから生成される場合があります。DMARC "fo="タグがSPF関連の失敗レポートを要求すると、SecurityGatewayはRFC 6522に基づいて失敗レポートを送信します。そのためには、仕様の中の拡張機能がドメインのSPFレコードとして公開されている必要があります。SPF失敗レポートはDMARC処理から独立して処理されたり、RFC 6522の拡張として対象外にされるものではありません。そのためには仕様の拡張がDKIM署名ヘッダフィールドに存在し、DNSへ正規のDKIMレポート用TXTレコードやADSP TXTレコードへ正規のADSP拡張が公開されていなくてはなりません。詳細については様々な仕様からご確認頂けます。DMARCの失敗レポートはデフォルトで無効に設定されています。

特記事項: DMARCレコードではレポートをドメイン所有者として指定の宛先へ送信する事ができます。その場合は、不正利用やパフォーマンスの問題の切り分けといった用途でメールを監視するといった目的を伝えた上で、ドメイン所有者からの許可をもらって実施してください。個人情報の取扱いや利用許諾、類似文書の中で、こうしたデータの第3者への譲渡を禁止している場合もあります。社内規定でDMARCレポーティングの利用や伝達に対する規制がされていないかどうかを確認し、規定によって必要性がある場合にはDMARCレポーティングを無効化してください。

DMARCはレポートの宛先が対応している場合にはSTARTTLSを使う必要がありますが実際に宛先の対応状況を事前に知る事はできません。しかしながら、もしもSTARTTLSが有効になっていない場合は、これを有効にする事をお勧めします。(設定 / ユーザ | システム | 暗号化 を確認してください。)

認証結果のヘッダはDMARCの処理結果を含むものへと拡張されました。認証結果(Authentication-Results)ヘッダにはデバッグの目的で、メッセージへ直接的なアクションは必要のない、ドメイン所有者から要求されたDMARCポリシーなどの情報が、コメントとして含まれている点にご注意下さい。DMARCポリシーはチェックで「失敗」したメッセージにのみ適用されるため、例えば、DMARCチェックの結果が「承認」されれば、DMARCポリシーの内容は気にする必要がありません。これと類似したものとして、DMARCチェックの結果が「失敗」でポリシーが「拒否」であればメッセージはローカルポリシーに従って受信される事になります。このヘッダを使う場合は、アカウント毎のフィルタリングをお勧めします。「X-SGDMARC-Fail-policy: quarantine」やX-SGDMARC-Fail-policy: reject」ヘッダを持つメッセージはスパムフォルダへ格納するようフィルタリングする事もできます。SecurityGatewayは「X-SGDMARC-Fail-policy:」ヘッダを全ての受信メールから取り出します。

メッセージはRFC 5322のFromヘッダを定義したDMARCセクション15.1に準拠したものでなくてはならず、そうでないものは基本的に(RFCで定義された)RFC5322のFromヘッダの仕様に準拠していないものとして、DMARC処理は正常に実施されません。

セキュリティ | 不正利用対策へ新しい画面が複数追加され、DMARCの利用に関する様々な設定を行う事ができるようになりました。

DMARCはSPFやDKIMのメカニズムを基にした認証機能である事から、SPFやDKIM認証が有効になっている必要があります。DMARCはこれらの認証のどちらか又は両方の技術を有効にしていないと事実上の効果はありません。UIではこれらの認証の有効化を行います。

[3961] ドメインとIPアドレスの関連付け

複数のIPアドレスを割り当てられたサーバーで、ドメイン毎に使用するIPアドレスを割り当てられるようになりました。対象ドメインからのメールは関連付けられたIPアドレスから送信されます。

SMTPホスト名もドメイン毎に指定できるようになります。この値は Fully Qualified Domain Name (FQDN)で、ドメインからのメール送信時にSMTP HELO/EHLOで利用されます。受信時の接続において、複数ドメインがこのIPアドレスを使用していた場合、アルファベット順で最初のFQDNが、SMTPホスト名として使用されます。

変更点と新機能

修正点

Copyright ©2008-2016 Alt-N Technologies, Ltd.