九州大学における電子メールサービスの Exchange Online 移行笠原 義晃 1) , 嶋吉 隆夫 1) , 宮口 忠幸 2) , 藤村直美 1)
1) 九州大学 情報基盤研究開発センター
2) 九州大学 情報システム部
kasahara@nc.kyushu-u.ac.jp

Migrating Email Services in Kyushu University
to Exchange Online
Yoshiaki Kasahara1) , Takao Shimayoshi1) , Tadayuki Miyaguchi2) , Naomi Fujimura1)
1) Research Institute for Information Technology, Kyushu Univ.
2) Information System Department, Kyushu Univ.

概要
九州大学情報統括本部は、全構成員向けに「全学基本メール」という名称のメールサービスを提供している。直近のシステムはオンプレミスのサーバで運用していたが、2018 年度末で 5 年の運用期間が終了することになっていたため、リプレースが課題となっていた。本学は大規模なキャンパス移転を終えたばかりで予算が限られていたため、次期システムについては調達コストを削減する必要があった。一方本学は Microsoft EES の包括契約により 2016年度から Microsoft Oﬃce 365 を学内提供しており、Oﬃce 365 には Exchange Online が含まれていたことから、これを活用することでコスト削減を目指した。ただし、全学基本メールには Exchange Online 単体では提供されないいくつかの付加サービスがあったため、これらは別途調達する必要があった。2018 年度中に移行準備を進め、2018 年 12 月 18 日にサービスの切り換えを実施、2019 年 3 月末までに移行を完了した。また、同時期にオンプレミスの Exchange Server から Exchange Online への移行を検討していた事務用メールについても、同時期に全学基本メールと同じ Oﬃce 365 テナントへ移行することとなり、無事移行に成功した。本学には他にも部局サブドメインによるメールサービスが 100 以上存在しているが、近年メールサービスを安全に運用することが難しくなっていることから、事務用メールと同様に全学基本メールの Exchange Online に統合していく事を検討している。本論
文では、全学向けメールの Exchange Online 移行の計画と実際について述べるとともに、その他の学内向けメールサービスの統合について検討状況を述べる。

守期間が 2018 年度末で終了することから移行が必要

1 Introductionとなり、種々検討の結果 Microsoft Oﬃce 365 の一部

九州大学情報統括本部は九州大学の教職員と学生向である Exchange Online に移行することとなった [4]。

けに情報インフラと各種情報サービスを提供してい2018 年 12 月 18 日にサービスを切り換え、2019 年 4る。情報サービスの多くは全学認証基盤により管理さ月 3 日に旧サーバを完全に停止することができた。本れたアカウント情報で利用者を認証している。アカウ

論文では、全学基本メールの Exchange Online 移行のント数は約 3 万アカウント (教職員約 1 万、学生約 2計画と実際について述べるとともに、その他の学内向万) である。情報統括本部では「全学基本メール」とけメールサービスの統合について検討状況を述べる。

いう全学向けメールサービスを提供しており、全学認証基盤にアカウントのある構成員全員が利用できる[1, 2, 3, 4]。一方、九州大学には部局等で独立に管理・2 移行に向けた準備
2.1

移行先の決定運用されているメールシステムも多数存在する。これ

前全学基本メールのサーバシステム (以下「前シスらのメールシステムでは kyushu-u.ac.jp のサブドテム」) は 2014 年 3 月に本運用を開始した。基本的メインが利用されている。

なメールサービス部分は Linux 上で動作するオープン

全学基本メールは従来オンプレミスのサーバで運用ソースソフトウェアで必要な機能を構築した。運用期していたが、前システムで導入当初に設定した運用保間を 5 年として調達したため、運用期間が終わる前に

22

次期メールシステムを構築し、利用者の移行を完了す問合せを分散させることにした。Oﬃce 365 上で利用る必要があった。前システムと同様にサーバを構築し者に Exchange Online のライセンスを付与すること運用する案と、クラウドベースの商用メールサービスにより、メールサービスへのサインイン自体は可能とを利用する案を検討した。

