九州大学における組織別運用メールサービスのクラウド集約への取り組み
嶋吉 隆夫 1) , 笠原 義晃 1) , 平川 新 2) , 亀岡 謙一 2) , 平野 広幸 2) , 藤村 直美 1)
1) 九州大学 情報基盤研究開発センター
2) 九州大学 情報システム部
simayosi@cc.kyushu-u.ac.jp

Takao Shimayoshi1) , Yoshiaki Kasahara1) , Arata Hirakawa2) ,Kenichi Kameoka2) , Hiroyuki Hirano2) , Naomi Fujimura1)
1) Research Institute for Information Technology, Kyushu University
2) Information Systems Department, Kyushu University

概要
九州大学では、全構成員に全学基本メールアドレスを割り当て、クラウドメールサービスである Microsoft
Exchange Online を利用して全学基本メールサービスを提供している。一方、過去の経緯から、学内の部局や学科、研究室などで、割り当てられたインターネットドメインを用いて、内部組織別のメールサービスが独自に運用されている。しかし、近年はメールサービスの運用には、セキュリティ対策についての最新知識やコストが必要とされる。そこで、九州大学情報統括本部では、学内組織による独自運用メールサービスを集約し、全学的なシステム運用コストを削減するとともにセキュリティを向上することを目的として、メールサーバ集約タスクフォースを発足させ、活動を行っている。本稿では、本タスクフォースがこれまでに進めてきた、集約方法の検討、必要システムの設計と構築、および、サービス提供について報告する。

1 はじめに九州大学情報統括本部では、全構成員に全学基本独自にメールサービスを運用するインターネットドメ
インを「組織ドメイン」、組織ドメインをドメインとするメールアドレスを「組織アドレス」と呼ぶ。

メールサービスを提供しており [1]、全学認証基盤

近年は、フィッシングメールによるパスワード等の[2] から配信される構成員の登録姓名に基づき、ドメ詐取、メール添付ファイルによるマルウェアの配送、インが学生は s.kyushu-u.ac.jp，教職員は m.kyushu-

標的型攻撃、ビジネスメール詐欺など、電子メールがu.ac.jp とする全学基本メールアドレス（以下，全学ア

サイバー攻撃の主要な手段として用いられている [5]ドレス）を一律に提供している。現在、全学基本メー

ことから、電子メールサービスの運用では適切なセルサービスには、クラウドメールサービス Exchange

キュリティ対策、対応が必要不可欠である。しかし、Online を利用している [3]。また、全学基本メールサー

適切なセキュリティ管理には、多大な管理労力、またビスの利用者アカウントは、全学認証基盤により管理は、運用経費を必要とする。それゆえ、学内で多数のされる全学共通アカウント SSO-KID[4] を利用して認独自メールサービスが運用されている現状は、大学全証している。

体として見たときに非経済的かつ非効率的であるとと一方、九州大学では本学インターネットドメインもに、セキュリティ上の問題もはらんでいる。

kyushu-u.ac.jp のサブドメインを、申請に応じて部局

そこで、九州大学情報統括本部では、学内組織による等に割り当て、DNS レコードの管理を委譲しており、独自運用メールサービスを集約し、全学的なシステム

部局等では、さらにそのサブドメインを学科や研究室運用コストを削減するとともにセキュリティを向上すなどの内部組織に割り当てている。そして、それらのることを目的として、メールサーバ集約タスクフォー

サブドメインをドメインとする電子メールアドレスをスを 2018 年 11 月に発足させた。本タスクフォースで利用するために、各学内組織で独自に電子メールサーは、これまでに、メールサービスの集約方法を調査、ビスが運用されている。以下、本稿では、学内組織が検討したのち、集約に必要となるシステムを設計、構築し [6]、集約のための新たなサービスを提供開始して、未知のマルウェアや有害リンクへの対応機能が利た。本稿では，メールサービス集約タスクフォースの用可能になった。

これまでとこれからの取り組みについて述べる。

2 九州大学メール環境の経緯と現状

上述の歴史的経緯により、多くの教員は組織アドレ
スを主たる連絡先メールアドレスとして用いており、学術論文などの出版物や名刺などに組織アドレスを掲

