九州大学における全学基本メールサービスの導入
戸川忠嗣†

宮口忠幸† 酒井健禎† 亀岡兼一†

入江啓一†

伊東栄典‡

九州大学情報統括本部（†情報システム部，‡情報基盤研究開発センター）〒812-8581 福岡市東区箱崎 6-10-1{ togawa.tadatsugu.642,miyaguchi.tadayuki.773, sakai.taketsugu.298, kameoka.kenichi.246,
irie.keiichi.123, ito.eisuke.523 }@m.kyushu-u.ac.jp
概要
電子メールは基本的な情報通信基盤となっており，大学の活動（教育・研究・業務）においても不可欠である。九州大学情報統括本部では，大学の活動支援のための基本的情報通信環境として，大学の全職員に電子メール環境を無料で提供する「全学基本メールサービス」の導入を進め，平成 21 年 7月からサービスを開始した。導入した全学基本メールシステムについて報告する。

1. はじめに
現在，電子メールは大学において基本的な情報通信基盤となっており，大学の活動（教育・研究・業務）において不可欠である。九州大学では従来，メールシステムは部局や研究室などで，様々な形で運用されていた。サーバの管理・運用は職員のボランティアに依存する場合が多く，運用業務の負担とメールシステムの維持更新が問題であった。また，部局ごとに管理・利用されていることから，他部局職員のメールアドレス把握が難しく，学内の情報共有の障害となっていた。特に近年，パンデミック等の緊急時における構成員への正確な情報提供・周知についての要望が上がってきたものの，電子メールによる情報提供は不十分で，円滑に行えない状況であった。
そこで，九州大学情報統括本部では，学内の全職員（教員を含む）にメールアカウントを無料で提供する「全学基本メールサービス」の導入を進め， 2009 年 7 月からサービスを開始した。九州大学
において，全職員一律のメール環境が提供されるのは，この全学基本メールが初めてである。利用者認証のための全学共通 ID（SSO-KID）発行により学内構成員のアカウント管理が実現したため，一律のメール環境提供が可能となった。
このサービスにより，全職員が統一的なメールアドレスを使用することが可能になり，パンデミッ
ク発生時等の緊急連絡や日常的な教育・研究・業務に関する連絡が円滑に行えるようになることが期待できる。一方，学内の部局ドメイン名でのメール環境も重要であるため，それらの支援のために，有料のメールホスティングサービスも提供している。

本稿では，導入した全学基本メールシステムについて説明する。

2. 九州大学におけるメールサービスの状況と整備方針
2.1

整備前の状況

2007 年に学内の各部局にヒアリング調査を行い，学内における情報サービスの状況を調査した。その結果，電子メールサービスについての，サービス提供形態は表 1 のとおりであった。

-1-

表 1：電子メールサービスの提供形態
名称
旧・基本 A

対象
全学生

内容
全学生を対象とした教育情報システム（情備考恒久サービス，無償報統括本部が管理）の電子メールサービス
旧・基本 B
旧・選択 C

職員・学生

職員

各部局／部門／研究室が独自に管理運用

各部局／部門／研究室する電子メールサービス

による経費負担

上記を補完する情報統括本部提供の mbox

暫定サービス，無償移行サービス

上記の現状に対して，九州大学情報統括本部として次のように考えた。
 各部局／部門／研究室単位での電子メールサーバの維持・管理運用は，費用・マンパワー・情報セキュリティの面で，最適とはいえない。
 大学として全構成員（職員，学生）に対して基本的な電子メールサービスを恒久的かつ安定的に提供すべきである。また，ウィルスメール，迷惑メール，等の情報セキュリティ面でも十分な対策を施すべきである。

2.2

大学におけるメールサービス提供方針

前節の認識に基づき，今後の電子メールサービス提供方針として，表 2 の提供形態を想定した。表2 の基本 B が，本稿の対象とする全学基本メールサービスである。

表 2：今後のメールサービスの提供形態
名称
基本 A

対象
全学生