なる。具体的には「Outlook on the web」(Exchange

新規にサーバを構築し 5 年間運用・保守する費用Online 用のウェブメール) に事前にサインインするよの見積額は前システムとほぼ同規模であった。本学

うに利用者全員にメール通知した。サービス切り替えは大規模なキャンパス移転を終えたばかりで予算が日より前にサインインしてもメールは届いておらず確限られており、その予算を確保するのは困難と結論し認がしにくいと思われたため、通知前に確認用のテスた。一方、本学では Microsoft と EES(Enrollment for

トメッセージを直接メールボックスに投入した。

Education Solution) 契約を結んでおり、これに付随

また、切り替え直後に前システムからのメール送信

して Microsoft Oﬃce 365 を学内に提供していた [5]。

機能を停止すると、Exchange Online へのアクセスがこのことから、メールサービスを Oﬃce 365 の一部でうまくできない利用者が我々に問合せメールを出すこある Exchange Online に移行することでコスト削減とができなくなる。そのため、切り替え後 1 ヶ月程度を目指すこととなった [4]。

は前システムからもメールを送信できる状態を維持す2.2移行スケジュールることとした。

全学基本メールを Exchange Online へ移行するこ

メールサービスの移行時には利用者のメールボックとを決定した後、詳細な移行スケジュールを検討した。

スの移行が必要となるが、管理者権限での約 3 万人分

前システムの保守契約は 2019 年 3 月末までだったのメールボックス移行は難易度が高いため、今回の移が、迷惑メール・ウイルスメールをフィルタする装置

行では情報統括本部側でのメールボックスの移行は行(以下「メールフィルタ装置」) については 5 年分のわないこととした。その代わり、Microsoft Outlook

ライセンスを導入時に調達しており、その終了期限はや Mozilla Thunderbird 等のメールクライアントを使2019 年 1 月末であった。これは、ライセンスが必要用して利用者自身でメールボックスを移行するためのとなる期間に本運用前の構築・テスト期間が含まれて手順書を用意した。

いたためである。メールフィルタ装置のライセンスが利用者から見た移行スケジュールを表 1 に示す。

切れるとフィルタのパターンファイルが更新されな
表1くなることから、その状態でメールサービスを運用し続ける事は危険である。全学基本メールの Exchange

2018 年 11 月中

切り替え前に Exchange Onlineにアクセス

Online への切り替えはそれより前に済ませる必要が2018 年 12 月 18 日あった。

移行スケジュール

前システムから Exchange Online
へメール受信切り替え

一方で、全学基本メールを Exchange Online に移行する際に必要となる付帯システム (詳細は 2.4 節で2019 年 1 月 23 日前システムのメール送信機能停止述べる) の準備が遅れていたため、切り替え日はでき2019 年 3 月末

前システムの完全停止

るだけ遅くしたいという事情もあった。1 月以降は教職員・学生ともに 3 月の卒業・修了に向けて忙しくな

2.3Oﬃce 365 テナントの準備ることから、この時期は避ける必要もあった。以上の

図 1 は移行後のメールシステムを含む Oﬃce 365 関

条件から、2018 年 12 月中に切り換えることを決定し連システム全体の構成図である。本学の Oﬃce 365 テた。切り替え直後は利用者からの問合せが増加する事

ナント、Microsoft Azure 上に構築されたサーバ群、が予想されるが、冬季休業に入ると利用者からの問合そして本学のキャンパス内に設置したサーバ群で構成せに対応できなくなること、週末直前の切り替えも同されている。なおこの図の Azure 上のサーバ及びネッ様に避けるべきことから、12 月 18 日 (水) を切り替え

トワークは本学の学内ネットワークと SINET クラウ日とした。

ド接続サービスによって接続され、本学のネットワー

切り替え直後には利用者から問合せが殺到することクアドレスがついていることから、オンプレミスと同が予想されたため、問合せ数を削減する策として、利様の扱いとなっている。本節で本学の Oﬃce 365 テナ

