MDaemonサーバv14リリースノート

MDaemon 14.5.3 - 2015年 1月20日

変更点と新機能

修正点

MDaemon 14.5.2 - 2014年11月20日

修正点

MDaemon 14.5.1 - 2014年11月11日

変更点と新機能

修正点

MDaemon 14.5.0 - 2014年10月21日

特記事項

[13265] Ctrl+O | 初期設定 | ヘッダ 画面から「メッセージヘッダの処理時にローカルIPを隠す」と「LAN IPも隠す」の2つのオプションが削除されました。このオプションは予約済IPアドレスを隠すオプション1つに置き換えられました。元の2つのオプションは以前より削除する方向性となっていました。新しく追加されたオプションでは、「メッセージヘッダを生成する際、予約されたIPアドレスは隠す」となり、デフォルトで有効になっています。。予約済IPアドレスは様々なRFCで定義されており、次のようなIPが含まれます:(a) 127.0.0.* (b) 192.168.*.* (c) 10.*.*.* and (d) 172.16.0.0/12。(LANドメインも含む)ドメインIPでも同様な設定を行う場合は、MDaemon.iniへ手動で設定を追加してください: [Special] HideMyIPs=Yes (デフォルトはNo)

[13332] 「POP3, IMAP,およびWorldClientパスワードは大文字・小文字を区別する」を選択できるオプションがCtrl+O | 初期設定 | その他 から削除されました。今後、パスワードは常に大文字・小文字を区別するようになります。大文字と小文字を区別しないパスワードはセキュリティ上好ましくなく、(APOP, CRAM-MD5などの)ハッシュベース認証メカニズムや安全な(ハッシュベースの)パスワードストレージと互換性が無いためです。この変更に伴いまして、お客様環境によりましては、メールクライアント側でパスワードの再入力(正しく大文字、小文字を区別した)を求められる場合があります。

[13786] SPFキャッシュファイルへ、最後のSPF処理の結果ではなく、ドメインで実際に使っているDNSのSPFポリシーレコードをキャッシュするようになりました。古いSPFCache.datファイルは移行する事はできません。後の参照用に、SPFCache.dat.oldとファイル名が変わります。 SPFCache.dat.oldは削除しても影響はありません。

[13121] DomainKeys は削除されました(詳しくは後述)。その結果、コンテンツフィルタにおける処理として、DomainKeysに関する処理を無視するようになりました。もし、お使いのルールでDomainKeysに関する処理を使われていたら、代わってDKIM署名に関する処理へご変更頂くか、ルールの削除をお願いいたします。

主な新機能

[11196] DMARC (MDaemon PROが必要です)

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

DMARCを使うと、ドメインの外部から送信したメッセージをドメインからのメッセージとして証明できるようになります。メッセージ処理のポリシーとして指定できるオプションで「none」の場合、MDaemonでは何も行いません。「reject」でMDaemonはSMTPセッション中にメッセージを受信を拒否し、「quarantine」の場合、MDaemonは、各メッセージへ"X-MDDMARC-Fail-policy: quarantine"というヘッダを挿入し、フィルタリング機能を使ってユーザーのジャンクメールフォルダへこれらのメールを振り分けることができるようにします。このヘッダはDMARCによる確認の結果、「fail」であった場合にのみ追加されます。DMARCでの確認で、拒否することを指定されたメッセージであったとしても、MDaemonでメッセージを受信するように設定することもでき、実際にこの動作をデフォルトとしています。この場合でも、MDaemonはメッセージへ「X-MDDMARC-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」はパブリックなドメイン拡張子の一覧です。MDaemonではMozilla Foundationコミュニティで管理しているものを使用しています:https://publicsuffix.org/ ここで公開されているリストのコピーが \Appフォルダ内にeffective_tld_names.datとしてインストールされます。現時点で、インターネットコミュニティ用の、総合的かつ正式なリストは存在しません。このファイルの情報は時間の経過に伴って劣化するものであるため、https://publicsuffix.org/list/effective_tld_names.datから最新のものをダウンロードし、\Appフォルダへ保存し、入れ替えを行う必要があります。MDaemonは2週間に1度、日次メンテナンスの1つとして、このファイルの自動ダウンロードとインストールを行います。新しいDMARC設定画面では、管理用に様々なオプションが搭載されています。DMARCログ用に、メインUIのセキュリティタブの中に新しくDMARCウィンドウが追加され、アップデートや他のDMARC処理の結果が表示されます。必要に応じて異なるファイルダウンロードURLを指定する事もできますが、ダウンロードしたファイルのデータはMozillaが提供しているファイルで定義しているフォーマットに準拠している必要があります。前述のURLで詳細をご確認下さい。MDaemonはMozillaで定義した分析アルゴリズムへ厳密に準拠しています。effective_tld_names.datを入れ替えたり編集したりした後で、再起動を行う事なく設定を再度読み込む場合は、MDaemonの\App\フォルダへ「PUBLICSUFFIX.SEM」という(空の)ファイルを作成して下さい。

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

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

