Help us understand the problem. What is going on with this article?

i-FILTER×m-FILTER連携時の自動作成パーツについての注意点

More than 1 year has passed since last update.

検証時のメモ

以下検証環境にて実施

■環境
 i-FILTER Ver.10.20R01-20181016
 m-FILTER Ver.5.11R01-20180802

i-FILTER×m-FILTER連携を有効化すると自動的に以下URLリストと識別名リストが作成される。

*m-FILTER連携URLリスト(完全一致)
*m-FILTER連携URLリスト(部分一致)
*m-FILTER連携デコードリスト(完全一致)
*m-FILTER連携デコードリスト(部分一致)

この4つのパーツだが、参照ロック及び編集ロックが解除されておりどの権限のユーザでも編集ができてしまう。

それを避けるために参照ロック及び編集ロックをするため、ルールパーツの*を外してパーツを保存してしまうとi-FILTER×m-FILTER連携が正常に動作しなくなる。

具体的にはパーツ名を変更してしまうとi-FILTER側はパーツがないため例外処理を返す。
その例外処理が返ってきた場合、m-FILTER側は未カテゴリ扱いをする結果、偽装メール対策機能側で偽装レベル3と強制的に判定される。
つまり偽装メール対策機能をデフォルトで運用している場合、URLがメールのどこかしらに記載がされた場合、そのメールすべてが隔離されてしまう。

困ったことにパーツの編集権限を持ったユーザが誤って変更すると恐ろしいことにURLが記載されたメールがすべてメールが隔離されメール不通状態となる。

マルチテナント的にグループ単位で権限を委譲している環境だと触らないように運用徹底が必要である。

もし変更してしまったことを能動的に知りたい場合はm-FILTERの「i-filter.log」ログから「-19」※の値をひっかけてログ監視をする必要があります。
※「-19」はURLリストがなかった場合のエラーコード

私は最初から触れないようにロックするか、そもそも変更できないようにすべきではないかと思います。(ロックだと全体管理者で設定変更できちゃいますし)
ユーザーってなんでかわからないけど普通ならやらないような設定を平気でやったりする方もいるので...

以上、検証結果でした。

Wreathlt_sumire
ネットワーク、サーバ系の初心者エンジニアです。 日々の業務で気づいたことや検証した事をまとめる予定
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away