用者に切り替え日より前に Exchange Online にアクントについて述べ、2.4 節でその他のサーバ群についセスさせることで利用方法に慣れてもらうとともに、て述べる。

23

ら、別名 (メールエイリアス) として維持することとOffice 365 テナントなった。

ExchangeOnline

Azure AD

AADConnect

ユーザ ID とパスワードを新テナントでどのようにメール通知
設定変更
ライセンス付与取り扱うかも決定する必要があった。他の情報システ

Microsoft Azure

ムと同様に全学認証基盤のユーザ ID とパスワードでLicense Sync.

別名アドレス設定

オンプレ AD

利用者

ADライフサイクル管理

サインインできるのが望ましかったが、ユーザ ID は全学基本メールアドレスとは異なること、またこのユー

ADFS/proxy

ザ ID とパスワードは学外のシステムには原則共有で利用者情報同期きないという全学認証基盤側ポリシーの制約があっ

学内ネットワーク
SMTP送信サーバ・一斉送信システム

図1

た。技術調査の結果、アカウント情報を保持してい全学認証基盤

るオンプレミスの Active Directory(AD) から Azure

メールサービス移行後のシステム構成

AD Connect で Azure AD にアカウントを連携する
際に、UPN を付けかえる「代替ログイン ID」という本学では 2016 年 4 月より Oﬃce 365 の学内提供を機能が利用できることがわかった。またパスワードは開始した。ただし、構築時に全学認証基盤とのデータAzure AD に連携せず、AD Federation Service(AD連携に関する制約を解決できなかったため、全学認証FS) による認証連携により Oﬃce 365 でのユーザ認基盤で利用者に割り当てられているユーザ ID・パス証リクエストをオンプレミスの AD で処理することワードをそのままサービス提供用のテナントで利用が可能となった [6]。これにより全学認証基盤のユーすることができず、全学基本メールアドレスを改変しザ ID とパスワードで認証しつつ、Oﬃce 365 の UPNた文字列をユーザ ID にあたる UPN(User Principalとして全学基本メールアドレスを利用する事が可能とName) として設定し、Azure AD で独立したパスワーなった。新テナントは 2018 年 4 月に学内に公開したドを設定する形で提供していた。UPN の違いからこが、その時点では前メールシステムと競合することかのテナントでは全学基本メールをサービスすることがら Exchange Online の機能は提供しなかった。

難しく、新テナントを用意する必要があった。

2.4

付随システムの準備

新テナントにおいて UPN を全学基本メールと揃え

Oﬃce 365 の新テナント準備に加えて、Exchangeるにあたり、学生向けメールアドレスの割当方法が問Online では提供されていない以下の機能やサービス題となった。学生向けメールサービスはもともと教育を準備する必要があった。

システムの Unix アカウントに端を発しており、ユーザ名として学生番号が利用されてきた。学生番号は入学時に割り当てられるため、入試に合格した入学前の学生は持っていない。本学では入学前学生への e ラー
ニングを実施しており、その中には Microsoft Oﬃce

1. 利用者へのアカウント作成・変更・削除等に関するメール通知機能

2. 利用者による別名アドレス設定機能
3. 全利用者に対する通知メール一斉送信機能
4. メール送信アドレスの変更機能

アプリケーションの講座が含まれている。2018 年度
まではボリュームライセンス版の Oﬃce アプリケー

2.4.1

メール通知機能ションを提供していたが、Microsoft との契約変更に前システムでは、アカウントの作成時や削除前、ま対応するため 2019 年度から Oﬃce 365 版を配布する

た氏名の変更によるメールアドレスの変更などを利用こととなっていた。そのため Oﬃce 365 のアカウント者にメールで通知する機能があり、新システムでも同が必要となるが、前述の理由により、入学前学生に学様の機能を用意することとなった。また、Oﬃce 365