DMARCのp=rejectは、正しく設定していないとメーリングリストのメンバーが自動で削除されてしまったり、メーリングリストに対しては特に望ましくない動作となります。こうした動作を避けるためには、次の手順が必要になります。:(I) メールの宛先に対して: (a) (最低限)p=rejectを公開しているドメインのメーリングリストへは投稿を禁止してください (b)禁止ができない場合は、p=rejectを公開しているドメインへ投稿する送信元メーリングリストのみ、全てのFrom:ヘッダを変換するよう設定してください。MDaemon 14.5では、メーリングリストエディタ内に、こうした設定全てを行えるよう新しいオプションを追加しました。この設定を使わない場合には、最低限メーリングリストのメールを拒否したメンバーを自動削除するオプションを無効にしていることを確認します。そうしないと、メールシステムがDMARCに準拠していた場合、(例えば) user@yahoo.com が属しているaol.comのリストメンバーからのメールは全て自動削除されてしまいます。MDaemon 14.5では全メーリングリストに対して機能する前述の軽減用機能によって、DMARCのセーフリストへ全てのメーリングリストが自動で登録されるため自動で削除されることはありません。(II)メール送信者に対して:ドメイン用DMARCレコードの公開やレポート受信用のアドレスの指定において、p=rejectは(状況によっては非常に)有効なものである場合にのみ使用するようにしてください。こうした説明がDMARC(又は少なくともp=rejectの部分)に対して、否定的に聞こえるかも知れませんが、そうではなく、大変素晴らしい機能だと考えています。これは第3ラウンドとして私たちが全体として取り組んでいくべきものだと考えています。ただ、他の全ての機能と同様、本機能も正しい設定でない場合、問題を引き起こすという事です。

DMARCの統計サポートに対応するため、MDaemonではDMARCの仕様に基づいたレポート生成を行うために今後必要となり得るデータを保持します。MDaemonはDMARCの"ri=";タグを無視し00:00:00 UTCから23:59:59 UTCの範囲でのみDMARCの統計レポートを生成します。(必ずしもローカル時間である必要はなく)UTCの深夜にMDaemonはこの蓄積されたデータをレポートの生成に使用します。MDaemonがこの時に稼働していないと、データは日々蓄積され、使われる事がありません。そのため、MDaemonを24時間365日で稼働させていない場合、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」で定義されているDMARCの失敗レポートに完全対応しました。 失敗レポートはトリガとなる事象を確認する度にリアルタイムで生成されます。MDaemonではDMARC AFRFタイプの失敗レポートを実装しており、IODEFタイプのレポートではありません。そのため、DMARC "rf=" タグの中では"afrf"の値のみが認識されます。詳細はDMARCの仕様を参照してください。DMARCレコードの"ruf=" タグ内の宛先の数や、"fo=" タグで指定されているメッセージ処理中の認証失敗回数によっては、複数の失敗レポートが1つのメッセージから生成されます。DMARC "fo="タグがSPF関連の失敗レポートを要求すると、MDaemonはRFC 6522に基づいて失敗レポートを送信します。そのためには、仕様の中の拡張機能がドメインのSPFレコードとして公開されている必要があります。SPF失敗レポートはDMARC処理から独立して処理されたり、RFC 6522の拡張として対象外にされるものではありません。そのためには仕様の拡張がDKIM署名ヘッダフィールドに存在し、DNSへ正規のDKIMレポート用TXTレコードやADSP TXTレコードへ正規のADSP拡張が公開されていなくてはなりません。詳細については様々な仕様からご確認頂けます。 DMARCの失敗レポートはデフォルトで無効に設定されています。

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