九州大学情報統括本部では、2009 年 7 月に教職員載している。実際、本論文に掲載している連絡先メーを対象に全学基本メールサービスの提供を開始した

ルアドレスも、全学アドレスではなく組織アドレスで[1, 7]。それまで、全教職員を対象とした共通のメーある。メールアドレスは全世界で一意な一種の個人識

ルサービスは提供されていなかった。2014 年までの別子である。全学アドレスとは違い、組織アドレスでサービスでは、各利用者のメールボックスの容量はあれば、ドメインにより所属組織を示すことができ、300 MB に限定され、また、メールボックス内のメー一般にユーザ名と呼ばれるローカルパートはある程度

ルは 90 日後に自動削除された。当時のサービスの主自由に選べることも多い。また、全学アドレスは構成な目的は、緊急時などに全教職員への連絡や情報提供員だけに割り当てられるものであるのに対して、組織を行うためであり、利用者に主たるメールボックスをアドレスは客員教授や訪問研究員などの学外者に発行提供するものではなく、主に他のメールアドレスに転される場合もあり、さらには、個人ではなく、業務上送されることを想定していた。それゆえ、2014 年までの役職や掛などのほか、プロジェクトなどに対して組は、学内組織が独自にメールサービスを運用する必要織アドレスが割り当てられることも多く、また、メーがあった。情報統括本部では、全学基本メールサービ

リングリストシステムが運用されていることも多い。

スとは独立に、2008 年から有償のホスティングサービ

組織ドメインのメールサービスには、メールサーバ

スを提供しており、現時点では 200 以上の組織ドメイを学内組織が独自に管理して運用しているものがあンが独自メールサービスを運用するためにホスティンる。一部の大規模部局などではメールサーバの運用保グサービスを利用している。その後、2014 年に学生向守を業者に外注している例もあるが、大部分のメール

けメールサービスが全学基本メールサービスに統合さサーバは、運用保守の経費や人員を確保することなく、れた際に、メールの保存期限は廃止され、メールボッ教員等が業務の傍らボランティアベースで管理されてクス容量も大幅に増強された。

いる。そのような事情もあり、独自運用のメールサー2018 年 12 月には、オンプレミスメールシステムかバでは、ソフトウェアの既知の脆弱性を放置したままら、Microsoft が提供するクラウドサービス Oﬃce 365

サーバが運用されている場合や、管理者の異動などに（現 Microsoft 365）Education に含まれるメールサーより管理者不在のままサーバが稼働している場合なビスである Exchange Online へと移行した [8]。このどがあり、実際に、アカウント不正利用によるメール移行は、前システムの保守期限切れに伴い、同規模シス送信や、サーバへの不正アクセスなどのセキュリティテムの構築費用が確保できないことを理由とするもの事案が頻発している。近年は特に、メールサーバのセだったが、結果的にサービスの利便性とセキュリティキュアな運用には高度な知識が必要とされるので、片の向上に繋がった。移行時点で、各利用者のメール手間での運用は困難である。

ボックス容量は 10 GB から 50 GB に増加した。また、上述の通り、メールサービスをホスティングサービ

前システムでは専用にオンプレミスのメールセキュリスを利用して運用している組織ドメインも非常に多ティ対策機器を使用していたが、Exchange Online はい。ホスティングサービスのサーバは情報統括本部標準でセキュリティ機能 Exchange Online Protectionにより適切にセキュリティ保守が行われている。しかが提供され、送受信スパム検出、バルクメールフィルし、サービスの設定や、メールアカウントの管理は組タ、有害 URL ブロックリスト、フィッシング対策、ス織ドメインの管理者に任されている。それゆえ、類推プーフィング対策、マルウェア対策などが含まれてい可能な初期パスワードが設定されたままになっている

る。さらにその後、2020 年 5 月からは、Microsoft との場合や、異動や退職などにより不必要になったアカウ

包括契約 Enrollment for Education Solution (EES)

ントがメール送信可能なまま放置されている場合などの更新に伴い、Microsoft 365 A3 および Oﬃce 365があり、ずさんなアカウント管理に起因するアカウン

Advanced Threat Protection が含まれることになり、ト不正利用が多数発生している。

メールボックス容量が 100 GB に増加するのに加え3 集約方針の検討
3.1

組織アドレスの継続性