生番号に基づいたメールアドレスは割り当てることがテナントの運用のためにはアカウント作成後に Oﬃceできない。一方教職員についてはサービス当初から英365 の各種サービスに対応したライセンスを付与した

字氏名に基づいたメールアドレスを割り当てていたこ

り、セキュリティグループに追加したりする処理も必とから、学生についても新テナントへの移行を機に英要であった。このため、新テナントの準備に合わせて字氏名に基づいたメールアドレスを割り当てることと「AD ライフサイクル処理システム」を構築し、メールなった。学生番号に基づくメールアドレスは長く利用通知機能はこのシステムの一部として実装した [6]。

されてきており受信できなくなると問題があることか

24

2.4.2 別名アドレス設定機能

ルアドレスを使ったりするなどの運用が日常的になさ全学基本メールでは、従来より「別名アドレス設定れていた。セキュリティ的な懸念はあるが、送信メーシステム」を提供している [1, 2]。自動で割り当てらルアドレスを変更したいという要望は高かった。このれる全学基本メールアドレスに加えて、英字氏名に基ため、Exchange Online を利用せずにメールを送信でづいた別名アドレスでもメールが受信できるように設きる別のメール送信サーバを用意することになった。

定するサービスである。もともとは、学生番号ベース利用者はメールクライアントに設定する SMTP サーのメールアドレスは進学や転学部によって変更され継バとしてこのサーバを指定することで、送信メール続利用ができず不便なため、希望により英字氏名からアドレスを変更可能となる。この方法はウェブメール生成したメールアドレスを別途追加できるというサー(Outlook on the web) では利用できないため、送信アビスであった。その後教職員向けにも対応を拡大しドレスを変更したい利用者はかならずメールクライアた。前システムでは約 2,500 人の利用者がいたため、ントを利用する必要がある。

Exchange Online に移行後も同様のサービスを提供すExchange Online をメールクライアントで利用するることとなった。2.3 節で述べたように、学生のメー場合、Exchange アカウントを設定するのが一般的だ

ルアドレスも英字氏名ベースになったため別名アドレが、Exchange アカウントでは SMTP サーバを個別にスの必要性は低下したものの、本名の英字が非常に長設定できない。このため、利用者には IMAP か POP

い外国籍の利用者による利用もある。

アカウントを利用するように案内し、その際に送信本システムは Azure 上の Linux 仮想マシン上にメールアドレスを変更したければ Exchange Onlineウェブサービスとして実装した。利用者はシステムにではなくこの SMTP 送信サーバを指定するように案ログインした後、英字氏名から生成されたいくつかの内した。

別名アドレス候補から 1 つを選択することができる。

このメール送信サーバはアカウント漏洩などで迷選択された別名アドレスを AD の proxyAddresses 属

惑メール送信等に不正利用される可能性があること性に追加することで、別名アドレスでもメールが受信から、利用者からのメールは一度 Exchange Online可能となる。利用者認証は SAML を利用して AD FSProtection を通してから送信するように設定した。こで処理される。

れは Exchange Online から見ると第三者リレーとな2.4.3 一斉送信機能るため、Exchange Online に受信コネクタと呼ばれる全学基本メールの目的の一つに、九州大学の全構成設定をし、SMTP 送信サーバ自体にクライアント証明員に大学の公的なメールアドレスを付与することで、書を設定する必要がある。適切なクライアント証明書

災害時などの緊急連絡に活用するという目的がある。

が無いと、Exchange Online に設定されたドメイン宛

このため、本メールシステムの一部として全構成員、のメール以外は拒否される。

もしくは選択した構成員へのメール一斉送信システムが必要である。一斉送信メールの本文には各受信者の所属・氏名を個別に挿入するという仕様があるため、3 移行の実際3.1準備の遅延とその回避策

Exchange Online の配布グループでは実現できない。