DMARCはレポートの宛先が対応している場合にはSTARTTLSを使う必要がありますが実際に宛先の対応状況を事前に知る事はできません。しかしながら、もしもSTARTTLSが有効になっていない場合は、これを有効にする事をお勧めします。(Ctrl+S | SSL & TLS | MDaemonを確認してください。)

DMARC検証用のホワイトリストがあります。このホワイトリストはIPのみ使用できます。このホワイトリストに該当するIPはDMARC処理から除外されます。DMARCはSPFやDKIMのホワイトリストとも連携します。もしもSPFやDKIMのホワイトリストに該当するホストがそれぞれの処理から除外されると、DMARC処理からも除外されます。当然ながら SPFとDKIMの両方が無効化されている場合も、DMARC処理が除外されます。

DMARC検証ではホワイトリストを使う事ができます。ホワイトリストへはIPのみが使用できます。しかしながらDMARCではDKIM認証や信頼するSPFを基にしたホワイトリストである、承認リストも採用しています。そのため、例えば、到着したメッセージがDMARC検証に失敗しており、一方で承認リストのドメインから発行された正規のDKIM署名を使っていた場合、メッセージはDMARCポリシーに抵触したものとはみなされません(この時、メッセージは、ポリシーをp=noneと設定していた時と同様に処理されます)。SPFパス検証が承認リストのドメインに一致した場合にもこれと同じ事が起こります。現在の承認リストが今後はDMARCのホワイトリストとしても使われる事にご注意下さい。最後に、DMARCはMDaemonのVBRシステムと統合され、Ctrl+S | 送信者認証 | VBR認証へ新しいオプションが追加されました。ここで行う設定により、DMARCチェックには失敗したものの、信頼するVBRサービスプロバイダの1つ以上から認識されてさえいれば、DMARCのポリシー違反を無視する事ができるようになります。このオプションはデフォルトで有効です。VBRの詳細については https://www.altn.com/email-certification/を参照してください。VBR (RFC 5518)の標準化、おめでとうございます!

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

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

Ctrl+S | 送信者認証へ新しい画面が複数追加され、ここではDMARCの利用に関する様々な設定を行う事ができます。

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

DMARCReporterはDMARC XMLレポートを読み込んで読みやすいHTMLへ変換してくれるツールです。これは\MDaemon\App\フォルダへインストールされます。使用方法についてはDMARCReporterReadMe.txtをご覧ください。

[9843] 画面を一新したMDAEMON REMOTE ADMINISTRATION

Remote Administrationの管理画面を一新しました。「モバイルデバイス管理」は簡単にアクセスできるよう上位のメニューへ配置しました。他のメニューもMDaemonのレイアウトに近いものへと変更し、より適切な場所へと移動しました。操作に応じたヘルプ画面が追加されました。

[10279] ACTIVESYNCサーバーがサーバー上でのメール検索に対応 (MDaemon PROとActiveSync ソフトウェアライセンスが保守契約期間内である事が必要です。)

MDaemonのActiveSyncサーバーがサーバー上でのメール検索に対応しました。ActiveSyncクライアントのドキュメントを読み、クライアントがこの機能に対応しているかどうかや、どのようにこの機能を利用できるのかを確認してください。検索インデックスはサーバー上で検索されたフォルダへ、SrchData.mrkとSrchIndex.mrkというファイル名で格納されます。

[13231] メーリングリストエンジンのアップデート

メーリングリストエンジンで複数の機能をアップデートしました。

[13196] メーリングリストエディタを部分的に再構築しました。全てのヘッダ操作に関連する設定は設定ページから削除され、新しく独自のヘッダページを追加しました。また、メーリングリストの優先度の設定値は推奨されないものであったため削除しました。関連してメーリングリスト名をTo:ヘッダの「表示名」へ挿入するオプションは同じ画面のラジオボタンでのオプションと重複するため、不要な設定として削除しました。