独自運用メールサービスの集約を考えるとき、非常に重要な問題として、既に利用されている組織アドレスの扱いがある。メールサービスの集約に伴い全学アドレスへと集約して組織アドレスを廃止する可能性

ルサービスで扱うインターネットドメインとして組織ドメインを追加し、組織アドレスが割り当てられた各構成員は、全学基本メールサービス上で組織アドレスを送受信できるようにする。

4 メール集約の実現
4.1

Exchange Online の仕様についても検討した。しかし、教員の多くは組織アド

九州大学の全学基本メールサービスが利用する Ex-レスを利用しており、研究者の場合は特に、出版されchange Online の機能および制約について説明する。

た論文に掲載されたメールアドレスは、可能な限り継ただし、以下の記述は検討時点での仕様に基づいてお続してメールが到達可能であることが求められる。まり、その後変更されている場合があることに注意された、個人以外に割り当てられた組織アドレスは、そのたい。

ままでは全学基本メールサービスには集約できない。

Exchange Online では、利用者組織に 1 個のテナそれゆえ、既存の組織アドレスは継続して送受信に利ントと呼ばれる管理単位が割り当てられる。テナン用でき、また、新たな組織アドレスの発行も許容する

トには複数のインターネットドメイン名を登録でき、方針とした。

メールアドレスに利用できる。九州大学の全学基本管理主体

メールサービスが利用するテナント（以下、全学テナ

3.2

組織ドメインから組織アドレスが割り当てられていント）では、全学基本メールサービスで利用するドメる構成員は、全学アドレスだけでなく複数のメールアイン名だけでなく、九州大学全体のドメイン名であるドレスを利用可能であり、状況に応じてメールアドレ

kyushu-u.ac.jp を登録している。利用者アカウントのスを使い分ける必要がある。これを単純に実現するに管理および認証には、Azure Active Directory（以下，は、メールアドレスごとにアカウントを発行する方法

Azure AD）が用いられる。利用者アカウントはテナがあるが、その場合、利用者が複数アカウントを管理ント全体の管理権限を持つサービス管理者（以下、テする必要があり、利便性やセキュリティ上の問題があナント管理者）だけが管理できる。テナント管理者はる。また、前述の通り、各組織が独自に管理するアカ全ての登録ドメインの全アドレスを管理でき、管理権ウントではセキュリティ事故などが頻発している。一限の対象を一部のアカウントやドメインなどに制限す方で、全学基本メールサービスが用いている全学共通ることはできない。

アカウントは、情報統括本部により適切に管理され、個々の利用者アカウントに複数のメールアドレス不正利用などが検知された場合は即座にアカウント停を登録でき、登録アドレス宛のメールは同一のメール止するなどの対応を行っている。これらのことから、ボックスに配送される。しかし、メール送信では、利集約された組織アドレスについても全学共通アカウ用者アカウントに「プライマリ SMTP アドレス」としントを用いて認証することを、集約実現の前提条件とて登録された単一メールアドレスしか、From フィーした。

ルドに利用できない。それ以外の「セカンダリ SMTP

一方、組織アドレスは、学生の研究室配属や教職員アドレス」は受信専用である。の着任、プロジェクト立ち上げなどに応じて発行すメンバーとして登録された複数のメールアドレスる必要があり、また、学外者などに一時的に発行するにメールを転送できる「配布グループ」という機能が場合もある。それらに対して情報統括本部で個別に対あり、一般的なメールサーバにおけるメールエイリア応することは、運用管理負荷の観点から事実上不可能

ス機能と同等な転送アドレスを作成できる。また、利である。そこで、組織アドレスについては、組織ドメ用者アカウントに対して「SendAs 権限」を付与する

イン管理者による発行、変更、削除を実現することとことで、権限付与した配布グループのメールアドレスした。

を、送信メールの From フィールドに利用できる。既3.3

基本方針

定では全ユーザーが配布グループを作成できる。配布

上記の検討の結果、学内組織が独自運用するメール

グループ作成権限を一部アカウントに制限できるが、サービスを、全学基本メールサービスへと統合するこ

作成権限を持つアカウントは任意の登録ドメインにつとにより、集約を実現することとした。全学基本メー

いて配布グループを作成できる。九州大学の全学テナ