2018 年度に 2.4 節で述べたシステムを構築する予算前システムと共に運用していた送信システムは長期間を確保し、準備を開始した。予算は潤沢ではなかったの運用で保守が困難になっていたため、新規に調達すため、一部仕様の簡略化による費用の圧縮が必要となることとなった。クラウド環境からの大量メール送信り、調達手続きが遅れることとなった。このため、ADは難しいため、本システムは学内に設置している。こライフサイクルシステムと別名設定システムは 12 月のシステムは 2.4.4 節で述べる SMTP 送信サーバと18 日の切り替え日までに完成することができなかっ同じサーバ上に構築されている。

た。一時的な回避策により、切り替え日を遅らせなけ2.4.4 送信アドレス変更機能ればならないような致命的な問題は回避できた。

Exchange Online では、送信者のメールアドレスはExchange Online が全学基本メールアドレス宛の通常 AD の proxyAddresses 属性に設定したプライマメールを正しく受信するためには、利用者の氏名変更リメールアドレスから変更できない。前システムにはや学生番号の変更に従って UPN や proxyAddresses

そのような制約はなく、2.4.2 節で述べた別名アドレス属性を適切に変更する必要がある。AD ライフサイクを使ったり、5.2 節で述べる部局サブドメインのメール処理システムが完成するまでは、PowerShell スク

25

リプトで最低限必要な処理を実装し、これを AD のタい仕様などは、FAQ としてウェブページに掲載した。

スクスケジューラで実行することにより対応した。利

情報統括本部ではチケット管理システム等を運用して用者へのメール通知はこのやり方では実装できなかっいないため、正確な問合せ数は把握できていない。またが、必須の機能ではないため一時的に通知機能停止

た、3 月末までに前システムから Exchange Online にとした。AD ライフサイクル処理システムが完成した古いメールを移動するよう通知した。

2019 年 2 月までこの処置で暫定対応した。

2019 年 1 月 23 日に、前システムで SMTP サービ

別名アドレス設定システムも同様に 2019 年 2 月にスを停止した。これにより、ウェブメールやメールク完成した。前システムで受信できた別名アドレスは継ライアントで前システムを利用してメールを送信する

続して受信可能である必要があったため、Exchangeことはできなくなった。停止後、メールが送信できな

Online への切り替えより前に前システムの別名アドくなったとの問合せが複数あり、システムの切り替えレス設定システムを停止した上で、既存の別名アドレから約 1 ヶ月が経過し前システムにはもうメールが届

スを AD の proxyAddresses に手動で設定することでいていないにもかかわらず、切り替えに気づいていな別名アドレスを維持した。また新規の別名アドレスはい利用者がいることがわかった。Exchange Online にシステム完成までは設定できないこととした。

移行していない利用者に追加の通知をするため、前シ3.2利用者への通知

ステムのメールボックスに SMTP を利用せずにメッ

メールサービス切り替えの利用者への通知では、セージを配布する方法を考案し、再度移行を促す通知

メールや学生向けウェブポータルへの掲示に加えて、メールを配布した。なお、メールを Exchange Online

2018 年 10 月と 11 月に 9 回の部局説明会を実施しに移動する必要があるため、IMAP と POP についてた。全体で教職員の約 10% が参加した。これと並行はシステムの停止まで稼働させた。

して、ウェブブラウザやメールクライアントを利用しメール移行のための前システムでのメールの読み出

た Exchange Online へのアクセス方法のマニュアル

しは 2019 年 3 月末まで可能と通知していたが、実際を作成し、公開した。前述のように、利用者に対し事の停止は 4 月 3 日となった。九州大学では 2013 年か

前に Exchange Online の利用を体験しておくことをら学生 PC 必携化を実施しており [7]、毎年 4 月の入推奨した。少なくともウェブメールでアクセスできて学式前には新入生向けの PC 講習会を開催している。

いれば、切り替え後すぐにメールを読む事ができるた2019 年度は 4 月 1 日と 2 日が開催日で、この期間はめである。

講習会開催に情報統括本部の人員がかなり割かれる。

3.3

移行の詳細