[13198] メーリングリストエディタへ新しいオプションを追加し、 (「p=reject」や「p=quarantine」といった)制限用DMARCポリシーを公開しているドメイン所有者のメーリングリストから送信されたメッセージを拒否する事ができるようになりました。このオプションはデフォルトで有効です。制限用ポリシーを公開する事で、ドメイン所有者は、ユーザーがメーリングリストを購読したり、メール転送サービスを利用したり「この記事をシェアする」に似たサービスを効果的に禁止できるようになります。メーリングリストエンジンでこのようなメッセージを許可してしまう事で無関係なメンバーが自動的に購読解除されてしまう場合もあります。新しくFrom:ヘッダに代わるオプションを使えば、このオプションを有効にする必要はありませんが、失敗よりも安全を優先するべきでしょう。([13160]を参照してください。)また、(もしも既に存在する場合は)有効なメーリングリスト用DKIM署名を無効にする必要はなく、(Subject:ラベルやフッタへの追加など)有効利用するべきです。

[13160] メーリングリストヘッダ画面へ新しいオプションを追加し、受信者のドメインが制御DMARCポリシーを公開している場合に警告する事ができるようになりました。このオプションはデフォルトで有効になっており、この設定はそのまま利用する事をお勧めします。これまでFrom:ヘッダデータはそのままの状態にしていました。これにより、最近のメーリングリスト管理者が直面しているYahoo, AOL, その他が公開しているDMARC "p=reject" ポリシーに関する問題解決に役立てる事ができます。このオプションはDMARCデータに依存したものであることから、DMARC処理が無効になっている場合は何も行いません。From:ヘッダがこの機能によって書き換えられると(1)メッセージにReply-To:ヘッダが存在しておらず (2)かつ、メーリングリスト設定の中で、カスタマイズされたReply-To:を挿入する設定になっていない場合のみ、From:ヘッダのデータはReply to:ヘッダへ移動します。

[5102] List-ID (RFC 2919)へ新たに対応しました。 List-IDを使う事でメーリングリストのList-IDメッセージヘッダへ短い説明文を挿入する事ができます。この説明はオプションで指定がなければ自分自身の識別IDを挿入します。ヘッダの説明文の例は次の通りです:List-ID: 。指定がない場合の例は次の通りです:List-ID: 。メーリングリスト自身のメールアドレスがメーリングリストの識別情報として記載されます。(誤った解釈のないよう"@"は"."へ変換される点に注意してください。)List-IDヘッダは社内のメーリングリストへのメッセージからは削除されますが、外部のメーリングリストから社内ユーザーに届くメールからは削除されません。

[13201] List-Post, List-Subscribe, List-Unsubscribe, List-Help, List-Owner, List-Archiveのメーリングリストヘッダ (RFC 2369)に新たに対応しました。こうしたヘッダは(スペース的に余裕のあった)メーリングリストエディタのモデレーションタブの中で、URLが指定されていた場合に、メーリングリストのメッセージへ追加されます。これはRFC 2369で定義されている通り(例えば mailto:arvel@altn.com のように)URLで指定する必要があります。文書へ記載されている例をご覧ください。設定を行うと、全てのメーリングリストメッセージへ追加されます。データが正しくない場合は期待した動作となりません。 

[13230] 月次で購読のリマインダーをメーリングリストへ送信する機能が搭載されました。有効にすると、MDaemonは毎月1日に全てのメーリングリストメンバーへリマインダー用のテキストを送ります。リマインダーメッセージはメーリングリストエディタのリマインダーページでカスタマイズできます。次のマクロがリマインダーのメッセージ内で利用できます。

こうした設定に対して、メーリングリスト毎に異なる日時指定や、MDaemon GUIへフルHTMLブラウザ/エディタの搭載、といった無駄に複雑にしてしまう構成は求めないで下さい。HTMLはお使いのHTMLエディタで生成したものをコピーして貼り付けてください。リマインダー送信を1日に行いたくない場合はMDaemon.iniで次の設定を行います: "[Special] ListReminderDay=X" Xは1から28までの数字へ置き換えて下さい。(カレンダーの計算式と連動してはいないので30や31は使わないで下さい。)

[13242] メーリングリストのReply-Toの値の設定を拡張しラジオボタンで簡単に(1)Reply-Toを変更せずにそのままにする (2)Reply-Toへメーリングリスト名を使用する (3) Reply-Toへ任意のアドレスを使用する のどれかを選択できるようにしました。

[13263] SMTPサーバーのアップデート