全学基本メールサービス Exchange Onlineテナント
組織ドメイン組織ドメイン
deptA.kyushu-u.ac.jp

deptB.kyushu-u.ac.jp

管理

管理

Azure Storage

ウェブアプリ取得

情報取得
認証 権限情報取得

設定

呼び出し
fn 投⼊
fn
REST API エンドポイント タスクキュー ワーカー
組織ドメイン管理者
RESTウェブサービス / Azure Functions

s.kyushu-u.ac.jp / m.kyushu-u.ac.jp

図1

Exchange Online

静的ウェブサイト

全学アドレス

メールアドレス

Azure AD

メールボックス

図 2 システム概略図

実現方式の概要

イン別の管理者用セキュリティグループを作成し、組ントでは、配布グループの作成権限をテナント管理者織ドメイン管理者の全学アカウントを登録することでだけに制限している。単なる転送だけでなく、メール実現する。

ヘッダの追加・変更などを行うようなメーリングリス
トの機能は提供されていない。

4.2

実現方式

Exchange Online にはメーリングリスト機能はない
が、独自運用メールサービスをなくすためにはメーリングリストの提供は必須である。そこで、新たにメー図 1 に、組織ドメインを全学基本メールサービスリングリストサーバを構築して提供することにした。

へと集約する方式の概要を示す。まず、集約対象のこのサーバには、専用ドメイン ml.kyushu-u.ac.jp 宛

組織ドメインを全学テナントに登録して、Exchangeメールを Exchange Online 経由で配送するように設Online テナントが組織ドメインを処理できるように定した。メーリングリストに組織アドレスを割り当てする。4.1 節で説明したように、セカンダリ SMTP ア

たい場合は、上記の配布グループを用いて組織アドレドレスは送信に利用できないことから、組織アドレススから専用ドメインのアドレスに転送することで実現は配布グループとして登録する。各組織アドレスにつできる。

いて、個人用、グループ用に関わらず、配布グループ

4.3

組織アドレス管理システムを作成し，転送先アドレスを配布グループのメンバー組織ドメイン管理者に組織アドレスの管理を委譲すとして登録する。個人用の組織アドレスには、メンるために、組織アドレス管理システムを設計、開発しバーとして全学アドレスを登録することで、組織アドた [6]。本システムは、システム運用者である情報統括レス宛メールが全学アドレスのメールボックスに配送本部の運用負担が少ないことを最重視して設計した。

される。さらに、メンバーとして登録された転送先ア

また、Exchange Online の仕様は利用者に断りなく変ドレスが全学アドレスである場合には、対応するアカ更される場合があり今後の改修が必要になる可能性がウントに配布グループに対する SendAs 権限を付与す高いこと、予算上の都合によりシステムを段階的に開る。これにより、本学構成員は組織アドレスを From発・拡張していく必要があったことから、保全性や拡フィールドに指定したメール送信が可能である。一張性を重視した。

方、本学構成員ではない組織アドレス利用者は、組織本システムには、計算機や仮想機械、基盤ソフトアドレスを From フィールドに指定した正当なメールウェアなどの保守、管理を要しないサーバレス構成を送信はできない。

採用し、保全性と拡張性を考慮してマイクロサービス

4.1 節で述べた通り、Exchange Online では、ある組アーキテクチャを採用した。システム構成を図 2 に織ドメインに限定して配布グループの管理権限を付与示す。システムは、Function as a Service (FaaS) のすることはできない。そこで、組織ドメイン管理者にAzure Functions、Platform as a Service (PaaS) の組織アドレスの管理を委譲するために、後述の組織ア

Azure Storage により構成され、Software as a Ser-ドレス管理システムを導入した。このシステムでは、

vice (SaaS) である Exchange Online と Identity as

組織ドメイン管理者が、管理対象の組織アドレスに限a Service (IDaaS) である Azure AD と連携して動作定して配布グループを作成、変更、削除できる。組織する。

ドメインの管理者への認可は、Azure AD 上に各ドメ

Azure Functions 上に REST ウェブサービスを構築し、Azure AD を利用して OAuth 2.0 による認証から検証用の組織アドレスを発行してもらい、情報統を行い、組織ドメイン管理者に、組織アドレスに対応括本部がそれを用いてセルフサービスサインアップをする配布グループの作成、取得、更新、削除の機能を、試みる。セルフサービスサインアップが成功した場合