前システムを完全に停止するとまた問合せが増える可2018 年 12 月 18 日に、全学基本メールで利用してい能性が高く、対応が難しいため、停止を 4 月 3 日に延る DNS ドメインの MX レコードを Exchange Online期した。前システムへのアクセスが不能になることかに変更するとともに、前システムで受信されたメーら問合せが増加するかと思われたが、予想に反してほルを Exchange Online に転送する設定を有効にした。

とんど問合せはなかった。このことから、今回の移行

これにより、DNS のキャッシュ機能に起因するメールは無事成功したと考えている。

受信サーバ変更の遅延を回避した。この時、DNS サー
バ管理者との連絡の齟齬により、学生用メールドメイ
ン (s.kyushu-u.ac.jp) の MX レコードが一度消失

4 発生した問題
この章では、Exchange Online の移行後に発生した、する事故が発生した。DNS でドメインが無いという移行前に想定できていなかった問題について述べる。

情報をキャッシュする期間 (negative caching TTL)

4.1が 3,600 秒に設定されていたため、最大 1 時間学生向けのメールが宛先不明になった可能性がある。

迷惑メールフィルタと自動振り分け

Exchange Online 移行直後から、一部のメールが受信できていないという問合せが複数寄せられた。情報切り替え後、利用者からはメールクライアントの設統括本部内からも同様の指摘があり、調査の結果通常定やメールの転送設定等に関する質問が寄せられた。のメールが迷惑メール判定され、迷惑メールフォルダ

また、複数回の通知にもかかわらず切り替えを認識しに格納されてしまっている例が多数あることがわかっていない利用者も残っており、全学基本メールにメーた。Exchange Online Protection の迷惑メール判定

ルが突然届かなくなったという問合せが複数あった。

基準は非公開のため原因は不明だが、切り替え直後は問合せが多い質問や、Exchange Online のわかりにくフィルタの学習が無いことから普通のメールも迷惑26メールと誤判定されやすいのではないかと思われる。

自動的に制限される事がわかった。

迷惑メールフォルダに格納されたメールは 30 日間

このようなユーザに対しては個別に連絡し、通常ので自動的に削除され、その期間は設定で変更できない。

転送設定を解除するとともに、受信トレイのメールのそのため、全利用者に対し迷惑メールフォルダをこまみを転送するルールを設定してもらうことで、問題がめに確認し、誤判定されたメールは迷惑メールフォル発生しなくなることを確認した。迷惑メールを外部転ダから移動するように通知した。迷惑メールフォルダ送しなくなるためと思われる。

からメールを移動すると、個人別の除外リストが更新され、誤判定が軽減されるためである。

5 その他のメールサービス

迷惑メールフォルダに自動で振り分けないという設

この章では、本学で運用されている全学基本メー定も可能だが、これは逆に有害なメールを開いてしまル以外のメールサービスについて、その Exchangeう危険性が高くなるため、自動振り分け自体は有効のOnline への移行やその検討状況について述べる。

ままとした。なお、利用者個人で自動振り分け設定を5.1無効にする事も可能である。

4.2

事務用メール

本学では、教育研究用キャンパスネットワークとはスロットリングによる流量制限別に事務用ネットワークが運用されている。ここではExchange Online への切り替え前に全利用者宛にテ事務向けの Exchange Server で事務系専用のサブドメストメールを配信した際に、メール一斉送信に異常にインでのメールサービスが運用されていたが、こちら時間がかかる事がわかった。調査の結果、Exchangeもリプレースが必要となり 2018 年度中に Exchange

Online には IP レピュテーションに基づくスロットリ

Online への移行が予定されていた。全学の Oﬃce 365