MDaemonのSMTPサーバーで複数のアップデートを行いました。

[13243] RFC 3463 (Enhanced Mail System Status Codes)に新たに対応しました。これらのコードでより高度なレポーティングや自動化が行えるようになります。このアップデートにより、拡張コードを埋め込むためにMDaemonのSMTPサーバープロトコルのストリングのほとんど書き換える事になりました。 その中で、コードの持ち方や呼び出し方を、よりシンプルで新しいものへとアップデートすることができました。また、RFC 2034 (SMTP Service Extension for Returning Enhanced Error Codes) に新たに対応しました。その結果、新しいESMTP拡張機能となるENHANCEDSTATUSCODESが追加されSMTP通信の中で、他のサーバーに対しても通知するようになりました。

[13264] RFC 3464 (An Extensible Message Format for Delivery Status Notifications) と RFC 6522 (The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages) に新たに対応しました。 これはMDaemonのDSNレポーティングと完全に置き換えられます。全ての古いコードや機能は削除され新しいものへ変更されます。この変更により、MDaemonのDSNシステムは完全に標準に準拠し、他のMTAが提供する自動化ツールとも正しく連携できるようになります。DSNのフォーマットは大きく変更し標準仕様に準拠しました。これは、配送時の警告メッセージや配信失敗メッセージはRFCで定義されたものを使うことになり、管理者がカスタマイズできないようになった、という事です。メッセージはローカライズはできてもカスタマイズはできません。メッセージの「件名」情報は変更できますが、推奨はしていません。DSNへ含まれるデータはMIME multipart/report形式となり、今後は元のメッセージを添付ファイルとして送信することはありません。代わって、仕様で推奨されている通り、元のメッセージのヘッダのみmultipart/reportメッセージのtext/rfc822-headers MIMEセクションへ含まれます。宛先MTAが対応している場合の拡張ステータスコードの送信など、レポートに関するほぼ全てのオプションコンポネントが実装されました。DeliveryWarning.datとDeliveryError.datを削除しました。 Ctrl+Q | DSNオプション画面をアップデートしました。編集ボタンを削除し、「配信不能のリストメール用DNSの生成しない」の古いオプションを削除しました。MDaemonは配信不能のメーリングリストメールにはDSNの生成は行いません。メールに含まれる各要素の用途や意味を知りたい場合は、RFCを参照してください。MDaemonはDSNへSession-IDとQueue-IDを付与します。Session-IDは実際の配送に使われたメールセッションや処理イベントを識別するために生成される機能的にユニークな値の事です(これは新機能ではなく、これまで特に使用されていなかっただけのものです)。Queue-IDはキューの中にあるメッセージファイルを識別するための機能的に重複のない値です(実際のファイル名です)。「機能的に重複のない」とは、実際には完全に個別に割り当てられたものではないものの、長い期間の間には重複する値を使う事がないため、現実的には重複する可能性がとても低いという意味で、重複することが完全にない事を保証するものではありません。

[13475] RFC 3848 (SMTP and LMTP Transmission Type Registration) に新たに対応しました。これはReceivedヘッダの「WITH」節の値に準拠します。つまり「ESMTP」は認証されておらずSSLではないセッション、「ESMTPA」は認証済セッション、「ESMTPS」はSSLセッション、「ESMTPSA」は認証済のSSLセッション、を示すことになります。MDaemon独自の「MULTIPOP」と「DOMAINPOP」はIANAレジストリでは定義されていませんが、今後も継続して使われます。

[13312] 送信者認証のアップデート

[13292] MDaemon SPFの実装を、最新仕様(RFC 7208)へアップデート:

セクション 4.6.4: DNSクエリで発生するSPF処理の上限数を定めました。次の文字列がDNSクエリに入ります:"include", "a", "mx", "ptr", "exists"メカニズムと"redirect"変換。また、各'A'レコードルックアップが"mx"メカニズムの中で最大10回となり、mxのカウント処理中に実行されるようになりました。10回に到達するとその後のSPF処理は停止し、SPF結果は破棄され、パーマネントエラーが仕様に基づき記録されます。セクション 4.6.4: "ptr"リソースレコードのカウントが10回に制限されますが、10回を超えたものは単純に無視され、仕様に基づきパーマネントエラーの生成は行いません。