REST API として提供する。Azure Storage を用いたは、組織ドメインの DNS に指定の TXT レコードを静的ウェブサイトに配置されるウェブアプリケーショ設定してもらうことで、検証用組織アドレスに自動生ンは、クライアント PC 上のウェブブラウザで実行さ成テナントの管理権限を取得した上で、セルフサービれ、REST API へのユーザインタフェースを提供す

スサインアップ登録されているメールアドレス一覧をる。このシンサーバ構成により運用保守コストが大幅組織ドメイン管理者に連絡して対処を依頼する。に削減される。

5.2

4.4

提供サービスの検討

ドメイン登録処理

情報統括本部において、前段階で自動生成テナント組 織 ド メ イ ン を 全 学 基 本 メ ー ル サ ー ビ ス の Ex-が存在した場合は組織ドメインを登録解除した後、組change Online に受け入れるサービスは、「全学基本織ドメインを全学テナントに登録する。通常は、組メールサービス 組織利用サービス」として提供してい織ドメインの正当な所有者である事を証明する確認る。サービス提供には、前述の組織アドレス管理シス作業が必要となるが、九州大学の全学テナントではテムやメーリングリストサーバの運用保守が必要にな

kyushu-u.ac.jp を登録していることから、組織ドメイること、全学共有の Exchange Online リソースを利用ンの所有権確認は不要である。

すること、全構成員が等しく利用するサービスではな

組織ドメイン deptA.kyushu-u.ac.jp を登録した時いことなどから、受益者負担を伴う有償サービスとし点では、全学テナントに組織アドレスは未だ存在して提供することとした。利用料金は、登録された組織ないため、既存の組織アドレス宛に全学テナントかアドレスの個数、および、メーリングリストの個数にらメールを送信すると宛先なしのエラーとなる。そこ応じて実数精算により年度ごとに請求する。集約を促

で、組織ドメイン登録次第速やかに、先ほど登録した進する観点から戦略的に、ホスティングサービスより組織ドメインを Exchange Online で「内部の中継」にも安価な料金に設定した。

設定することで、deptA.kyushu-u.ac.jp 宛のメールが5 組織ドメイン移行手順

DNS の MX レコードを参照して mx.deptA.kyushuu.ac.jp へ配送されるようにしなければならない。ただ組 織 ド メ イ ン の 既 存 の メ ー ル サ ー ビ ス を「 全 学し、テナントへのドメイン登録が Exchange Online に

基 本 メ ー ル サ ー ビ ス 組 織 利 用 サ ー ビ ス 」へ と 移反映されるまでに数分程度の時間が掛かる場合がある

行 す る と き の 手 順 に つ い て 以 下 に 説 明 す る 。こ こ

ので、PowerShell を用いて登録確認と中継設定を自動で は 、集 約 対 象 の 組 織 ド メ イ ン を deptA.kyushu-処理する。それでも、一時的な宛先不明エラーは発生

u.ac.jp、集約前の deptA.kyushu-u.ac.jp の MX ホス

しうるので、全学テナントから deptA.kyushu-u.ac.jp

トを mx.deptA.kyushu-u.ac.jp とする。

宛に送信を試みて失敗したメールがないか確認が必要

5.1

ドメイン登録確認である。なお、詳細は不明だが設定変更が巻き戻って組織ドメインがどの Microsoft 365 のテナントにもしまう事例も経験しているので、注意が必要である。

登録されていない場合、各個人がセルフサービスサ

そこで、設定作業後何回か時間をおいて、検証用の組インアップにより、教育機関のメールアドレスの場織アドレス宛に全学テナントからメールを送信して、合は無償で、Microsoft 365 の利用を開始することが問題なく受信されるかを確認する。

できる。このとき、組織ドメインが登録されたテナ

5.3

MX レコード変更ントが自動的に作成される。九州大学では、全学基本

組織ドメイン宛メールが全学基本メールサービス

メールサービスを Exchange Online に移行した際に、に届くようにするには、組織アドレスを Exchange

kyushu-u.ac.jp 配下のインターネットドメインでは新Online に登録することになるが、組織ドメインの MXたにセルフサービスサインアップできないようになっレコードを Exchange Online へと切り替えるまでは、たが、それ以前にセルフサービスサインアップに使わ全学テナントからのメールは Exchange Online に、それていた組織ドメインについては、既に自動生成テナ