ングの機能があり、今までメールを送信して来たことテナントとは別テナントにする案もあったが、サイのないような IP アドレスからメールが送信されるとンインの操作が複雑化する等の問題があり、最終的に非常に強い流量制限がかかることがわかった。またこ同一テナントに統合することになった。旧 Exchangeの制限は、その IP アドレスから送信されるメールがServer で使用されていた部署や職階に対応したメー迷惑メールでなければ徐々に軽減され、数日程度で改ルアカウントは、配布グループや共有メールボックス善されることがわかった。に切り換えられ、それらのアドレスを利用する必要が学内の IP アドレスであれば受信コネクタを設定することでもスロットリングは軽減されるとのことだっある利用者のアカウントをそれらのグループやメールボックスに登録する形となった。

たが、個別に対応すると運用負荷が高いため、時間で解事務用メールの移行は全学基本メールの移行とは独決するとアナウンスし個別対応はしないこととした。

立に行なわれた。これには旧 Exchange Server からの4.3

メール転送に起因する送信制限

メールメッセージ移行も含まれていたが、Oﬃce 365

Exchange Online への切り替え後しばらくして、極内蔵の移行ツールを利用するのに必要なスペックを旧一部のメールアカウントにおいて、そのアカウントサーバが満たしていなかったためメッセージ移行は難からのメール送信が Exchange Online で自動的に制航した。適切な移行パラメータを見つけるのに数ヶ月限される事象が発生した。Oﬃce 365 管理者の「制限を要したが、適切な設定が判明した結果、934 メールされたユーザ」管理画面で確認できる。調査の結果、ボックスを 19 日間で移行することができた。

メールの転送設定に起因している事がわかった。

5.2

部局サブドメイン

本学では、全学基本メール宛のメールを他のメール本学では、部局が kyushu-u.ac.jp のサブドメイアドレスに転送することを特に禁止していない。このンを取得することに大きな制約はないため、200 以上ため、部局のメールアドレスなどに転送している利用のサブドメインが運用されている。各部局の支線ネッ者が多い。Exchange Online の個人設定にはメールのトワークの運用は各部局に委譲されているため、自然転送先を設定できる項目があるが、この設定では迷惑とそのネットワークのためにサブドメインを取得するメールと判定され迷惑メールフォルダに振り分けら事になる。そのサブドメインでメールシステムを運用れたメールも全て外部に転送される。この状態でそのする部局も多い。サーバ立ち上げ時の管理者が異動すメールアドレスが多数の迷惑メールを受信すると、転るなどで管理が不十分なサーバも増えており、ネット送される迷惑メールをそのアカウントが送信したと認

ワークセキュリティ的にリスクが高いことから、情報識されるようで、そのアカウントからのメール送信が統括本部ではメール・ウェブ・DNS ホスティングサー

27ビスを提供してサーバの巻き取りを行っている。現在多いことがわかっている。メーリングリストではヘッ

約 100 ドメインがホスティングサービスを利用してダの書き換えや通し番号の付番などの機能が必要とさいるが、独自にサーバを運用している部局もまだ多数れることから単純な配布グループでは対応できない。

残っている。

これについては GNU Mailman などのメーリングリ

メールはセキュリティ侵害の第一歩として多くの攻撃にさらされており、安全にメールシステムを運用するのは困難になってきている。迷惑メールフィルタやウイルスフィルタをバラバラに運用するのはコスト的スト管理ソフトウェアを搭載したサーバを準備する必要があると考えている。

6 おわりににも不利である。またフィッシング被害によりアカウ

この論文執筆時点で前システムの停止から約半年がント情報が漏洩し、ウイルスメール等を大量送信する経過しており、全学基本メールの Exchange Online 移インシデントも発生している。サーバ自体の脆弱性は行は成功したと考えている。問合せ数も平常レベルにホスティングサービスの利用で軽減できたとしても、落ち着いており、利用者は大きな問題なく Exchange

アカウント管理が適切でないためにアカウントが不正Online を利用しているものと思われる。一方、本学利用されるインシデントは防ぐのが難しい。全学認証のキャンパスネットワークには依然として多くの部局基盤はより厳しいパスワードポリシーで運用されておメールサーバが残されており、セキュリティ対策や安り、これを利用している全学基本メールではアカウン