セクション 4.6.4: "void"ルックアップ回数に上限を定めました。(a)ドメインが存在しない場合 (b)応答がない場合のルックアップ回数は、仕様として定義されています。SPF処理でこの上限に達すると、仕様に基づきパーマネントエラーが生成されます。新しいCtrl+S | 送信者認証 | SPF検証の画面にてvoidルックアップの回数を何度まで許可するか設定する事ができます。これは2回以下に設定する事はできません。

セクション 9.1: ABNFがReceived-SPFヘッダ用にアップデートされたため、多少の変更が必要になりました。また、「mechanism」キーを追加し、どのメカニズムに一致したのかを確認できるようになりました。タイミングによってどのメカニズムにもマッチしない場合は「default」というストリングが呼び出される点にご注意下さい。また、9.2ではAuthentication-Resultsヘッダ(RFC 7001)の使用方法についてのガイドラインを説明しており、対象のヘッダもこれに伴ってアップデートされました。

結果としてAuthentication-Resultsが改良され、MDaemonは今後 X-MDPtrLookup-Result, X-MDMailLookup-Result, X-MDHeloLookup-Resultのヘッダの生成を行わなくなります。これらヘッダは受信メールから取り除かれ、MDaemonでも今後生成したり、使用することはなくなります。

[13313] MDaemonの「Message Header Field for Indicating Message Authentication Status (RFC 7001)」の実装部分をアップデートしました。最新の仕様はAuthentication-Resultsヘッダに準拠する事になっています。これによりAuthentication-Resultsヘッダのフォーマットへ変更が加えられ、以前と大きく違うものになりました。PTR, HELO, MAILの逆引きはRFC 7001 (例: 区別するためのコメント付きPTR, HELO, MAIL用iprev及びpolicy.iprev)に基づきABNFを使用する事となりました。また、複数個所で不適切に使われていたptypesとその値を修正しました。また、ヘッダテキストの中でDNSのルックアップの失敗によっては矛盾を引き起こすものを幾つか見つけたため、それらの修正を行いました。

[13314] "Authentication-Results Registration for Vouch By Reference Results (RFC 6212)"を実装しました。私はVBRの著者の一人ではありますが、RFC 6212を定義した友人Murrayへ、VBRの結果をAuthentication-Resultsヘッダを使って標準化する話をしていませんでした。そのせいで私は3年間ブラックホールにいることになったのです。MDaemonはRFCに準拠し、複数のVBRホストが使用された際、Authentication-Resultsへ複数のVBRセクションを設けるようになりました。

[13316] "Authentication-Results Registration for Differentiating among Cryptographic Results (RFC 6008)"を実装しました。 このことで各DKIM署名が標準化された方法で付与されることになりました。これまでMDaemonは全ての署名結果を記録しておらず、結果として署名の結果は仕様に準拠したものではありませんでした。MDaemonはRFCに準拠し、複数のDKIM署名が使用された際、Authentication-Resultsへ複数のDKIMセクションを設けるようになりました。

[13315] Ctrl+S | 送信者認証 | VBR証明書へ新しいオプションを追加し、VBR-Infoヘッダを持たない受信メールに対してもVBR検証を強制するようになりました。通常このヘッダは必須ですが、なかったとしてもVBRは正しく機能します。ヘッダがない場合MDaemonは"all"メールタイプとしてVBR認証局へ問合せを行います。このオプションはこれまでのバージョンでも存在していましたがUIにはないものでした。また、これまでのバージョンでこの設定はデフォルト値を有効としていましたが、クエリとして保存するため、このデフォルト値を無効にしました。必要に応じてこのオプションを有効にしてください。また、これまでのバージョンでは、こうした状況ではデフォルトの認証局(MDaemonのサービスであるvbr.emailcertification.orgです)を使用していましたが、今後は信用するVBR認証局それぞれに対して問合せるようになります。spamhausはVBRのDWLリストから削除されましたのでご注意下さい。 http://www.spamhauswhitelist.com/en/usage.html で詳細と使用法をご確認頂けます。コンプライアンスの中でSpamhausの利用が必要など、MDaemonでこのリストを使いたいという場合には、Ctrl+S | 送信者認証 | VBR認証局 で信頼する認証局の一覧へ追加してください。