れ以外からのメールは mx.deptA.kyushu-u.ac.jp に届ントに登録されており、全学基本メールサービスのテくことになり、逐次的に組織アドレスを移行したい場ナントに登録できない。そこで、まず、組織ドメイン合に不都合が生じる。そこで、組織アドレスの登録に先立って、組織ドメインの MX レコードを ExchangeOnline へと変更する。

5.5

終了処理

全ての必要な組織アドレスが Exchange Online に

まず、情報統括本部において、deptA.kyushu-u.ac.jp

登録されれば移行は完了である。ただし、先に作成しドメイン宛のメールを、MX レコードの設定にかかわた送信コネクタによって、宛先不明のメールは全てらず既存サーバ mx.deptA.kyushu-u.ac.jp に配送すmx.deptA.kyushu-u.ac.jp に転送されるままである。

るために、Exchange Online に送信コネクタを作成す

そこで、組織ドメイン管理者から移行完了の報告を受る。この作業により、Exchange Online に存在しない

けた後、情報統括本部において、Exchange Online で

組織アドレスについては、mx.deptA.kyushu-u.ac.jp

送信コネクタを削除し、組織ドメインを「内部の中継」に中継されるようになる。なお、Exchange Online へから「権限あり」に設定変更する。この作業により、宛の設定変更は、本処理に限らず、Exchange Online シ

先不明エラーは Exchange Online が返すことになる。

ステム全体に設定が反映されるまで 1 時間程度要する

なお、組織ドメインがホスティングサービスを利用ことがあるので、送信コネクタは事前に無効状態で作していた場合は、追加の注意点がある。ホスティング成しておき、ドメイン登録後に有効化する。

サービスに組織ドメイン deptA.kyushu-u.ac.jp が登そ の 後 、情 報 統 括 本 部 に お い て 登 録 ド メ イ ン

録されていると、同じホスティングサービスを使っdeptA.kyushu-u.ac.jp に割り当てられた MX レコーている利用者が deptA.kyushu-u.ac.jp 宛に送信した

ド 用 の FQDN を 取 得 し 、組 織 ド メ イ ン 管 理 者 にメールは、Exchange Online ではなくホスティング依頼して MX レコードを変更する。なお、MX レサービスのメールボックスに配送され、組織アドレス

コ ー ド だ け で な く 、TXT レ コ ー ド の SPF 設 定 なの利用者は両方のメールボックスを確認する必要があ

ど も 併 せ て 設 定 し て お く 。MX レ コ ー ド の 設 定 変る。そこで、移行完了後は速やかにホスティングサー

更後は、deptA.kyushu-u.ac.jp 宛のメールは、直接ビスから deptA.kyushu-u.ac.jp を削除する必要があ

mx.deptA.kyushu-u.ac.jp に届くメールを除き、Ex-る。ただし、組織ドメインを削除すると以前のメール

change Online を経由する。

ボックスにアクセスできなくなる。この状況の対処と組織アドレス登録して、例えば、各利用者が事前にホスティングサービ

5.4

まず、情報統括本部において、組織ドメインの管理権限を管理するための管理者グループを Azure AD 上で作成し、組織ドメイン管理者の全学アカウントをメンバーとして登録する。このとき、管理者グループにス側で全学アドレスへの転送を設定しておくなどの方法が考えられる。

6 経過と今後は、組織ドメインと一意に相互変換できる名前を設定

まず、2019 年 11 月から 12 月にかけて、本稿 4.2する。この作業により、組織ドメイン管理者が、組織節で述べた集約の実現方式を用いたテストケースとしアドレス管理システムを利用可能になる。て、九州大学の 1 部局について独自にサーバ運用してこの段階から、組織アドレス管理システムを用いていた組織ドメイン 2 個のメールサービスを Exchange

組織アドレスを登録すれば、組織アドレス宛メールはOnline へと手動で移行した。それと並行して、4.3 節