定運用の課題がある。今後ホスティングサービスへのトの不正利用による迷惑メール発信は過去ほとんど発巻き取りや Exchange Online への統合を進めること生していない。一方で、メールアドレスは簡単に乗りで、より安全な学内メール環境を目指す。

換えることが難しく、部局ドメインでのメールを強引に禁止して全学基本メールだけに統一するのも現実的ではない。利用者の利便性とアカウント管理を考える

参考文献[1] Naomi Fujimura, Tadatsugu Togawa, Yoshiakiと、部局メールを Exchange Online に統合するのが理Kashara, and Eisuke Ito.

想的である。

vice for students based on their names. In IPSJ

全学基本メールの Exchange Online 移行後、部局のメールサービスを Exchange Online に統合すること

Primary mail ser-SIG Technical Report, Vol. 2011-IOT-14, Tokyo,Japan, 2011. IPSJ.

が技術的に、また運用として可能かについて検討して[2] Naomi Fujimura, Tadatsugu Togawa, Yoshiaki

いる。現在検討している手法は、部局ドメインのメー

Kasahara, and Eisuke Ito. Introduction and ex-

ルアドレスに対応する配布グループを作成し、そのア

perience with the primary mail services based

ドレスに対応する利用者のアカウントを唯一のメンバ

on their names for students. In Proceedings ofとして登録することである。この時、メンバには配布

the 40th Annual ACM SIGUCCS Conference on

グループのメールアドレスでメールを送信する許可をUser Services, SIGUCCS ’12, pp. 11–14, New設定できる。これにより、ウェブメール利用を含めてYork, NY, USA, 2012. ACM.

部局のメールアドレスでもメールを送信することが可[3] Yoshiaki Kasahara, Eisuke Ito, and Naomi Fu-能になる。この方法は前述の別名アドレス設定システjimura.

ムでも有用だが、別名システムの設計時点では方法がsity primary mail service for staﬀ members and明確になっていなかったため採用できなかった。

students. In Proceedings of the 42Nd Annual

Introduction of new kyushu univer-

この方法を実装するためには、部局サブドメインのACM SIGUCCS Conference on User Services,

メール管理者がそのドメインに属する配布グループ

SIGUCCS ’14, pp. 103–106, New York, NY,の作成や削除、メンバの変更をできるような仕組みがUSA, 2014. ACM.

必要となる。Exchange Online 自体には、登録ドメイ[4] Yoshiaki Kasahara, Takao Shimayoshi, Eisuke

ン単位で管理者を分けるような仕組みがない。このたIto, and Naomi Fujimura. The past, current, andめ、独立したウェブサービスとして管理者からの要求future of our email services in kyushu university.

を受けつけ、それを Exchange Online に全体管理者

In Proceedings of the 2018 ACM on SIGUCCS

権限で反映する仕組みが必要となる。また、部局アン

Annual Conference, SIGUCCS ’18, pp. 103–106,

ケートによりメーリングリストを運用している部局もNew York, NY, USA, 2018. ACM.

28

[5] Yoshiaki Kasahara, Takao Shimayoshi, Masahiro
Obana, and Naomi Fujimura. Our experience
with introducing microsoft oﬃce 365 in kyushuuniversity. In Proceedings of the 2017 ACM Annual Conference on SIGUCCS, SIGUCCS ’17,
pp. 109–112, New York, NY, USA, 2017. ACM.
[6] Naomi Fujimura Takao Shimayoshi, Yoshiaki Kasahara. Renovation of the oﬃce 365 environment in kyushu university: Integration of account management and authentication. In Proceedings of the 2019 ACM on SIGUCCS Annual
Conference (to be appeared), SIGUCCS ’19, New
York, NY, USA, 2019. ACM.
[7] Naomi Fujimura.

Bring your own computers

project in kyushu university. In Proceedings ofthe 41st Annual ACM SIGUCCS Conference on
User Services, SIGUCCS ’13, pp. 43–50, New
York, NY, USA, 2013. ACM.

29