[13139] MDaemonのDKIM実装を最新の仕様(RFC 6376)に合わせてアップデートしました。また、DMARCの失敗レポートでオプションとして使用されるヘッダと本文の標準化されたデータを別途保持する機能を追加しました。さらに、Authentication-ResultsヘッダへRFC 5617で定義されているADFP処理の結果を追加するようになりました。最後にRFC 6651はlibdkimのアップデートを必要とします。Ctrl+S | 送信者認証 | DKIMオプションへ送信時の署名としてRFC 6651 "r=y"タグを追加するオプションを搭載しました。これによりDKIM失敗レポートは別処理されることになります。こうしたレポートを受け取るには、DNSのTXTレコード内でのDKIMレポートやADSP TXTレコードのアップデートが必要です。シンタックスやDKIM検証に失敗したメッセージの処理についての詳細はRFC 6651を参照してください。正しく設定していれば、DKIM検証に失敗した際、AFRF失敗レポートが外部のソースから届く事になります。これはDNSの設定が必要になるため、デフォルトでは無効に設定されています。また、Ctrl+S | 送信者認証 | DKIMオプションへRFC 6651 "rs="タグに準拠するかどうかを指定するオプションを追加しました。このタグで、外部のドメイン所有者はSMTP拒否のストリングをカスタマイズできるようになり、MDaemonではこのドメインに関するDKIM処理の結果としてそうしたストリングを確認できるようになります。このストリング空白や数字から始まる事や、\r, \n, \tを含む事はできません。こうした文字列を使った場合はMDaemonはこれらを無視しますが、それ以外は正常動作します。この設定はデフォルトで有効です。MDaemonがDKIMに関わるSMTP拒否で具体的にどういったエラーを返しているのか、第3者に知られる事に抵抗を感じる場合は、この設定を無効にしてください。通常、ここでのメッセージは「550 5.7.0 Message rejected per DKIM policy」といったものです。カスタマイズされたストリングが(存在している場合で、且つ)使用されていた場合は「550 5.7.0」の部分のみがそのまま表示されます。

変更点と新機能

修正点

MDaemon 14.0.3 - 2014年7月15日

変更点と新機能

修正点

MDaemon 14.0.2 - 2014年 5月14日

修正点

MDaemon 14.0.1 - 2014年 5月13日

特記事項

 変更点と新機能

修正点

MDaemon 14.0.0 - 2014年 3月25日

特記事項

主な新機能

[12504] 新しいWorldClientテーマ (MDaemon PROが必要です)

見た目最新のブラウザベースのメールクライアントに対するニーズへの答えるため、新しいテーマとなるWorldClientを搭載しました。この新しいテーマは世の中の個人・ビジネス向けのウェブメールクライアントのデザインを元に、専任のUI/UX開発チームによってデザインされました。

この新しいWorldClientテーマは新規インストールの際にはデフォルトのテーマとなります。アップデートの場合は、インストーラーが、デフォルトテーマをこの新しいテーマへ変更するかどうかを確認します。

[12091] ActiveSyncサーバーが共有フォルダに対応 (MDaemon PROとActiveSyncソフトウェアライセンスの更新が必要です)

MDaemonのActiveSyncサーバーが、個人フォルダとパブリックフォルダに加え、他のユーザーの共有フォルダに対応しました。エンドユーザーがActiveSyncプロトコルを使って共有フォルダへアクセスする際の動きは端末により多種多様です。そのため、MDaemonのActiveSyncはメール、予定、連絡先、仕事、メモに対応していますが、全てのクライアント側の端末でこれらのデータを取り扱えるとは限りません。

[12723] MDaemonのGUIからActiveSyncの共有フォルダを全体(F2 | サーバー設定 | パブリック&共有フォルダ 及び Alt+M | ActiveSync |オプション)、ドメイン単位(Alt+F2 | ドメイン設定 | オプション)、アカウント単位(アカウントエディタ | メールサービス)で有効化・無効化する事ができるようになりました。「継承」とはドメインやアカウントが、上位である、全体またはドメインで設定された値を使用するという意味です。

変更点と新機能

修正点

MDaemonn は、 MDaemon Technologies, Ltd の登録商標です。
Copyright 1996-2014 MDaemon Technologies, Ltd.