Exchange Online が受信するようになるが、その前にで述べたシステムを 2019 年度内に構築した。ただし、確認が必要な事項がある。ある組織アドレスから転送管理者用ウェブアプリケーションについては、予算上される全学アドレスにおいて、その組織アドレス自身の制約から、必要最低限の機能として特定形式の CSVへの転送が設定されていた場合、メールのループが発ファイルにより処理を行う機能だけを実装しており、生し、特にメッセージを保持しない転送設定のときは、CSV ファイルはウェブアプリケーション外で準備すメールロストが発生する。そこで、組織アドレス登録る必要がある。に先立って、組織アドレス管理者から、組織アドレス

Exchange Online には、共有メールボックスといの転送先として設定する全学アドレスの一覧を提出しう、複数のユーザアカウントで共有できるメールボッてもらい、情報統括本部において、自分自身への転送クスを作成する機能がある。組織利用サービスの利用が設定されていないかを確認し、存在する場合は組織者や利用予定者から、この共有メールボックス機能をドメイン管理者から転送設定の解除を依頼する。

使いたいという強い要望が寄せられていることから、今年度中に組織アドレス管理システムの改修による機能追加を実施し、来年度初頭から組織利用サービスでの提供を計画している。

[6] 嶋吉隆夫, 笠原義晃, 清家史郎, 藤村直美. 九州大学

当初の予定では、2020 年 4 月より組織利用サービスにおける独自運用メールサービス集約のためのシを提供開始する予定だったが、COVID-19 対応の影響ステム開発. 情報処理学会研究報告インターネットもあり、2020 年 7 月からサービス提供を開始した。筆と運用技術（IOT）, 第 2020-IOT-50 巻, pp. 1–8,者らが所属する情報基盤研究開発センターの組織ドメJuly 2020.

インについても、独自運用サーバから移行した。サー[7] 伊東栄典, 笠原義晃, 藤村直美. 九州大学における

ビス提供開始直後は、Exchange Online の挙動などで職員向け電子メールサービスの現状. 平成 21 年度

想定外の事項があり、数時間にわたって組織ドメイン

情報教育研究集会, pp. D3–4, September 2009.

宛メールが不達になるなどの問題も生じたが、現在は[8] Yoshiaki Kasahara, Takao Shimayoshi, Ta-5 章で述べた手順により円滑に移行が行えている。今dayuki Miyaguchi, and Naomi Fujimura. Mi-

年度中には、大規模部局の組織ドメイン移行も予定さ

grate legacy email services in kyushu university

れている。また、ホスティングサービスのうち古いオ

to exchange online. In Proceedings of the 2019

ンプレミスサーバについては、2020 年 11 月に利用

ACM SIGUCCS Annual Conference, p. 127–131,

ソフトウェアがサポート終了となることから、その利

New York, NY, USA, 2019. Association for Com-

用ドメインのメールサービスは、新しいクラウドホス

puting Machinery.

ティングサーバか組織利用サービスに移行する必要があり、情報統括本部では組織利用サービスへの移行を推奨している。今後の課題として、学内で独自運用しているメールサーバの集約促進策の検討がある。

参考文献[1] Yoshiaki Kasahara, Takao Shimayoshi, Eisuke
Ito, and Naomi Fujimura. The past, current, andfuture of our email services in kyushu university.
In Proceedings of the 2018 ACM on SIGUCCS
Annual Conference, pp. 103–106. Association forComputing Machinery, 2018.
[2] Eisuke Ito, Yoshiaki Kasahara, and Naomi Fujimura. Implementation and operation of thekyushu university authentication system.

In

Proceedings of the 41st Annual ACM SIGUCCS
Conference on User Services, pp. 137–142. Association for Computing Machinery, 2013.
[3] 笠原義晃, 嶋吉隆夫, 宮口忠幸, 藤村直美. 九州大学
における電子メールサービスの Exchange Online
移行. 大学 ICT 推進協議会 年次大会論文集, pp.

22–29, 2019.
[4] 菅尾貴彦, 戸川忠嗣, 太田美和, 橋倉聡, 平野広幸,伊東栄典, 市川広大, 先立英喜. 全学共通認証基盤
サービスの手続きの電子化について. 第 30 回 全国
共同利用情報基盤センター 研究開発連合発表講演
会研究開発論文集, pp. 77–86, 2008.

[5] Verizon. 2020 data breach investigations report.
Technical report, Verizon Communications Inc.,
2020.