(旧・基本 A）
基本 B

内容
情報統括本部による全学生を対象とした

備考
恒久サービス・無償

教育情報システム電子メールサービス
全職員

全学基本メールサービス：情報統括本部で恒久サービス・無償全教員・職員へ提供するメールサービス
選択 D

職員，学生情報統括本部が提供する（基本 A および基有償サービス。ドメイン本 B に対する）電子メール転送サービス（部局／部門／研究室）
単位で申請して利用

選択 E

職員，学生

情報統括本部が提供する電子メールサー有償サービス。ドメイン

バ・ホスティングサービス（部局／部門／研究室）
単位で申請して利用

新・選択 F(旧・基本 B)

2.3

職員，学生各部局／部門／研究室が独自に維持，管理各部局／部門／研究室運用する電子メールサーバによる経費負担

職員向けメールサービスの全体像

全学基本メールサービス，ホスティングサービスと，既存メールサーバの関係を全体像として図１-2-に示す。
全学基本メールサービス

ホスティングサービス

部局や研究室のメールサーバ

your.name.123@m.kyushu-u.ac.jp

addr1@DDD.kyushu-u.ac.jp

addr3@ZZZ.
kyushu-u.ac.jp

addr2@XXX.kyushu-u.ac.jp
全学基本メールサーバ
全学共通
認証基盤

メールサーバメールホスティングサーバ

Virus Filter

部局
ドメイン
DDD

SPAM Filter

MailServer

部局ドメイン
XXX

Mail Server
全学共通ID（SSO-KID）
による認証

DDDの管理者

XXXの管理者

転送のみ
メーリングリストおよび個人用メールを転送送受信を行うメールサーバとして利用（メールスプール有り）

メール専用ソフト Webメール(POP/IMAP)

利用者（全教員・職員）

ZZZの管理者

送受信

送受信

XXXドメインのメール利用者

ZZZドメインのメール利用者

図 1：全学基本メールサービス，ホスティングサービスと，既存メールサーバの関係

3. 全学基本メールサービス
ここでは，本稿の主たる対象である「全学基本メールサービス」について述べる。

3.1

全学基本メールサービスの対象者

全学基本メールサービスは，九州大学の活動に従事する全職員へ提供することとした。厳密には，全学基本メールのアカウントは，全学共通 ID（SSO-KID）[1,2,3]の所持者に提供している。全学共通ID（SSO-KID）は，正規の九州大学職員と，派遣等の大学業務従事者に発行している。派遣等の方には申請に応じて全学共通 ID を発行している [2,3]。公に九州大学の活動に係る人は全学共通 ID（SSO-KID）を取得可能であるため，その全員が全学基本メールサービスを利用可能である。

3.2

メールアドレス

アドレス形式は，「英字姓.英字名.SSO-KID の下 3 桁数字」に「@m.kyushu-u.ac.jp」とすることにした。例えば，筆者の一人（伊東）の場合，ito.eisuke.523@m.kyushu-u.ac.jpという形のアドレスとなる。
SSO-KID の下 3 桁は，同姓同名を回避するために付与している。九州大学の場合，2009 年 6 月時
点で約 20 組の同姓同名（読み）があった。これらに SSO-KID の下 3 桁を付けることで，メールアドレスの一意性を確保できた。将来にわたってメールアドレスの一意性を確保するため，今後の新任者には既発行のアドレスと重複するような SSO-KID は割り当てないようにしている。

3.3

メール利用時の認証

メールでは，個人情報や学内情報などが流通するため，受信時の認証と暗号化が必要である。送信時にも，迷惑メール配送を防ぐため，認証による送信制限が望ましい。全学基本メールでは，メール-3-

送受信時に利用者認証を行う。認証の ID・パスワードには全学共通 ID（SSO-KID）とそれに対応するパスワードを用いている。表 3 にメールクライアント用設定パラメータ等を示す。

表 3：メールクライアント用設定パラメータ項目
認証用 ID/PW

3.4

受信用

送信用

全学共通 ID

全学共通 ID（SSO-KID）（SSO-KID）

プロトコルとPOP over SSL : 995

Submission over TLS : 587

ポート

POP over TLS : 110

その他の概要その他の，全学基本メール概要を示す。

 1 人あたりの容量は 100MB
 30 日を保存期限として，受信から 30 日で削除
 POP3 と Web メールを提供 (SSL を使用)
 職員でなくなったら三ヶ月後にアカウント削除
 spam フィルタを適用
 ウイルスフィルタは後から導入予定
 受信可能なメールの大きさは 20MB 未満

3.5

システム概要

全学基本メールシステムは，Mirapoint 社の機器で構成した。ゲートウェイに RazorGate600 を 1台用意し，メールサーバに M6000 を 2 台用意している。POP, Webmail, Anti Spam のライセンスを，それぞれ 1 万個購入した。表 4 に機器の性能緒元を，図 2 に全学基本メールのシステム構成を示す。

表 4：性能諸元
Mirapoint Message Server M6000

Mirapoint RazorGate RG600

プロセッサ

Quad Core Intel Xeon 2.3GHz ×2

Quad Core Intel Xeon 2.0GHz

メモリ

4 GB ECC DDR2 SDRAM

4 GB ECC DDR2 SDRAM

ストレージ

670GB（システムが 50GB を使用。

90GB

容量メールボックス用は 600GB 程度。
）

台数

2台

1台

-4-メールセキュリティ
ゲートウェイInternet

Anti SPAM

Mirapoint
RazorGate600×1台

SMTP

Proxy

SMTP/POP/HTTP

LDAPPOP

SMTP/POP
HTTP

Webmail
メールサーバ
Mirapoint M6000 (600GB)×２台

LDAP(Directory Server)Clients

図 2：全学基本メールのシステム構成
利用者のメールアカウントは，LDAP サーバと連動している。認証用の LDAP サーバにメールアドレスが登録されると，自動的にサーバ側にもメールボックスが設定されるようになっている。そのため，メールアカウント管理の作業は軽減されている。
メールサーバの M6000 は 2 台あるため，1 台のサーバを職員の半数が使うようにしている。各メー
ルサーバでは利用者毎にメールボックスが作成されるので，SSO-KID の末尾が奇数の人は１台目に，偶数の人は 2 台目のサーバにメールボックスが作成されるように割り当てている。外部からのメールはゲートウェイである RazorGate RG600 が受信するようにしている。受信すると RG600 が宛先に応じてメールを M6000 に振り分ける。RG600 は，spam メールフィルタ（将来はウィルスメールフィルタも）を行っている。これにより，メール受信およびフィルタと，受信メール管理と利用者からのメール利用の負荷分散を行っている。
RG600 は，Web メールにおける Web アクセスの振り分けも行っている。Web メールの入り口サイ
トは RG600 であるが，利用者がログインすると，M6000 の Web メールサイトへリダイレクトされる。
そのため，Web アクセスについても負荷分散になっている。
現在の運用では，サーバのディスクを溢れさせないための制限をしている。その制限は，一人あたりの容量は 100MB，受信から 30 日で削除（保存期限は 30 日），受信可能なメールの大きさは 1 通当たり 20MB 未満，である。100MB の上限は，職員の半数である約 4000 人が 1 台のサーバ（約 600GB）を利用するに場合に，ディスクを超過しない値として設定した。

4. 運用における課題
4.1

LDAP サーバの属性拡張

Mirapoint M6000, RazorGate600 は，LDAP サーバと連動する機能を有している。LDAP サーバに登録された情報を参照してメールボックスを生成したり，メールを転送したり，各利用者のメールボックのサイズを指定したりといった制御ができる。九州大学では，全学的な認証用の LDAP サーバを平成 17 年度に導入しており，平成 19 年度から全学共通認証サービスを正式に開始した。そのため，全構成員が登録された LDAP サーバが既に存在している。全学基本メールサービスを開始するには，メールサービスに必要な属性が不足していたため LDAP サーバに Mirapoint 用のスキーマを追加し，各利用者用に mail, mailRoutingAddress, mailHost の３属性を各利用者のレコードに追加した。

-5-

4.2

メールアドレスの生成

全学基本メールのアドレスは，職員の英字氏名と全学共通 ID（SSO-KID）から生成している。職員の氏名や所属といったデータは，人事給与データベース（人事給与 DB）から抽出する。しかしながら，全学基本メール運用開始前には，全職員の英字氏名は人事給与 DB に登録されていなかった。人事給与 DB には英字氏名を記録するフィールドが用意されていたものの，英字氏名を収集・登録する手順が確立していなかった。そのため，自動的なメールアドレス生成を簡単にできなかった。
そこで，全学基本メールの運用開始前に，全職員の英字氏名データを整理することとした。幸い在職教員については研究業績 DB への英字氏名登録が半ば義務化されていたため，大半の教員については英字氏名を抽出できた。事務系職員については，事務手続きを通して英字氏名の収集を行った。それらの作業の結果，約 7800 名の職員のうち，約 6500 名については比較的正確な英字紙名データを収集できた。残りの約 1300 名（多くは平成 21 年度の新任者）については，手作業で英字氏名を収集した。新任者の多く（600 人）は九州大学病院の職員であったため，病院の医療情報部に依頼して，九州大学病院職員の英字氏名を収集していただいた。英字氏名整理の事務手続きの際は，カタカナ氏名から英字氏名を生成し，その綴りをもとに英字氏名データを収集した。
平成 21 年 6 月前半の段階で，一次段階の英字氏名整理を行い，メールアドレスを生成した。生成したメールアドレスは LDAP サーバに登録した。LDAP サーバは，利用者認証とメールのアカウント管理機能を兼ねている。また，学内便による文書送付で，各職員へ各自のメールアドレスを連絡した。
平成 21 年 7 月の全学基本メールの運用開始から一ヶ月を猶予期間とし，この期間の間に，英字氏名の変更を受け付けた。この場合の変更とは，人事給与 DB に登録された英字氏名が，つまり全学基本メールアドレスの英字氏名が，本人が正式なもの（パスポート記載のものなど）と考える英字氏名と異なる場合は，申告すれば正式な英字氏名に登録をやりなおすこととした。

4.3

メールアドレスの連絡

メールアドレスの通知は，紙による連絡を行うこととした。通知文のひな形を作り，それに DB から抽出した所属・氏名・メールアドレスを差し込み印刷する。その後，印刷した文書を学内便で構成員に通知した（正規職員分が 7,645 件，非正規職員分が 179 件）。この通知文書はほとんどの構成員に届いたものの，一部から「全学基本メールのアドレスが分からない」といった問い合わせがあった。
これは，一部の構成員は届いた通知文書をきちんと読まずに捨ててしまうなどの処理を行っていたためと考えられる。

4.4

改名時の対応本サービスでは，構成員の氏名に基づいてメールアドレスを生成している。氏名は，結婚などで変わることがある。本名が変更された場合にも，通称使用申請を行うことで職場では旧姓氏名を呼称として継続することが可能である。それらを踏まえて改名時の手順を定めた。まず，本名と通称は，通称を優先することに決めた。最優先の氏名に変更が有った場合，その氏名に基づくメールアドレスを改めて作成する。例えば，福岡花子が九大花子に改名し，かつ通称利用申請による旧姓氏名の利用も行わないとする。この場合，最優先の氏名は「九大花子」になるため，全学基本メールのアドレスは，
fukuoka.hanako.123@m.kyushu-u.ac.jp から kyudai.hanako.123@m.kyushu-u.ac.jp に変更される。
なお，数字３桁の部分は九州大学全学共通 ID（SSO-KID）の下３桁であるが，改名されても SSO-KIDは変更されないため，メールアドレスの数字３桁部分に変更はない。このアドレスを LDAP サーバに-6-

登録する。メールサーバは LDAP に連動するため，LDAP に登録後は新しいメールアドレスが利用可能となる。
改名によりメールアドレスが変更になった際，改名前に用いていた古いアドレス宛のメールが急に届かなくなると業務上支障がでる。そのためメールサーバ側で，旧アドレス宛のメールを，本人のメールボックスへ転送するようにしている。本サービスで用いている Mirapoint M6000 では，利用者のメールボックスを個人の ID 名（LDAP に格納されている UID 属性の値）にしている。本学の場合，個人の ID は九州大学全学共通 ID（SSO-KID）である。先の例で九大花子（旧姓名・福岡花子）さんの SSO-KID が 9876540123 であるならば，旧アドレスの fukuoka.hanako.123@m.kyushu-u.ac.jp 宛のメールは 9876540123@m.kyushu-u.ac.jp へ転送するように設定する。なお，転送期間は三ヶ月にしている。

4.5

利用者窓口および説明サイト

メールに関する問い合わせ窓口として，メールと電話での問い合わせ窓口を置いた。この窓口に，文書でのサービス開始通知直後は多数の問い合わせがきた。サービス開始の文書を送付した 2009 年 6月 19 日（金）から，正式サービス開始の 2009 年 7 月 1 日を過ぎた 7 月第二週（2009 年 7 月 10 日）までに届いた問合せメールは，107 件あった。その後，多くの構成員が安定的に利用できるようになると，問い合わせは減っていった。2009 年 7 月 11 日から 7 月末までの問合せメール数は 11 件，8 月中の問合せメール数は 5 件であった。サービス開始直後は電話による問合せも多かった。これらの各利用者からの問合せを整理し，全学基本メールの案内 Web サイトの説明や FAQ を充実させていった。
問合せが減った理由には，Web サイトの充実もあると考えられる。

5. その他の課題
5.1

利用率

2009 年 7 月 1 日に運用を開始した。2009 年 9 月 4 日現在，7738 人の職員のうち，2101 人はログインして設定などを行っている。まだ全構成員の 3 分の 1 に満たないため，緊急時の重要連絡用に使うには問題がある。2009 年 7 月 24 日から，新型インフルエンザに関する注意連絡が全学基本メールで行われるようになった。2009 年 9 月 18 日からは，旅費・立替払い等の振込に係る通知も全学基本メール宛になった。これら学内の公式な連絡が全学基本メールで行われるようになれば利用者が増えてくるものと思われる。合わせて広報活動も行うことで利用率を増加する予定である。

5.2

容量・受信可能サイズ・保持期間制限

先に述べたように，現在の運用ではサーバのディスクを溢れさせないための制限をしている。その制限は，一人あたりの容量は 100MB，受信から 30 日で削除（保存期限は 30 日），受信可能なメールの大きさは 1 通当たり 20MB 未満，である。100MB の上限は，職員の半数 4000 人が 1 台のサーバ（600GB）を利用するに場合に，容量を超過しない値として設定した。
業務上の全メールを全学基本メールにて受信したところ，PDF や PPT 形式のファイルが添付された事務連絡メールが多く来ると，100MB の制限を超える場合が何度かあった。容量制限を守ろうとすると，30 日の保持期間より前にメールを消す必要がある。保持期間が 30 日で，それを超えた受信メールが削除されることについても不満がある。POP で手元のクライアントへメールデータを落とし-7-たりしたり，他へ転送する事で対応可能であるものの，利便性の高い Webmail のみでのメール利用を要望する利用者から，期間が短すぎるとの不満が出ている。また，受信可能なメールの大きさは 1 通当たり 20MB 未満としている。この制限のために，大きなサイズの資料ファイルを添付したメールが届かない場合もあった。

6. おわりに
本稿では，九州大学における職員向けの電子メールサービスについて現状を報告した。九州大学では，情報統括本部がメールのホスティングサービスと全学基本メールサービスを提供している。全学基本メールサービスは，2009 年 7 月に開始したばかりである。
今後は，全学基本メール導入の目的である，緊急時連絡や重要事項の伝達，さらに学内の情報交換の活発化について整備を行う予定である。防災の日である 2009 年 9 月 1 日には，防災訓練を兼ね，全学基本メールを用いた一斉連絡および応答確認を行った。この一斉連絡と応答確認システムは筆者らが開発したものである。一斉連絡および応答確認システムについては，現在，システムの機能充実と学内での運用ルール制定などの作業を行っている。改めて別の機会に詳細を報告したい。

参考文献[1] 伊東栄典，全学共通認証事業室：“九州大学全学共通認証基盤と全学共通 ID「SSO-KID」の紹介”，
九州大学情報統括本部 IT マガジン Vol.1, No.2, pp.42-48, 2007.
http://iii.kyushu-u.ac.jp/publish/magazine/ITmag_Vol1No2/SSO-KID.pdf[2] 伊東栄典,全学共通認証事業室: “全学共通認証基盤サービスの紹介 −全学共通 ID 発行，認証機能の提供，およびサーバ証明書の配付−”，情報統括本部 IT マガジン Vol.2, No.1, 2008.
http://iii.kyushu-u.ac.jp/publish/magazine/ITmag_Vol2No1/zengaku.pdf[3] 菅尾貴彦，戸川忠嗣，太田美和，橋倉聡，平野広幸，伊東栄典，市川広大，先立英喜：全学共通認証基盤サービスの手続きの電子化について，第 20 回 全国共同利用情報基盤センター 研究開発
連合発表講演会 研究開発論文集, pp.77-86, Nov. 2008. (ISSN 0910-8769)[4] 平野広幸，全学 IT 支援事業室：“情報統括本部のホスティングサービスについて”，九州大学情報統括本部 IT マガジン Vol.2, No.2, 2008.
[5] SSO ポータル：https://sso.kyushu-u.ac.jp/-8-