4.3

メール処理方式
本処理方式は、処理結果電文を一定時間経過後に NACCS センターサーバに対して取りに行く方式である。そのため、インタラクティブ処理方式（SMTP 双方向）などと比較すると、処理要求電文の応答は遅くなる。また、本処理方式は、利用者システム配下のパソコンのみ利用することが可能であり、NACCS EDI 電文の作成負荷を軽減することが可能である。
なお、メール処理方式として、NACCS EDI 電文によるメール処理方式と、EDIFACT 電文によるメール処理方式があるが、電文構造が異なるほかは、基本的に同じ方式となっている。
また、メール処理方式では、利用者は 1 度に複数件の処理要求電文の送信が可能であるが、処理結果電文は、一定時間経過後に NACCS センターサーバに対して、一括して取りに行く（受信する）必要がある。

4.3.1

NACCS EDI電文によるメール処理方式

4.3.1.1

処理方式概要（EDIFACT電文以外）

NACCS EDI 電文によるメール処理方式には、利用者が開発したソフトを利用する。
NACCS EDI 電文によるメール処理方式の処理方式の概要を図 4-3-1 に示す。なお、e-mail 送
信については、「4.6.1 e-mail」を参照すること。

① SMTP
NACCS EDI電文

SMTPヘッダー
NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文（１件ずつ送信）

メイン
処理部

メール
サーバ
ゲートウェイコンピュータ② POP3（利用者主導の取り出し）NACCS EDI電文
SMTPヘッダー
NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文

利用者
システム

図 4-3-1

NACCS センターサーバ

NACCS EDI 電文によるメール処理方式の接続形態概要① 利用者は、業務において必要とされる項目が格納された NACCS EDI 電文を作成し、メールサーバに対し SMTP にて送信する。このとき、1 度に複数件の電文送信が可能である。
② メールサーバに送られた電文は、メイン処理部に 1 件ずつ転送される。メイン処理部で業
務処理を行った後、処理結果電文をメールサーバ内利用者メールボックスに転送する。利用者は、メールボックスから POP3 にて電文の取り出しを行うことにより処理結果を受信する。

4-3-1

4.3.1.2

通信プロトコルの詳細

NACCS EDI 電文によるメール処理方式の通信プロトコルには、ネットワーク・トランスポート
層に TCP/IP 、その上位層には、処理要求電文の送信には SMTP、処理結果電文の取り出しには
POP3 を採用する。
(1) 処理要求電文送信時の SMTP 仕様(A) 対応する SMTP コマンド
NACCS EDI 電文によるメール処理方式で対応する SMTP コマンドとそのレスポンスの一覧を
表 4-3-1 に示す。

コマンド

HELO
MAIL
RCPT
DATA
RSET
QUIT

表 4-3-1
概要

対応する SMTP コマンド一覧
パラメータ

通信経路の使用開始宣言とホストの識別
メール処理の開始
メール受信者の指定
メール本文の送信開始
メール転送の中止
接続終了要求送信側ホスト名（ドメイン名）FROM:送信者名
TO:宛先ユーザ名
メッセージデータ
なし
なし

4-3-2

250
250
250
354
250
221

センター側メール
サーバの応答（正常レスポンス）

(B) SMTP 送信時のコマンドシーケンス
利用者システムからセンター側サーバに処理要求電文を送信する際の SMTP コマンドレベル
でのシーケンスを、表 4-3-2 に示す。また、各コマンドの説明を表 4-3-2 に示す。

コネクション接続要求 （TCPポート25番）
正常応答（220）
クライアントホストの識別
HELO ZZZZZ.ABC01.NACCS6
正常応答（250）
メール処理の開始
MAIL FROM:AAXXXX@ZZZZZ.ABC01.NACCS6
正常応答（250）
メール受信者の指定
RCPT TO:NACCS@MAIL.PROD.NACCS6
正常応答（250）
１電文

メール本文（処理要求電文）の送信開始
DATA
正常応答（354）
１行ずつ送信(１行1000byte以内)
・・・１行ずつ送信．CRLF
正常応答（250）

ゲートウェイコンピュータ

メール処理の開始
MAIL FROM:AAXXXX@ZZZZZ.ABC01.NACCS6

メールサーバ

正常応答（250）
メール受信者の指定
RCPT TO:NACCS@MAIL.PROD.NACCS6
正常応答（250）

１電文

メール本文（処理要求電文）の送信開始
DATA
正常応答（354）
１行ずつ送信(１行1000byte以内)
・・・１行ずつ送信．CRLF
正常応答（250）
接続終了要求QUIT

注

正常応答（221）
コネクション切断要求

利用者
システム

NACCS
センターサーバ

図 4-3-2 処理要求電文送信時の SMTP コマンドシーケンス(対メールサーバにおける 1 コネクション 2 電文送信例)
4-3-3

(注)図 4-3-2 で全ての電文送信が完了した後 2 分、利用者システムのゲートウェイコンピュー
タから QUIT コマンドを発行しない場合、センター側メールサーバでコネクションタイムア
ウトを発行し、強制的に接続切断を行う。このため、メール処理方式利用者は、全ての処理
要求電文の送信が完了した時点で、QUIT コマンドを発行すること。

表 4-3-2
項
番
1

コマンド等
コネクション接続要求

2

HELO ドメイン名

3

MAIL FROM:メールアドレス

4

RCPT TO:メールアドレス

5

DATA

6

メール本文の送信

SMTP 送信時のコマンド説明
説明

利用者は、センター側メールサーバの 25 番ポートに対してコ
ネクション接続要求を行うこと。
センター側メールサーバは、正常応答として応答コード 220 を返す。
センター側メールサーバの IP アドレスは、NACCS センターのDNS に問い合わせを行うことで取得できる。
利用者は、利用者システム側のドメイン名を設定してコマンドを実行すること。センター側メールサーバは、サーバが利用可
能な場合、SMTP コネクションを開始する。
センター側メールサーバは、正常応答として応答コード 250 を返す。
利用者システム側のドメイン名は、事前に NACCS センターが通知する。
利用者は、利用者側メールアドレスを設定してコマンドを実行すること。
センター側メールサーバは、正常応答として応答コード 250 を返す。
利用者側メールアドレスは事前に NACCS センターが通知する。
利用者は、NACCS センターサーバ側メールアドレス(NACCS@MAI
L.PROD.NACCS6)を設定してコマンドを実行すること。
センター側サーバは、正常応答として応答コード 250 を返す。
利用者は、処理要求電文の送信開始コマンドを実行すること。
センター側メールサーバは、正常応答として応答コード 354 を返す。
この後、利用者は、電文(通信プロトコルヘッダーを含む)を送信することが可能となる。
利用者は、NACCS の業務仕様に則り処理要求電文を送信する。
１つの処理要求電文の終端には、.(ドット)のみの行を送信すること。
終端を受信した後、センター側メールサーバは、正常応答として応答コード 250 を返す。
(注 1)1000 バイトごとに改行<CRLF>が必要となるが、NACCS のEDI 仕様では、1000 バイト以内に改行<CRLF>が入る仕様となっているため、特に意識する必要はない。
(注 2)SMTP では、電文の終端を<CRLF>.<CRLF>で認識するため、電文の途中に「．」が先頭に位置する行がある場合、利用者システムでダミーの「．」をその直前に付加すること。センター側メールサーバでは、ダミーの「.」を削除してメイン処理部に引き渡す。
4-3-4

項
番
7

コマンド等
RSET

8

QUIT

説明
利用者が本コマンドを実行すると、HELO 直後の状態に戻る。
センター側メールサーバは、正常応答として応答コード 250 を返す。
(本コマンドは、正常時には実行する必要は無い。)
利用者は、SMTP のコネクションを終了する。
センター側メールサーバは、正常応答として応答コード 221 を返す。

（注 1）SMTP の応答コードについて
各応答コード 3 桁の後ろには、任意の文字列が続くが、先頭 3 桁のみ参照すること。
例）HELO の応答
250 MAIL.PROD.NACCS6
応答コードのみ参照し、表 4-3-3 で示す対処を行うこと。
※理由：後ろの文字列は、NACCS センターサーバの仕様変更に伴い変更される可能性があるため。
（注 2）タイムアウト監視について
利用者システムは、センター側メールサーバやネットワークの障害などを検知できるよ
う、SMTP コネクションのタイムアウト監視を行うこと。
本仕様においては、同一コネクションで複数の電文送信を可能としており、SMTP コネク
ションのタイムアウト時間を規定することはできないため、利用者の運用方法にあわせて監視時間を定めること。

4-3-5

（C）異常時の対処
SMTP 送信時にエラーが発生した場合の対処を表 4-3-3 に示す。
表 4-3-3
項
番
1

コマンド等
コネクション
接続要求

2

HELO

3

MAIL FROM

SMTP のシーケンスエラーにおける対処想定されるエラーと対処

センター側メールサーバに接続要求を行ったが、接続要求が受け付けられない。
＜原因と対処＞
・宛先 IP アドレスが間違っている。
→NACCS センターから通知されたセンター側メールサーバの IP アドレスに接続しているか確認する。
・宛先ポート番号が間違っている→25 番ポートに接続要求しているか確認する。
・NACCS センターサーバがメンテナンス中である。
→NACCS センターサーバのメンテナンス情報は、NACCS 掲示板に公開されているのでそれを確認する。メンテナンス中である場合、メンテナン
ス終了後に再度接続を行う。
・NACCS センターサーバやネットワークが障害中である。
→暫くしてから再度接続要求を行う。長時間復旧しない場合は、NACCS セ
ンターのヘルプデスクに調査依頼を行う。障害情報については、NACCS 掲
示版にも掲載される。
なお、接続試験用のサーバのメンテナンス情報、障害情報については、
NACCS 掲示板に掲載されないので、接続試験可能な時間帯にも関わらずサーバに接続できない場合は、NACCS センターに NACCS センターサーバの状況を確認すること。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)である。
→HELO コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-2 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)またはパラメータエラー(501)またはドメイン名のエラー(553)である。
→MAIL コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-2 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、接続要求から
やり直す。

4-3-6

項
番
4

コマンド等

想定されるエラーと対処

RCPT TO

エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)またはパラメータエラー(501)またはドメイン名のエラー(553)である。
→RCPT コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-2 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。

5

DATA

エラー応答（正常応答(354)以外）が返される。
＜原因と対処＞①文法エラー(500)である。
→DATA コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-2 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。

6

処理要求電文
の送信

7

RSET

8

QUIT

9

その他

通信途中でエラーとなる。
＜原因と対処＞
センター側メールサーバが障害となっている可能性があるため、暫くしてから再度送信を行う。長時間復旧しない場合は、NACCS センターのヘルプ
デスクに調査依頼を行う。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞
文法エラー(500)である。
→RSET コマンドの送信文字列が正しいか確認する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。
エラー応答（正常応答(221)以外）が返される。
＜原因と対処＞
文法エラー(500)である。
→QUIT コマンドの送信文字列が正しいか確認する。
通信途中でコネクションの異常を検出する。
＜原因と対処＞
障害発生の可能性があるため、コネクション接続要求からやり直す。

4-3-7

(2) 処理結果電文送信時の POP3 仕様(A) 対応する POP3 コマンド
POP3（Post Office Protocol version3）については、基本的に RFC「Request For Comments」（RFC1939）に準拠するものとする。但し、認証交換方式の１つである APOP には対応しない。
NACCS EDI 電文によるメール処理方式で対応する POP3 コマンドとそのレスポンスの一覧を
表 4-3-4 に示す。

表 4-3-4

コマンド

USER
PASS
STAT

LIST

使用する POP3 コマンド一覧
概要
パラメータ
センター側メール
サーバの応答（正常レスポンス）
メールアドレスの送信 メールアドレス+OK
メールボックスパスワ メールボックス
+OK
ードの送信
パスワード
メールの電文数、電文なし+OK 電文数 電文総サイズ
サイズの問い合わせ+OK
メッセージ番号 メッセージサイズ
・・
全体の情報問い合わせ なし
・メッセージ番号 メッセージサイズ．
特定の情報問い合わせメッセージ番号

RETR

メール本文の取り出しメッセージ番号
要求

DELE
QUIT

メール本文の削除要求
通信終了（完了通知）

メッセージ番号なし

4-3-8+OK メッセージ番号ズ+OK
業務電文 (複数行)
.
+OK
+OK

メッセージサイ(B) 処理結果電文受信時の POP3 コマンドシーケンス
メール処理方式における、POP3 による処理結果電文の取り出しシーケンスを図 4-3-3 に示す。本シーケンスは、メールサーバ接続時点での処理結果電文数を取得する際に、STAT コマ
ンドを使用した場合の例である。また、各コマンドの説明を表 4-3-5 に示す。

コネクション接続要求(TCPポート110番)
正常応答（+OK）

USER ZZZZZ.ABC01.NACCS6 [利用者メールアドレス送信]
正常応答（+OK）
PASS パスワード [認証要求]
正常応答（+OK）
STAT [電文数、電文総サイズ取得要求]
正常応答（+OK 電文数 電文総サイズ）
RETR メッセージ番号 [電文取り出し要求]
正常応答（+OK）※応答として電文内容を複数行にわたり送信（<CRLF>.<CRLF>で終了）
DELE メッセージ番号 [電文削除要求]

ゲートウェイコンピュータ

メール
サーバ

正常応答（+OK）...（上記RETRコマンドからDELEコマンドのシーケンスを
STATコマンドの応答にて得られた電文数分、繰り返す）...
QUIT [終了要求]
正常応答（+OK）
コネクション切断

利用者
システム

NACCS
センターサーバ
図 4-3-3

処理結果電文受信時の POP3 コマンドシーケンス

4-3-9

表 4-3-5

POP3 受信時のコマンド説明項番
1

コネクション接続要求

利用者は、センター側メールサーバの 110 番ポートに対してコ
ネクション接続要求を行うこと。センター側メールサーバは、
正常応答として+OK を返す。
センター側メールサーバの IP アドレスは、NACCS センターのDNS に問い合わせを行うことで取得できる。

2

USER メールアドレス

利用者は、利用者側メールアドレスを設定してコマンドを実行すること。センター側メールサーバは、正常応答として+OK を返す。
利用者側メールアドレスは事前に NACCS センターが通知する。

3

PASS POP パスワード

利用者は、POP パスワードを設定してコマンドを実行すること。
USER コマンドにて指定されたメールサーバと、本コマンドにて指定した POP パスワードとでユーザ認証を行い、成功した場合は、正常応答として+OK を返す。
POP パスワードは、事前に NACCS センターが通知する。

4

STAT

現在のコネクションにおいて取得可能である電文数、電文総サイズを取得する場合、利用者は、本コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを
返す。

5

LIST

コマンド等

説明

+OK△電文数△電文総サイズ（バイト単位）
現在のコネクションにおいて取得可能である各電文のメッセ
ージ番号、メッセージサイズを取得する場合、利用者は、本コ
マンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK
メッセージ番号△メッセージサイズ
メッセージ番号△メッセージサイズ～
メッセージ番号△メッセージサイズ.

6

LIST メッセージ番号(注 1)”.”は、応答の終端を示す通信プロトコルトレーラーである。
(注 2) メッセージサイズの単位は、バイトである。
現在のコネクションにおいてメッセージ番号が示す電文のメッセージサイズを取得する場合、利用者は、本コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK△メッセージ番号△メッセージサイズ（バイト単位）

4-3-10

項
番
7

コマンド等
RETR メッセージ番号

説明
メッセージ番号を指定してメールボックスからメールを読み出す場合、利用者は、本コマンドを実行すること。センター側
メールサーバは、正常応答として次のレスポンスを返す。
+OK
業務電文（複数行）.
(注 1)”.”は、応答の終端を示す通信プロトコルトレーラーである。POP3 では、電文の終端を<CRLF>.<CRLF>で認識する
ため、電文内に行頭が「．」である行が存在する場合、利用者には、その行頭に「．」を付加したうえで応答を返す。利
用者は、受信した応答電文の行頭が「．」で続く文字列が<CRLF>でなかった場合は、行頭の「.」を取り除くこと。

8

DELE メッセージ番号

RETR コマンドによって受信した電文のメッセージ番号を指定
してメールボックスからメールを削除する場合、利用者は、本コマンドを実行すること。センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK(注 1)指定されたメッセージのメール領域からの削除は、QUIT
コマンドによるコネクション正常終了時に確定される。
QUIT が正常に受け付けられる以前に POP3 からの異常応答、障害によるコネクション切断が発生した場合は、コネクシ
ョン再接続時に DELE コマンドが既に正常終了していたメッセージについても再受信可能な状態になっている点に留意すること。

9

QUIT

利用者は、POP3 のコネクションを終了する際、コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返した後、利用者とのコネクションを切断する。
+OK（注意 1）POP の応答コードについて
応答コード（+OK,-ERR）の後には、スペース 1 バイトを挟み、要求コマンド固有の応答情報が続く場合があるが、表 4-3-5 内で説明されているもののみ参照すること。
（注意 2）△は、スペースを示す

4-3-11

利用者が受信用メールボックスに対して処理結果電文の取り出し要求を行う際には、直前の取り出し要求によって電文の削除が完了し QUIT コマンドによる完了通知を行った後、次の接続までに必ず NACCS センターが指定する一定時間（3 分）以上の間隔をあけなければならない。利
用者が受信用メールボックスに対し処理結果電文の取り出し要求を頻繁に行うと、メールサー
バが高負荷状態となる。その結果、レスポンスが遅延し、処理結果電文の内容の確認に時間がかかってしまうためである。
また、利用者は、RETR コマンドを発行して電文の取り出しを完了した後には、必ず DELE コマ
ンドを発行し、メールボックス内の取り出し済み電文を削除しなければならない。

4-3-12

（C）異常時の対処
POP3 による電文受信時にエラーが発生した場合の対処を表 4-3-6 に示す。
表 4-3-6
項
番
1

2

コマンド等

POP3 のシーケンスエラーにおける対処想定されるエラーと対処

コネクション
接続要求

センター側メールサーバに接続要求を行ったが、接続要求が受け付けられない。
＜原因と対処＞
・宛先 IP アドレスが間違っている。
→NACCS センターから通知されたセンター側メールサーバの IP アドレスに接続しているか確認する。
・宛先ポート番号が間違っている→110 番ポートに接続要求しているか確認する。
・センターがメンテナンス中である。
→センターのメンテナンス情報は、NACCS 掲示板に公開されているのでそれを確認する。メンテナンス中である場合、メンテナンス終了後に再度接続を行う。
・NACCS センターサーバやネットワークが障害中である。
→暫くしてから再度接続要求を行う。長時間復旧しない場合は、NACCS セ
ンターのヘルプデスクに調査依頼を行う。
障害情報については、NACCS 掲示版にも掲載される。
なお、接続試験用のサーバのメンテナンス情報、障害情報については、NACCS
掲示板に掲載されないので、接続試験可能な時間帯にも関わらずサーバに接続できない場合は、NACCS センターに NACCS センターサーバの状況を確認
すること。

USER

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→USER コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド実行前に、コマンドを実行する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

3

PASS

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→PASS コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→USER コマンド実行後に、コマンドを実行する。
③認証エラーである。
→USER コマンドにおいて指定した利用者側メールアドレス、PASS コマンドにおいて指定した POP パスワードの内容を確認し、再度コネクション
接続要求の手順からやり直す。
4-3-13

項
番

コマンド等

想定されるエラーと対処
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、接続要求からやり直す。
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→STAT コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

4

STAT

5

LIST

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→LIST コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

6

RETR

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→RETR コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
③指定したメッセージ番号に相当する電文が存在しない、または同一コネクションにおいて既に DELE コマンドを用いた削除要求が行われているメッ
セージ番号である。
→正しいメッセージ番号を指定して、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

4-3-14

項
番
7

コマンド等
DELE

想定されるエラーと対処
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→DELE コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
③指定したメッセージ番号に相当する電文が存在しない、または同一コネクションにおいて既に DELE コマンドを用いた削除要求が行われているメッ
セージ番号である。
→正しいメッセージ番号を指定して、コマンドを実行する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

8

QUIT

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→QUIT コマンドの送信文字列が正しいか確認する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

9

その他

通信途中でコネクションが切断される。
＜原因と対処＞
障害発生の可能性があるため、コネクション接続要求からやり直す。

4-3-15

4.3.1.3

電文構造

メール処理方式を使用する場合は、NACCS EDI 電文、添付ファイル電文および XML 形式電文に通信プロトコルヘッダー及び通信プロトコルトレーラーが付加される。
以降に各形式の電文構造の概要を示す。
(1) NACCS EDI 電文の場合
NACCS EDI 電文の概要（メール処理方式）を図 4-3-4 に示す。

NACCS EDI電文通信プロトコルヘッダー（SMTPヘッダー）

入力（出力）
共通項目

業務個別項目通信プロトコルトレーラー（SMTPトレーラー）

最大 700,000 バイト（注）（「3. 電文方式と構造」参照）（ 「4.3.1.3(4)SMTPヘッダーの格納内容(A)NACCS EDI電文の場合」参照）

・ ・ ・ ・ ・ ・ ・

Ｓ
ｕ
ｂ
ｊ
ｅ
ｃ
ｔ

（「4.3.1.3 (5) SMTPヘッダーのSubjectの内容」参照）
図 4-3-4

NACCS EDI 電文の概要（メール処理方式）（注）なお、関連省庁システムの業務で送受信する電文の最大長は、3.1.2 NACCS EDI 電文の電文構造 表 3-1-1 を参照

メール処理方式利用者が NACCS EDI 電文を NACCS センターサーバへ送信する際に作成する電文の形態を、図 4-3-5 に示す。
① SMTP ヘッダーの後の“<CRLF>”に続けて NACCS EDI 電文を始める。
② NACCS EDI 電文に“．”(ピリオド)、<CRLF>を続けて、通信プロトコルトレーラーとする。

4-3-16

通信プロトコルヘッダー（ SMTPヘッダー）

From:
……

C
R

L
F

To:
……

C
R

L
C
MimeF Version:1.0 R

ContentType:LC
Text/plain;F
R
charset="EUC-JP"

C
R

L
F
…

C
R

L
F

業務個別項目

…

C
R

L
F

…

図4-3-5

C
R

L
F

C
R

L
F

通信プロトコルトレーラー（SMTP）NACCS EDI電文
入力共通項目ContentTransferEncoding:
8bit

L
F

…

C
R

L
.
F

C
R

L
F

電文の内容

(参考)上記の電文構造をテキストエディター等のテキスト形式で見た場合、以下のようになる。
From:XXXXXXXX...XXX<CRLF>
To:XXXXXXXX...XXX<CRLF>
Mime-Version:1.0<CRLF>

通信プロトコルヘッダー（SMTP ヘッダー）

Content-Type:Text/plain;charset="EUC-JP"<CRLF>
Content-Transfer-Encoding:8bit<CRLF><CRLF>XXXXXXXXXXX.....XXX<CRLF>
XXXX...XXX<CRLF>
XXXX...XXX<CRLF>
XXXX...XXX<CRLF>.<CRLF>

入力共通項目業務個別項目NACCS EDI
電文
通信プロトコルトレーラー（SMTP トレーラー）※ 「<CRLF>」については、テキストエディター等により見え方が異なることがある。

! 通信プロトコルトレーラーについて
SMTPでは、電文の最後に“．<CRLF>”（ピリオドのみの行）を付加し、電文の最後に存在する“<CRLF>”と合わせた“<CRLF>．<CRLF>”を認識することによって、電文の終了を判断できるようになっている。
! 通信プロトコルトレーラーと“．”（ドット）の区別”.”は、応答の終端を示す通信プロトコルトレーラーである。SMTP、POP3 では、電文の終端を<CRLF>.<CRLF>で認識するため、電文内に行頭が「．」である行が存在する場合、センター側では、利用者に対してその行頭に「．」を付加(バイトスタッフ）したうえで応答を返す。通信プロトコルトレーラーと区別するため、利用者は、受信した応答電文の行頭が「．」で続く文字列が<CRLF>でなかった場合は、行頭の「.」を削除すること。
バイトスタッフを正しく削除しない場合、“．”（ドット）が本来よりも 1 つ多く出力されたり、電文長が 1 バイト長いといったエラーが利用者システム側で発生する。

4-3-17

(2) 添付ファイル電文の場合添付ファイル電文の概要（メール処理方式）を図 4-3-6 に示す。
なお、NACCS で使用可能な添付ファイルについては、「4.6.2 添付ファイルについて」を参照すること。

添付ファイル電文
通信プロトコルヘッダー（SMTPヘッダー）

添付
データ(添付ファイル登録業務等)
1
NACCS EDI電文

・・・

添付
データ
n

通信プロトコルトレーラー（SMTPトレーラー）

最大 10,000,000バイト(注)（「3.電文方式と構造」参照）（「4.3.1.3(4)SMTPヘッダーの格納内容(B)添付ファイル電文の場合」参照）

図 4-3-6添付ファイル電文の概要（メール処理方式）（注）なお、関連省庁システムの業務で送信する添付データ部の最大電文長は、3.1.2 NACCS EDI
電文の電文構造 表 3-1-1 を参照

メール処理方式利用者が添付ファイル電文を NACCS センターサーバへ送信する際に作成する
電文の形態を、図 4-3-7 に示す。
①

格納方法
NACCS では、添付ファイル電文の送受信時に MIME（Multipurpose Internet Mail Extensions）の BASE64 を使用する。添付ファイル電文は、メールの添付ファイルの形式で格納する。
添付ファイル電文送信時の詳細規定は、以下のとおりとする。
・ MIME のバージョンは、1.0 とする。
・ SMTP ヘッダー部の Content-Type は、Multipart/mixed、NACCS 電文部の Content-Type
は、Text/plain、添付ファイル部の Content-Type は、添付ファイル次第でそれぞれ設定する。
・ 添付ファイル部の Content-Transfer-Encoding は、BASE64 を指定する。
・ NACCS EDI 電文は、省略することはできない。また、添付ファイル部は、NACCS EDI 電
文の後方に位置する必要がある。
・ Content-Disposition には、attachment を設定し、filename にはファイル名を設定する。

②

電文イメージ・ 添付ファイル電文は、通信プロトコルヘッダー、本文、通信プロトコルトレーラーからなる。
・ SMTP ヘッダーの後の<CRLF>の後ろに、NACCS EDI 電文、BASE64 でエンコードした添付ファイル本体を設定する。
・ 添付ファイル電文に<CRLF>、“．”（ピリオド）、<CRLF>を続けて通信プロトコルトレー
ラーとする。

4-3-18

通信プロトコルヘッダー（ SMTPヘッダー）

From:
XXXXX

C
R

L
F

To:
XXXX

C
R

L
MimeC
F Version:1.0 R

L
F

Content-Type:multipart/
mixed;
boundary="YYYYYY"

C
R

L
F

C
R

L
F

C
R

L
F

C
R

L
F

本文
テキスト
-

-

(

(

ハ
イ
フ
ン

ハ
イ
フ
ン

)

)

YYY
YYY

C
R

テキスト

ContentType:LC
Text/plain;F
R
charset="EUC-JP"

ContentL Transfer- C
F Encoding: R
8bit （注）

L
F

C
R

NACCS
L EDI電文をF 参照する C
R
こと

L
F

本文
添付ファイル部
-

-

(

(

ハ
イ
フ
ン

ハ
イ
フ
ン

)

)

YYY
YYY

C
R

L
F

Content-Type:"添付ファイル C次第"; name= R"ファイル名"L
F

ContentTransferEncoding:
BASE64

本文

通信プロトコルトレーラー(SMTP)

添付ファイル部

YYY
YYY

-

(

L ハ ハ
F イ イ
フ フ
ン ン

-

(

-

(

C
R

-

(

添付ファイル
本体

C
R

ContentDisposition:
LC
attachment;
FR
filename="ファイル名"

ハ ハ
イ イ C
フ フ R
ン ン

L
．
F

C
R

L
F

)

)

)

)

（注）当該項目の設定値は、メールソフトに依存する。"8bit"は一例。

図 4-3-7

添付ファイル電文構造の例

4-3-19LF

<参考>前頁の電文構造をテキストエディター等のテキスト形式で見た場合、以下のようになる。
From:XXXXX…XXX<CRLF>
To:XXXXX…XXX<CRLF>
Mime-Version:1.0<CRLF>
Content-Type:multipart/mixed; boundary="YYYYYY"<CRLF><CRLF>--YYYYYY<CRLF>
Content-Type:Text/plain; charset="EUC-JP"<CRLF>
Content-Transfer-Encoding:8bit<CRLF><CRLF>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX…XXX<CRLF>

通信プロトコルヘッダー（SMTP ヘッダー）

NACCS EDI 電文<CRLF>--YYYYYY<CRLF>
Content-Type: "添付ファイル次第"; name="ファイル名"<CRLF>
Content-Transfer-Encoding: BASE64<CRLF>
Content-Disposition: attachment; filename="ファイル名"<CRLF>
繰り返し可能<CRLF>ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ…ZZ 添付ファイル本体<CRLF>--YYYYYY-<CRLF>
通信プロトコル.<CRLF>
トレーラー（SMTP トレーラー）

4-3-20(3) XML 形式電文の場合
XML 形式電文の概要（メール処理方式）を図 4-3-8 に示す。

XML形式電文
通信プロトコル
ヘッダー

XML電文

（SMTPヘッダー）

通信プロトコルトレーラー（SMTPトレーラー）

最大 700,000 バイト（「3. 電文方式と構造」参照）（「4.3.1.3(4)SMTPヘッダーの格納内容(C)XML形式電文の場合」参照）
図 4-3-8XML 形式電文の概要（メール処理方式）

メール処理方式利用者が XML 形式電文を NACCS センターサーバへ送信する際には、以下の形
態で電文を作成すること。
① SMTP ヘッダーの後の“<CRLF>”に続けて XML 形式電文を始める。
② XML 形式電文に<CRLF>、“．”(ピリオド)、<CRLF>を続けて通信プロトコルトレーラーとする。
③ 1000 バイトごとに改行すること。しない場合はエラーとなる。
④ XML 電文部については、一行ごとに<CRLF>が存在するものとする。
⑤ XML 電文部の文字コードは、EUC-JP とし、XML ヘッダーの encoding フィールドに EUC-JPを記載すること。
メール処理方式利用者が XML 形式電文を NACCS センターサーバへ送信する際に作成する電文構造の詳細については、「付録 15」及び「業務仕様書」を参照すること。

4-3-21

<参考>XML 形式電文の電文構造をテキストエディター等のテキスト形式で見た場合の一例を以下に示す。
From:XXXXX…XXX<CRLF>
To:XXXXX…XXX<CRLF>
Mime-Version:1.0<CRLF>
Content-Type:Text/xml; charset="EUC-JP"<CRLF>
Content-Transfer-Encoding:8bit<CRLF><CRLF>

通信プロトコルヘッダー(SMTP ヘッダー)<?xml version="1.0" encoding="EUC-JP" standalone="no" ?>- <RootElement>- <Header>- <DocumentType><DocumentTypeCode>XXX</DocumentTypeCode><DocumentTypeDescription>XX…XXX</DocumentTypeDescription></DocumentType>- <DocumentIdentification><MessageFunction> XX…XXX </MessageFunction><MessageTransferSequenceNo>XX</MessageTransferSequenceNo></DocumentIdentification><SenderID> XX…XXX </SenderID></Header>- <Body>・※XML 電文部
・
詳細は、「付録 15」及び「業務仕様書」参照
・・- <AdditionalInformation><InformationType> XX…XXX </InformationType></AdditionalInformation></Body></RootElement><CRLF>.<CRLF>

通信プロトコルトレーラー（SMTP トレーラー）

4-3-22

(4) SMTP ヘッダーの格納内容(A) NACCS EDI 電文の場合処理要求電文及び処理結果電文における SMTP ヘッダーの格納内容について以下に示す。

項番

１

２
３
４
５

① 処理要求電文
利用者が作成する処理要求電文において使用する SMTP ヘッダーの必須格納内容を表 4-37 に示す。
表 4-3-7 SMTP ヘッダー（処理要求電文）
項目
利用者が設定する内容
メール送信者を示す
NACCS では、NACCS センターから付与された送信元（利用者）メールア
From
ドレスを設定する設定されていない場合は、エラーとなる（「4.3.4 メールアドレス」を参照）
メール受信者を示す
NACCS では、メール処理方式用の NACCS センターサーバ側メールアドレ
Toスを設定する（「4.3.4 メールアドレス」を参照）
MIME-version
NACCS では、“1.0”を設定する
Content-Type
Text/plain;charset="EUC-JP"を設定する
Content-TransferNACCS では、文字を EUC で扱うため、"8bit"を設定する
Encoding② 処理結果電文
NACCS から利用者に出力される処理結果電文（処理結果通知電文、出力情報電文）において使用する SMTP ヘッダーの格納内容を表 4-3-8 に示す。
表 4-3-8
項番

項目

１

From

２

To

３
４
５
６

Date
Subject
MIME-version
Content-Type
Content-TransferEncoding

７

SMTP ヘッダー（処理結果電文）
NACCS センターサーバ内メールサーバが設定する内容
メール送信者を示す
NACCS では、メール処理方式用の NACCS センターサーバ側メールアドレ
スが設定される
（「4.3.4 メールアドレス」を参照）
メール受信者を示す
NACCS では、処理結果電文が格納される利用者の受信用メールボックスのメールアドレスが設定される（「4.3.4 メールアドレス」を参照）
利用者がメールを取り出した日時が設定される（「4.3.1.3 (5) SMTP ヘッダーの Subject の内容」を参照）
NACCS では、“1.0”を設定する
Text/plain;charset="EUC-JP"を設定する
NACCS では、文字を EUC で扱うため、"8bit"を設定する

4-3-23

(B) 添付ファイル電文の場合処理要求電文及び処理結果電文における SMTP ヘッダーの格納内容について以下に示す。
①

処理要求電文利用者が作成する処理要求電文において使用する SMTP ヘッダーの格納内容を表 4-3-9 に示す。
表 4-3-9

項番

項目
From

１
To
２

３

MIME-version
Content-Type

４

５

ContentTransferEncoding
Content-

６

Disposition

SMTP ヘッダー(処理要求電文)
利用者が設定する内容

メール送信者を示す
NACCS では、NACCS センターから付与された送信元（利用者）メールア
ドレスを設定する。設定されていない場合は、エラーとなる（「4.3.4 メールアドレス」を参照）
メール受信者を示す
NACCS では、メール処理方式用の NACCS センターサーバ側メールアドレ
スを設定する（「4.3.4 メールアドレス」を参照）
NACCS では、“1.0”を設定する
設定されていない場合には、当該メールは破棄される
SMTP ヘッダー部には、multipart/mixed;boundary="任意の値"を設定する
また、NACCS 電文部は、Text/plain、添付ファイル部は、添付ファイル次第で設定する設定されていない場合には、当該メールは破棄される
SMTP ヘッダー部には設定しない
NACCS 電文部には、8bit を設定し、添付ファイル部には、BASE64 を設定
する
SMTP ヘッダー部および NACCS 電文部には、設定しない
添付ファイル部には、attachment を設定し filename には、"ファイル名"を設定する②

処理結果電文NACCS から利用者に出力される処理結果電文において使用する SMTP ヘッダーの格納内容の詳細については、前述の「4.3.1.3 (4) SMTP ヘッダーの格納内容 (A)NACCS EDI 電文の場合 表 4-3-8」を参照すること。

4-3-24

(C) XML 形式電文の場合処理要求電文及び処理結果電文における SMTP ヘッダーの格納内容について以下に示す。
① 処理要求電文
利用者が作成する処理要求電文において使用する SMTP ヘッダーの必須格納内容を表 43-10 に示す。
表 4-3-10
項番

項目

SMTP ヘッダー（処理要求電文）
利用者が設定する内容

1

From

メール送信者を示す
NACCS では、NACCS センターから付与された送信元（利用者）メールア
ドレスを設定する。設定されていない場合は、エラーとなる（「4.3.4 メールアドレス」を参照）
メール受信者を示す
NACCS では、メール処理方式用の NACCS センターサーバ側メールアドレ
スを設定する（「4.3.4 メールアドレス」を参照）
NACCS では、“1.0”を設定する
設定されていない場合には、当該メールは破棄される

2

To

3

MIME-version

4

Content-Type

NACCS では、EUC で電文を扱うため、Text/xml;charset="EUC-JP"を設定
する

5

ContentTransferEncoding

NACCS では、文字を EUC で扱うため、"8bit"を設定する② 処理結果電文
NACCS から利用者に出力される処理結果電文において使用する SMTP ヘッダーの格納内容の詳細については、前述の「（「4.3.1.3 (4) SMTP ヘッダーの格納内容 (A)NACCS EDI 電文の場合 表 4-3-8」を参照すること。

4-3-25(5) SMTP ヘッダーの Subject の内容
NACCS センターサーバから利用者に送信される処理結果電文内の SMTP ヘッダー"Subject"に格納する内容について以下に示す。
① 目的
NACCS センターサーバ側で SMTP ヘッダーの"Subject"に以下の②に示す内容を設定することにより、利用者側でメールを開封することなく、メールに格納された処理結果電文の内容を判別可能とすることを目的とする。

② Subject の格納内容
処理結果通知電文と出力情報電文に共通のフォーマットを使用する。
Subject の内容を表 4-3-11 に示す。
表 4-3-11
項目名
業務個別
データ

Subject の内容

桁数

概要

64

例えば、処理結果コード、申告番号、B/L 番号が設定される（「付表 6-8 出力情報コード一覧」を参照）
各情報の区切りとしてスペースが設定される③ その他
Subject に格納する内容は、NACCS EDI 電文中にも含まれている情報であり、Subject の情報を必要としない利用者については、特に意識して使用する必要はない。
（破棄しても問題ない）

4-3-26

4.3.2EDIFACT電文によるメール処理方式

4.3.2.1

処理方式概要（EDIFACT電文）EDIFACT 電文によるメール処理方式は、NACCS EDI 電文によるメール処理方式と電文構造が異なるほかは基本的に同じ方式となっている。
NACCS における EDIFACT 電文によるメール処理方式の概要を図 4-3-9 に示す。なお、e-mail 送
信については、「4.6.1 e-mail」を参照すること。

① SMTP
NACCS EDI電文

SMTPヘッダー EDIFACT電文(MIME)SMTPヘッダー Air-NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文

ゲートウェイコンピュータ④ POP3（利用者主導の取り出し）（１件ずつ送信）

メール
サーバ

メイン
処理部
NACCS EDI電文

SMTPヘッダー EDIFACT電文(MIME)SMTPヘッダー Air-NACCS EDI電文
SMTPヘッダー Air-NACCS EDI電文

利用者
システム

NACCS センターサーバ

図 4-3-9

EDIFACT 電文によるメール処理方式の接続形態概要①

利用者は、業務において必要とされる項目が格納された EDIFACT 電文(メール)を作成し、メールサーバに対し SMTP（EDIFACT 電文を MIME 形式で添付）にて送信する。このとき、1 度に複数件の電文送信が可能である。

②

メールサーバでは、EDIFACT 電文を NACCS EDI 電文に変換した後、メイン処理部に転送する。

③

メイン処理部では、転送された電文に基づき業務処理を行った後、処理結果電文をメール
サーバ内の利用者メールボックスに転送する。メールサーバでは、NACCS EDI 電文を EDIFACT
電文に変換した後、メールサーバ内の利用者のメールボックスに EDIFACT 電文を MIME 形式
で格納する。

④

利用者は、メールボックスから POP3 にて電文(メール)の取り出しを行うことにより、処理結果を受信する。
4-3-27

4.3.2.2

通信プロトコルの詳細

EDIFACT 電文によるメール処理方式の通信プロトコルには、ネットワーク・トランスポート層に TCP/IP、その上位層には、処理要求電文の送信には、SMTP(MIME)、処理結果電文の取り出しには、POP3(MIME)を採用する。
(1) 処理要求電文送信時の SMTP 仕様(A) 対応する SMTP コマンド
EDIFACT 電文によるメール処理方式で対応する SMTP コマンドとそのレスポンスの一覧を表 43-12 に示す。

コマンド

HELO
MAIL
RCPT
DATA
RSET
QUIT

表 4-3-12

対応する SMTP コマンド一覧

概要

パラメータ

通信経路の使用開始宣言とホストの識別
メール処理の開始
メール受信者の指定
メール本文の送信開始
メール転送の中止
接続終了要求送信側ホスト名（ドメイン名）FROM:送信者名
TO:宛先ユーザ名
メッセージデータなし
なし

4-3-28

センター側
メールサーバの応答（正常レスポンス）
250
250
250
354
250
221

(B) 処理要求電文送信時の SMTP コマンドシーケンス
利用者システムからセンター側サーバに処理要求電文を送信する際(1 コネクション 2 電文送
信例)の SMTP コマンドレベルでのシーケンスを、図 4-3-10 に示す。また、各コマンドの説明を
表 4-3-13 に示す。
コネクション接続要求 （TCPポート25番）
正常応答（220）
クライアントホストの識別
HELO ZZZZZ.ABC01.NACCS6
正常応答（250）
メール処理の開始
MAIL FROM:AAXXXX@ZZZZZ.ABC01.NACCS6
正常応答（250）
メール受信者の指定
RCPT TO:NACCS@EDIFACT.PROD.NACCS6
正常応答（250）
１電文

メール本文（処理要求電文）の送信開始
DATA
正常応答（354）
１行ずつ送信(１行1000byte以内)
・・・１行ずつ送信．CRLF
正常応答（250）

ゲートウェイコンピュータ

メール処理の開始
MAIL FROM:AAXXXX@ZZZZZ.ABC01.NACCS6
正常応答（250）

メール
サーバ

メール受信者の指定
RCPT TO:NACCS@EDIFACT.PROD.NACCS6
正常応答（250）
１電文

メール本文（処理要求電文）の送信開始
DATA
正常応答（354）
１行ずつ送信(１行1000byte以内)
・・・１行ずつ送信．CRLF
正常応答（250）
接続終了要求QUIT

注

正常応答（221）
コネクション切断要求

利用者
システム
図 4-3-10

NACCS
センターサーバ

SMTP による処理要求電文の送信シーケンス（１コネクション２電文送信例）
4-3-29

表 4-3-13
項番
1

コネクション接続要求

2

HELO ドメイン名

3

MAIL FROM:メールアドレス

4

RCPT TO:メールアドレス

5

DATA

6

メール本文の送信

7

RSET

8

QUIT

SMTP 送信時のコマンド説明

コマンド等

説明
利用者は、センター側メールサーバの 25 番ポートに対してコ
ネクション接続要求を行うこと。
センター側メールサーバは、正常応答として応答コード 220 を返す。
センター側メールサーバの IP アドレスは、NACCS センターのDNS に問い合わせを行うことで取得できる。
利用者は、利用者システム側のドメイン名を設定してコマンドを実行すること。センター側メールサーバは、サーバが利用可
能な場合、SMTP コネクションを開始する。
センター側メールサーバは、正常応答として応答コード 250 を返す。
利用者システム側のドメイン名は、事前に NACCS センターが通知する。
利用者は、利用者側メールアドレスを設定してコマンドを実行すること。
センター側メールサーバは、正常応答として応答コード 250 を返す。
利用者側メールアドレスは、事前に NACCS センターが通知する。
利用者は、NACCS センターサーバ側メールアドレス(NACCS@EDI
FACT.PROD.NACCS6)を設定してコマンドを実行すること。
センター側サーバは正常応答として応答コード 250 を返す。
利用者は処理要求電文の送信開始コマンドを実行すること。
センター側メールサーバは、正常応答として応答コード 354 を返す。
この後、利用者は、電文(通信プロトコルヘッダーを含む)を送信することが可能となる。
利用者は、NACCS の業務仕様に則り処理要求電文を送信する。
１つの処理要求電文の終端には、.(ドット)のみの行を送信すること。
終端を受信した後、センター側メールサーバは正常応答として応答コード 250 を返す。
(注 1)1000 バイトごとに改行<CRLF>が必要となるが、NACCS のEDI 仕様では、1000 バイト以内に改行<CRLF>が入る仕様となっているため、特に意識する必要はない。
(注 2)SMTP では、電文の終端を<CRLF>.<CRLF>で認識するため、電文の途中に「．」が先頭に位置する行がある場合、利用者システムでダミーの「．」をその直前に付加すること。センター側メールサーバでは、ダミーの「.」を削除してメイン処理部に引き渡す。
利用者が本コマンドを実行すると、HELO 直後の状態に戻る。
センター側メールサーバは、正常応答として応答コード 250 を返す。
(本コマンドは、正常時には実行する必要は無い。)
利用者は、SMTP のコネクションを終了する。
センター側メールサーバは、正常応答として応答コード 221 を返す。

4-3-30(注)図 4-3-10 で全ての電文送信が完了した後 2 分、利用者システムのゲートウェイコンピュー
タから QUIT コマンドを発行しない場合、センター側メールサーバでコネクションタイムアウトを発行し、強制的に接続切断を行う。このため、メール処理方式利用者はゲートウェイ接続の場合、全ての処理要求電文の送信が完了した時点で、QUIT コマンドを発行すること。
（注 1）SMTP の応答コードについて
各応答コード 3 桁の後ろには、任意の文字列が続くが、先頭 3 桁のみ参照すること。
例）HELO の応答
250 EDIFACT.PROD.NACCS6
応答コードのみ参照し、表 4-3-14 で示す対処を行うこと。
※理由：後ろの文字列は NACCS センターサーバの仕様変更に伴い変更される可能性があるため。
（注 2）タイムアウト監視について
利用者システムは、センター側メールサーバやネットワークの障害などを検知できるよう、
SMTP コネクションのタイムアウト監視を行うこと。
本仕様においては、同一コネクションで複数の電文送信を可能としており、SMTP コネクシ
ョンのタイムアウト時間を規定することはできないため、利用者の運用方法にあわせて監視時間を定めること。

4-3-31

(C) 異常時の対処
SMTP 送信時にエラーが発生した場合の対処を表 4-3-14 に示す。
表 4-3-14
項
番
1

コマンド等
コネクション
接続要求

2

HELO

3

MAIL FROM

SMTP のシーケンスエラーにおける対処想定されるエラーと対処

センター側メールサーバに接続要求を行ったが、接続要求が受け付けられない。
＜原因と対処＞
・宛先 IP アドレスが間違っている。
→NACCS センターから通知されたセンター側メールサーバの IP アドレスに接続しているか確認する。
・宛先ポート番号が間違っている→25 番ポートに接続要求しているか確認する。
・NACCS センターサーバがメンテナンス中である。
→NACCS センターサーバのメンテナンス情報は、NACCS 掲示板に公開されているのでそれを確認する。メンテナンス中である場合、メンテナン
ス終了後に再度接続を行う。
・NACCS センターサーバやネットワークが障害中である。
→暫くしてから再度接続要求を行う。長時間復旧しない場合は、NACCS セ
ンターのヘルプデスクに調査依頼を行う。
障害情報については、NACCS 掲示版にも掲載される。
なお、接続試験用のサーバのメンテナンス情報、障害情報については、
NACCS 掲示板に掲載されないので、接続試験可能な時間帯にも関わらずサーバに接続できない場合は、NACCS センターに NACCS センターサーバの状況を確認すること。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)である。
→HELO コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-10 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)またはパラメータエラー(501)またはドメイン名のエラー(553)である。
→MAIL コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-10 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、接続要求からやり直す。

4-3-32

項
番
4

コマンド等

想定されるエラーと対処

RCPT TO

エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞①文法エラー(500)またはパラメータエラー(501)またはドメイン名のエラー(553)である。
→RCPT コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-10 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。

5

DATA

エラー応答（正常応答(354)以外）が返される。
＜原因と対処＞①文法エラー(500)である。
→DATA コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。(503)→図 4-3-10 に示す正しい順序でコマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。

6

処理要求電文
の送信

7

RSET

8

QUIT

9

その他

通信途中でエラーとなる。
＜原因と対処＞
センター側メールサーバが障害となっている可能性があるため、暫くしてから再度送信を行う。長時間復旧しない場合は、NACCS センターのヘルプ
デスクに調査依頼を行う。
エラー応答（正常応答(250)以外）が返される。
＜原因と対処＞
文法エラー(500)である。
→RSET コマンドの送信文字列が正しいか確認する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション
接続要求からやり直す。
エラー応答（正常応答(221)以外）が返される。
＜原因と対処＞
文法エラー(500)である。
→QUIT コマンドの送信文字列が正しいか確認する。
通信途中でコネクションの異常を検出する。
＜原因と対処＞
障害発生の可能性があるため、コネクション接続要求からやり直す。

4-3-33

(2) 処理結果電文受信時の POP3 仕様(A) 対応する POP3 コマンド
POP3（Post Office Protocol version3）については、基本的に RFC「Request For Comments」（RFC1939）に準拠するものとする。但し、認証交換方式の 1 つである APOP には対応しない。
EDIFACT 電文によるメール処理方式で対応する POP3 コマンドとレスポンスの一覧を表 4-3-15に示す。
表 4-3-15
コマンド

USER
PASS
STAT

概要

メールアドレスの送信
メールボックスパスワ
ードの送信
メールの電文数、電文
サイズの問い合わせ対応する POP3 コマンド一覧
パラメータ
センター側
メールサーバの応答（正常レスポンス）

メールアドレス+OK

メールボックス
パスワード

+OK

なし

+OK 電文数 電文総サイズ+OK
メッセージ番号 メッセージサイズ・・・
メッセージ番号 メッセージサイズ．

全体の情報問い合わせなし

特定の情報問い合わせメッセージ番号

LIST

RETR

メール本文の取り出しメッセージ番号
要求

DELE
QUIT

メール本文の削除要求
通信終了（完了通知）

メッセージ番号なし

4-3-34+OK メッセージ番号ズ+OK
業務電文 (複数行)
.
+OK
+OK

メッセージサイ(B) 処理結果電文受信時の POP3 コマンドシーケンス
メール処理方式における、POP3 による処理結果電文の取り出しシーケンスを図 4-3-11 に示す。本シーケンスは、メールサーバ接続時点での処理結果電文数を取得する際に、STAT コマン
ドを使用した場合の例である。また、各コマンドの説明を表 4-3-16 に示す。

コネクション接続要求(TCPポート110番)
正常応答（+OK）

USER ZZZZZ.ABC01.NACCS6 [利用者メールアドレス送信]
正常応答（+OK）
PASS パスワード [認証要求]
正常応答（+OK）
STAT [電文数、電文総サイズ取得要求]
正常応答（+OK 電文数 電文総サイズ）
RETR メッセージ番号 [電文取り出し要求]
正常応答（+OK）※応答として電文内容を複数行にわたり送信（<CRLF>.<CRLF>で終了）
DELE メッセージ番号 [電文削除要求]

ゲートウェイコンピュータ

メール
サーバ

正常応答（+OK）...（上記RETRコマンドからDELEコマンドのシーケンスを
STATコマンドの応答にて得られた電文数分、繰り返す）...
QUIT [終了要求]
正常応答（+OK）
コネクション切断

利用者
システム

NACCS
センターサーバ

図 4-3-11

処理結果電文受信時の POP コマンドシーケンス

4-3-35

表 4-3-16

POP3 受信時のコマンド説明項番
1

コネクション接続要求

利用者は、センター側メールサーバの 110 番ポートに対してコ
ネクション接続要求を行うこと。センター側メールサーバは、
正常応答として+OK を返す。
センター側メールサーバの IP アドレスは、NACCS センター側の
DNS に問い合わせることで取得できる。

2

USER メールアドレス

利用者は、利用者側メールアドレスを設定してコマンドを実行すること。センター側メールサーバは、正常応答として+OK を返す。
利用者側メールアドレスは、事前に NACCS センターが通知する。

3

PASS POP パスワード

利用者は、POP パスワードを設定してコマンドを実行すること。
USER コマンドにて指定されたメールサーバと、本コマンドにて指定した POP パスワードとでユーザ認証を行い、成功した場合は、正常応答として+OK を返す。
POP パスワードは、事前に NACCS センターが通知する。

4

STAT

現在のコネクションにおいて取得可能である電文数、電文総サイズを取得する場合、利用者は、本コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを
返す。

5

LIST

コマンド等

説明

+OK△電文数△電文総サイズ（バイト単位）
現在のコネクションにおいて取得可能である各電文のメッセ
ージ番号、メッセージサイズを取得する場合、利用者は、本コ
マンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK
メッセージ番号△メッセージサイズ
メッセージ番号△メッセージサイズ～
メッセージ番号△メッセージサイズ.

6

LIST メッセージ番号(注 1)”.”は、応答の終端を示す通信プロトコルトレーラーである。
(注 2) メッセージサイズの単位は、バイトである。
現在のコネクションにおいてメッセージ番号が示す電文のメッセージサイズを取得する場合、利用者は、本コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK△メッセージ番号△メッセージサイズ（バイト単位）

4-3-36

項
番
7

コマンド等
RETR メッセージ番号

説明
メッセージ番号を指定してメールボックスからメールを読み出す場合、利用者は、本コマンドを実行すること。センター側
メールサーバは、正常応答として次のレスポンスを返す。
+OK
業務電文（複数行）.
(注 1)”.”は、応答の終端を示す通信プロトコルトレーラーである。POP3 では、電文の終端を<CRLF>.<CRLF>で認識する
ため、電文内に行頭が「．」である行が存在する場合、利用者には、その行頭に「．」を付加したうえで応答を返す。利
用者は受信した応答電文の行頭が「．」で続く文字列が<CRLF>でなかった場合は、行頭の「.」を取り除くこと。

8

DELE メッセージ番号

RETR コマンドによって受信した電文のメッセージ番号を指定
してメールボックスからメールを削除する場合、利用者は、本コマンドを実行すること。センター側メールサーバは、正常応答として次のレスポンスを返す。
+OK(注 1)指定されたメッセージのメール領域からの削除は、QUIT
コマンドによるコネクション正常終了時に確定される。
QUIT が正常に受け付けられる以前に POP3 からの異常応答、障害によるコネクション切断が発生した場合は、コネクシ
ョン再接続時に DELE コマンドが既に正常終了していたメッセージについても再受信可能な状態になっている点に留意すること。

9

QUIT

利用者は、POP3 のコネクションを終了する際、コマンドを実行すること。
センター側メールサーバは、正常応答として次のレスポンスを返した後、利用者とのコネクションを切断する。
+OK（注意 1）POP の応答コードについて
応答コード（+OK,-ERR）の後には、スペース 1 バイトを挟み、要求コマンド固有の応答情報が続く場合があるが、表 4-3-16 内で説明されているもののみ参照すること。
（注意 2）△は、スペースを示す

4-3-37

利用者が受信用メールボックスに対して処理結果電文の取り出し要求を行う際には、直前の取り出し要求によって電文の削除が完了し QUIT コマンドによる完了通知を行った後、次の接続までに必ず NACCS センターが指定する一定時間(3 分)以上の間隔をあけなければならない。利用者が受信用メールボックスに対し処理結果電文の取り出し要求を頻繁に行うと、メールサーバが高負荷状態となる。その結果、レスポンスが遅延し、処理結果電文の内容の確認に時間がかかってしまうためである。
また、利用者は、RETR コマンドを発行して電文の取り出しを完了した後には、必ず DELE コ
マンドを発行し、メールボックス内の取り出し済み電文を削除しなければならない。

4-3-38

(C) 異常時の対処
POP3 による電文受信時にエラーが発生した場合の対処を表 4-3-17 に示す。
表 4-3-17
項
番
1

2

コマンド等

POP3 のシーケンスエラーにおける対処想定されるエラーと対処

コネクション
接続要求

センター側メールサーバに接続要求を行ったが、接続要求が受け付けられない。
＜原因と対処＞
・宛先 IP アドレスが間違っている。
→NACCS センターから通知されたセンター側メールサーバの IP アドレスに接続しているか確認する。
・宛先ポート番号が間違っている→110 番ポートに接続要求しているか確認する。
・NACCS センターサーバがメンテナンス中である。
→NACCS センターサーバのメンテナンス情報は、NACCS 掲示板に公開されているのでそれを確認する。メンテナンス中である場合、メンテナンス終了後に再度接続を行う。
・NACCS センターサーバやネットワークが障害中である。
→暫くしてから再度接続要求を行う。長時間復旧しない場合は、NACCS セ
ンターのヘルプデスクに調査依頼を行う。
障害情報については、NACCS 掲示版にも掲載される。
なお、接続試験用のサーバのメンテナンス情報、障害情報については、NACCS
掲示板に掲載されないので、接続試験可能な時間帯にも関わらずサーバに接続できない場合は、NACCS センターに NACCS センターサーバの状況を確認
すること。

USER

エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→USER コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド実行前に、コマンドを実行する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。

4-3-39

項
番
3

コマンド等
PASS

4

STAT

5

LIST

6

RETR

想定されるエラーと対処
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→PASS コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→USER コマンド実行後に、コマンドを実行する。
③認証エラーである。
→USER コマンドにおいて指定した利用者側メールアドレス、PASS コマンドにおいて指定した POP パスワードの内容を確認し、再度コネクション
接続要求の手順からやり直す。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、接続要求からやり直す。
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→STAT コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→LIST コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→RETR コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
③指定したメッセージ番号に相当する電文が存在しない、または同一コネクションにおいて既に DELE コマンドを用いた削除要求が行われているメッ
セージ番号である。
→正しいメッセージ番号を指定して、コマンドを実行する。
センター側メールサーバから応答が無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。
4-3-40

項
番
7

コマンド等
DELE

8

QUIT

9

その他

想定されるエラーと対処
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→DELE コマンドの送信文字列が正しいか確認する。
②コマンドの順序が誤っている。
→PASS コマンド要求の正常応答後に、コマンドを実行する。
③指定したメッセージ番号に相当する電文が存在しない、または同一コネクションにおいて既に DELE コマンドを用いた削除要求が行われているメッ
セージ番号である。
→正しいメッセージ番号を指定して、コマンドを実行する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。
エラー応答（-ERR）が返される。
＜原因と対処＞①文法エラーである。
→QUIT コマンドの送信文字列が正しいか確認する。
センター側メールサーバから応答無くタイムアウトする。
＜原因と対処＞
障害発生の可能性があるため、一旦コネクションを切断し、コネクション接続要求からやり直す。
通信途中でコネクションが切断される。
＜原因と対処＞
障害発生の可能性があるため、コネクション接続要求からやり直す。

4-3-41

4.3.2.3 電文構造
(1) EDIFACT 電文
EDIFACT 電文を使用する際は、EDIFACT 電文に通信プロトコルヘッダー及び通信プロトコルト
レーラーが付加される。
電文構造の概要を図 4-3-12 に示す。

EDIFACT電文
通信プロトコル
ヘッダー

EDIFACT電文(MIME)

通信プロトコルトレーラー（SMTPトレーラー）（SMTPヘッダー）

最大 10,000,000 バイト（「3. 電文方式と構造」参照）（「4.3.2.3 (2) SMTPヘッダーの格納内容」参照）

・ ・ ・ ・ ・ ・ ・

Ｓ
ｕ
ｂ
ｊ
ｅ
ｃ
ｔ

（「4.3.2.3 (3) SMTPヘッダーの Subject の内容」参照）

図 4-3-12

EDIFACT 電文の概要

メール処理方式利用者が EDIFACT 電文を NACCS センターサーバへ送信する際には、以下の形
態で電文を作成する。EDIFACT 電文構造の例を図 4-3-13、図 4-3-14 に示す。
①

格納方法
NACCS では、EDIFACT 電文の送受信時に MIME（Multipurpose Internet Mail Extensions）
を使用する。EDIFACT 電文は、メールの添付ファイルの形式で格納する。
MIME の詳細規定は、以下のとおりとする。
・ MIME のバージョンは、1.0 とする。
・ Content-Type は、Text/plain または Multipart/mixed とする。
・ Content-Transfer-Encoding は、BASE64 または Quoted-Printable とする。
・ EDIFACT 電文のみをエンコードする。
・ 添付できるファイル数は、1 ファイルのみとする（仮に利用者が複数のファイルを添付した処理要求電文を送信した場合、NACCS センターサーバでは、その内の先頭の 1
ファイルのみを処理し、残りのファイルは、処理対象外とする）。

②

電文イメージ・SMTP ヘッダーの後の“CRLF”に続けて EDIFACT 電文を BASE64 または Quoted-Printable
でエンコードした状態で始める。
・EDIFACT 電文に<CRLF>、“．”（ピリオド）、<CRLF>を続けて通信プロトコルトレーラーとする。
4-3-42

＜Content-Type に Text/plain が設定された場合＞
通信プロトコルヘッダー（ SMTPヘッダー）

From:
XXXXX

C
R

L
F

To:
XXXX

C
R

L
F

EDIFACT電文

XXXXXXXXXXXXXXX...XXXX(エンコードされた状態)

図 4-3-13

Date:
XXXXX

C
R

L
C
MimeF Version:1.0 R

ContentType:LC
Text/plain;F
R
charset="EUC-JP"

L
F

ContentTransferEncoding:
BASE64または
Quotedprintable

C
R

L
F

C
R

L
F

通信プロトコルトレーラー（SMTP）

C
R

L
.
F

C
R

L
F

EDIFACT 電文構造の例（Content-Type に Text/plain が設定された場合）(参考) 上記の電文構造をテキストエディター等のテキスト形式で見た場合、以下のようになる。
From:XXXXXXX…XXXX<CRLF>
To:XXXXXXXX…XXX<CRLF>
Date:XXXXXXX…XXXX<CRLF>
Mime-Version:1.0<CRLF>
Content-Type:Text/plain;charset="EUC-JP"<CRLF>
Content-Transfer-Encoding:BASE64<CRLF>（"BASE64"が"Quoted-printable"になる場合もある。）<CRLF>

通信プロトコルヘッダー（ SMTP ヘッダー）

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX…XXXEDIFACT 電文(エンコードされた状態)<CRLF>.<CRLF>

通信プロトコルトレーラ（SMTP トレーラー）! 通信プロトコルトレーラーと“．”（ドット）の区別”.”は、応答の終端を示す通信プロトコルトレーラーである。SMTP では、電文の終端を<CRLF>.<CRLF>で認識する。電文内に行頭が「．」である行が存在する場合、センター側では通信プロトコルトレーラーと区別するために、利用者に対してその行頭に「．」を付加(バイトスタッフ）したうえで応答を返す。利用者は、受信した応答電文の行頭が「.」であり続く文字列が<CRLF>でなかった場合は、行頭の「.」（バイトスタッフ）を削除すること。バイトスタッフを正しく削除しない場合、“．”（ドット）が本来よりも１つ多く出力されたり、電文長が 1 バイト長いといったエラーが利用者システム側で発生する。

4-3-43

＜Content-Type に Multipart が設定された場合＞

通信プロトコルヘッダー（ SMTPヘッダー）

From:
XXXXX

C L
R F

To:
XXXX

C L
R F

Date:
XXXXX

C L
MimeC LR F Version:1.0 R F

Content-Type:multipart/mixed;boundary="YYYYYY"C L
C L R F
R F

メール本文
テキスト

(

(

ハ ハ
イ イ
フ フ
ン ン

- ContentC
L
ContentTransferC L
C L
C L XXX C L R F ハ ハ
Type:
Encoding:
イ イ
R F
R F
R F ••XX R F
XXXXXXXX
7bit
フ フ
（注）
ン ン

YYY
YYY

(

L ハ ハ
F イ イ
フ フ
ン ン

-

(

-

(

(

EDIFACT電文
C L C LC
XXXX...XXXXR F R FR
(エンコードされた状態)C L
R FContent-Type;Text/plain;name="添付ファイル名"通信プロトコルトレーラー(SMTP)

添付ファイルYYY ハ ハ C L
YYY イ イ R F .

C L
R F

フ フ
ン ン
)

)

)

)

ContentTransferEncoding:
BASE64または
Quotedprintable

YYY
YYY

)

)

)

)

メール本文

(

-

(

-

添付ファイル（注）当該項目の設定値は、メールソフトに依存する。"7bit"は一例。
図 4-3-14

EDIFACT 電文構造の例（Content-Type に Multipart が設定された場合）

4-3-44C L
R F

(参考)前頁の電文構造をテキストエディター等のテキスト形式で見た場合、以下のようになる。
From:XXXXX…XXX<CRLF>
To:XXXXX…XXX<CRLF>
Date:XXXXX…XXX<CRLF>
Mime-Version:1.0<CRLF>
Content-Type:multipart/mixed; boundary="YYYYYY"<CRLF><CRLF>--YYYYYY<CRLF>
Content-Type:XX…X<CRLF>
Content-Transfer-Encoding:7bit<CRLF>
XXXXX…XXX<CRLF><CRLF>--YYYYYY<CRLF>
Content-Type:Text/plain; name="添付ファイル名" <CRLF>
Content-Transfer-Encoding:BASE64<CRLF>（"BASE64"が"Quoted-printable"になる場合もある。）<CRLF>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX…XXX<CRLF>--YYYYYY-<CRLF>.<CRLF>

通信プロトコルヘッダー（SMTP ヘッダー）

EDIFACT 電文（エンコードされた状態）

通信プロトコルトレーラー（SMTP トレーラー）③ 添付ファイルのファイル名
イ．処理要求電文
利用者で任意のファイル名を設定する。ファイル名は、以下のとおり。
形式：8.3 形式(XXXXXXXX.XXX)の計 12 文字以内
使用可能文字：半角英文字(大文字、小文字)、半角数字

ロ．処理結果電文
処理結果電文については、常に単一のファイル名を設定する。ファイル名は、以下のとおりとする。
SEANACCS.B64

4-3-45

(2) SMTP ヘッダーの格納内容
処理要求電文及び処理結果電文における SMTP ヘッダーの格納内容について以下に示す。
①

処理要求電文利用者が作成する処理要求電文において使用する SMTP ヘッダーの格納内容を表 4-3-18 に示す。
表 4-3-18

項番

項目

SMTP ヘッダー(処理要求電文)
利用者が設定する内容

1

From

メール送信者を示す
NACCS では、NACCS センターから付与された送信元（利用者）メールア
ドレスを設定する(「4.3.4 メールアドレス」を参照)
NACCS センターサーバ側でシステムに登録されているかをチェックし、未登録の場合は、当該メールは破棄される

2

To

メール受信者を示す
NACCS では、メールサーバのメールアドレスを設定する(「4.3.4 メールアドレス」を参照)

3

Date

NACCS では、利用者がメールを送付した日時を設定する

4

MIME-version

NACCS では、“1.0”を設定する
設定されていない場合には、当該メールは破棄される

5

Content-Type

NACCS では、Text/plain;charset="EUC-JP"を設定する。マルチパートタ
イプの場合、multipart/mixed;boundary="任意の値"を設定する
設定されていない場合には、当該メールは破棄される

6

ContentTransferEncoding

Content-Type に Text/plain が 設 定 さ れ た 場 合 、 "BASE64" ま た は"Quoted-Printable"を設定する
Content-Type に multipart/mixed が設定された場合、設定値は、メールソフトに依存する。この場合、メール本文中の添付ファイルのエンコード形式を"BASE64"または"Quoted-Printable"と設定する設定されていない場合には、当該メールは破棄される

4-3-46

②

処理結果電文NACCS から利用者に出力される処理結果電文（処理結果通知電文、出力情報電文）において使用する SMTP ヘッダーの格納内容を表 4-3-19 に示す。
表 4-3-19

項番
1

項目
From

SMTP ヘッダー(処理結果電文)
NACCS センターサーバで設定される内容

メール送信者を示す
NACCS では、メールサーバのメールアドレスが設定される

2

To

メール受信者を示す
NACCS では、処理結果電文が格納される利用者の受信用メールボッ
クスのメールアドレスが設定される

3

Date

利用者がメールを取り出した日時が設定される

4

Subject(「4.3.2.3 (3) SMTP ヘッダーSubject の内容」を参照)

5

MIME-

NACCS では、"1.0"が設定される

Version6

Content-

NACCS では、Text/plain;charset="EUC-JP"が設定される

Type
7

Content-

NACCS では、"BASE64"が設定されるTransferEncoding
8

Content-

NACCS では、attachment;filename="添付ファイル名"が設定される

Disposition

4-3-47

(3) SMTP ヘッダーSubject の内容
NACCS センターサーバから利用者に出力される処理結果電文内の SMTP ヘッダー"Subject"に格納する内容について以下に示す。
①

目的
NACCS センターサーバ側で SMTP ヘッダーの"Subject"に以下の②に示す内容を設定することにより、利用者側でメールを開封することなく、メールに格納された処理結果電文の内容を判別可能とすることを目的とする。

②

Subject の格納内容
処理結果通知電文と出力情報電文に共通のフォーマットを使用する。
Subject の内容を表 4-3-20 に示す。
表 4-3-20
項目名
業務個別データ

Subject の内容

桁

概要
例えば、処理結果コード、申告番号、B/L 番号、管理番号が設64 定される
各情報の区切りとしてスペースが設定される（「付表 6-8 出力情報コード一覧」を参照）③

その他
Subject に格納する内容は、EDIFACT 電文中にも含まれている情報であり、Subject の情報を必要としない利用者については、特に意識して使用する必要はない。
（破棄しても問題ない）

4-3-48

4.3.3

メールボックス(1) メールボックスの概要
NACCS においてメール処理方式を採用する利用者のために、NACCS センターサーバ内に、それぞれ送信用メールボックスと受信用メールボックスを設置する。
① 送信用メールボックス
利用者から NACCS に送信された処理要求電文を格納するメールボックスのことである。
利用者は、NACCS センターサーバ内のメールボックスに対し、電文を送信する。
送信用メールボックスは、全利用者で共用となる。
② 受信用メールボックス
NACCS で処理を行った結果出力される処理結果電文（処理結果通知電文、出力情報電文）を格納するメールボックスのことである。
利用者は、NACCS センターサーバ内のメールボックスから、電文の取り出し要求により、処理結果電文を取り出す。
利用者は、受信用メールボックスから処理結果電文を取り出す際にメールボックス ID 及び
メールボックスパスワードを使用することとなる。
メールボックス ID
電文の格納先であるメールボックスの識別子のことである。
電文の取り出し時に、メールボックスへのアクセス認証として使用する。
メールボックスパスワード
電文の取り出し時に、メールボックス ID とともにアクセス認証に使用する。
メールボックスの運用イメージを図 4-3-15 に示す。
電文送信
TO: メールサーバ

送信用
メールボックス

電文取り出しアクセス認証用
メールボックスID********
パスワード ************

受信用
メールボックス
ID:********

メール
処理方式

メールサーバ

利用者システム

メイン処理部

NACCS センターサーバ

図 4-3-15

メールボックスの運用イメージ
4-3-49(2) メールボックスの付与基準
NACCS センターサーバ内のメールボックスの総数は、システムの性能に影響を与えるため極力少なくすることが望ましい。
NACCS における接続形態別のメールボックスの付与基準を表 4-3-21 に示す。
また、受信用メールボックスの利用方法についての具体例を付録 10 に示す。
表 4-3-21

ゲートウェイ接続

メールボックスの付与基準
メールボックスの付与基準
利用者の希望するメールボックス数を付与する(3) 処理要求電文の処理順序
NACCS において、利用者から送信された処理要求電文は、NACCS センターサーバ内にある送信用メールボックスに格納され、送信用メールボックスから利用者コード単位で一電文ずつ取り出され、メイン処理部に転送される。

(4) 処理結果電文の取り出し
利用者が受信用メールボックスに対して処理結果電文の取り出し要求を行う際には、直前の取り出し要求から次の要求まで、NACCS センターが指定する一定時間(3 分)以上の間隔をあけなければならない。利用者が受信用メールボックスに対し処理結果電文の取り出し要求を頻繁に行うと、メールサーバが高負荷状態となる。その結果、レスポンスが遅延し、処理結果
電文の内容の確認に時間がかかってしまうためである。
また、利用者は、RETR コマンドを発行して電文の取り出しを完了した後には、必ず DELE コ
マンドを発行し、メールボックス内の取り出し済み電文を削除しなければならない。

受信用メールボックスを複数のゲートウェイコンピュータで共有した場合の注意点を図
4-3-16 に示す。

4-3-50

業務Ａ

処理要求電文ゲートウェイコンピュータ1

送信用メールボックス

メール処理方式

業務Ｂ

処理要求電文メイン処理部
ゲートウェイコンピュータ2

メール処理方式

業務Ａ’
業務Ｂ’

業務Ａ’
業務Ｂ’

受信用メール
ボックス

処理結果電文利用者
システム

処理結果電文

NACCS
センターサーバ
POP3による取り出しは、メールボ
ックス内の全ての電文を受信
POP3による１回の取り出し要求は、1つの受信用メールボックス内の全ての電文を受信する。
↓
複数のゲートウェイコンピュータで１つの受信用
メールボックスを共有する場合、例えば上図のゲートウェイコンピュータ1の処理要求に対応する処理結果もゲートウェイコンピュータ2で受信してしまう場合がある。

図 4-3-16

受信用メールボックスを複数のゲートウェイコンピュータで共有した場合の注意点(5) 電文のメールボックス内における保存期間
NACCS では、以下の方法で利用者から送信された処理要求電文、あるいは利用者が取り出す
処理結果電文を削除する。
① 処理要求電文
処理要求電文については、メールサーバからメイン処理部に転送された後に削除する。
② 処理結果電文
処理結果電文については、電文の取り出しを行った後に削除する。
なお、利用者が取り出していない処理結果電文については、メールボックスに登録された日を含めて、7 日間(土日祝日含む)は、電文をメールボックス内に保存する。電文の削除は、深夜の一定時刻に行われる。

4-3-51

(参考) メールボックス内処理結果電文の削除例（仮に一定時刻を 0:30 とした場合）
8/1（金）12:30
8/8（金）0:30｜
8/2（土）0:30
｜
↓
↓
8/3
8/4
8/5
8/6
8/7
↓
――――☆―――｜―――｜―――｜―――｜―――｜―――｜―――★――――｜｜｜←―――――――――電文の保存期間―――――――――→｜
｜
｜
登録
削除
(6) 同一電文の再送の制限
必要以上に電文の再送を行うと、NACCS システム全体に過度の負荷がかかり、処理能力の低下等の事態を招く原因となるため、利用者は、原則として全く同一の業務処理単位の処理要求
電文（例えば、同一 B/L の積荷目録情報登録）を重複して送信してはならない。
ただし、一定時間が経過した後でも処理結果電文が出力されない場合には、照会業務により業務処理されていないことを確認の上、同一の処理要求電文を送信しても差し支えない。

(7) 同一電文の再取り出し
１度取り出しを行った処理結果電文（処理結果通知電文または出力情報電文）を誤って紛失した場合、または、メールボックスでの電文の保存期間内に取り出しを行わなかった場合等、処理結果電文を再度取り出す必要がある場合は、以下の要領で電文の取り出しを行うことができる。ただし、処理結果通知電文については、再出力はできない。
① 照会業務については、再度、処理要求電文を送信することにより行う。
② 再出力可能な出力情報が存在するものについては、再出力業務を行う。
(8) メールボックスのオーバーフロー対策
NACCS では、利用者がメールボックスから取り出されたメールは、削除される。また、メールボックスから取り出されない未処理のメールについては 7 日間経過後、削除される。
そのため、NACCS のメールボックスにメールが蓄積し続けるような状況は考えづらく、メールボックスがオーバーフローする可能性は、極めて少ない。
しかしながら、万が一、メールボックスがオーバーフローする可能性が発生した場合、以下の対処によりオーバーフローの発生を回避する。
① 送信用メールボックス
NACCS では、NACCS センターサーバにおける送信用メールボックス領域の使用率が一定量を超えた場合、全利用者からの電文の受信を停止する。この場合、利用者には送信タイムア
ウトが応答される。利用者は、送信タイムアウトとなった電文を再送する必要があるため、利用者システム側には、作成した電文を一時保存する機能が必要となる。
② 受信用メールボックス
NACCS では、NACCS センターサーバにおける受信用メールボックス領域の使用率が一定量を超えた場合、メイン処理部からの受信用メールボックスに送信されてくる電文の受信を停止する。この場合、利用者は、速やかに受信用メールボックスから電文の取り出しを行う必要がある。
（NACCS センターから利用者に対し電話、FAX または NACCS 掲示板等により連絡を行う｡）
上記以外にも、例えばシステムの高負荷時には、全利用者からの電文の受信を停止する等の運用制限をかける場合がある。
（NACCS センターから利用者に対し電話、FAX または NACCS
掲示板等により連絡を行う。）
4-3-52

4.3.4

メールアドレス(1) 利用者側メールアドレスの概要と付与基準
NACCS のメール処理方式における利用者側メールアドレスのアカウントは、メールボックス
ID と同一とする。つまり、メール処理方式を採用する利用者は、1 メールボックスを付与されると、1 メールアドレスを付与されることとなる。
処理要求電文と処理結果電文における、SMTP ヘッダー内のメールアドレスの例を図 4-3-17 に示す。
「①処理要求電文」の From 行と「②処理結果電文」の To 行にはそれぞれ、利用者側のメールアドレスが入る。
「①処理要求電文」の To 行と「②処理結果電文」の From 行にはそれぞれ、
NACCS センターサーバ側のメールアドレスが入る。
メールアドレス①From：AAAAA001@MAIL.PROD.NACCS6
To ：NACCS@MAIL.PROD.NACCS6
SMTPヘッダー

メイン処理部

NACCS EDI電文NACCS@MAIL.
PROD.NACCS6

メール処理方式
利用者（NACCS EDI電文）

SMTPヘッダー

NACCS EDI電文

メールボックスID:AAAAA001
メールボックスパスワード：********

メールアドレス：
MAIL.PROD.NACCS6

AAAAA001@MAIL.
PROD.NACCS6

・
・

メールアドレス
From：NACCS@MAIL.PROD.NACCS6②To ：AAAAA001@MAIL.PROD.NACCS6
メールサーバ

メールアドレス①From：BBBBB001@EDIFACT.PROD.NACCS6
To ：NACCS@EDIFACT.PROD.NACCS6
SMTPヘッダー

メールアドレス：
EDIFACT.PROD.NACCS6EDIFACT電文
NACCS@EDIFACT.
PROD.NACCS6

メール処理方式
利用者（EDIFACT電文）

SMTPヘッダー

EDIFACT電文

メールボックスID:BBBBB001
メールボックスパスワード：********BBBBB001@EDIFACT.
PROD.NACCS6

・
・

メールアドレス
From：NACCS@EDIFACT.PROD.NACCS6②To ：BBBBB001@EDIFACT.PROD.NACCS6

NACCSセンターサーバ

利用者システム

図 4-3-17

SMTP ヘッダー内のメールアドレス

4-3-53

(2) メール処理方式における利用者側メールアドレス
メール処理方式における、利用者側のメールアドレスの形式を図 4-3-18 に示す。
なお、メールアカウントの形式は、メールボックス ID も同様になる。

○○○○○○○○@(NACCS センターサーバのサーバ名)
メールアカウント（8 桁）（NACCS センターが付与）

図 4-3-18

ドメイン名（図 4-3-20 を参照）

メール処理方式における利用者側メールアドレス形式（半角大文字）(3) メール処理方式における NACCS センターサーバ側メールアドレス
メール処理方式における、センターサーバ側メールアドレスの形式を図 4-3-19 に示す。

NACCS @(NACCS センターサーバのサーバ名)

図 4-3-19

メールアカウント
ドメイン名（固定）（図 4-3-20 を参照）
メール処理方式におけるセンターサーバ側メールアドレス形式（半角大文字）(4) メール処理方式におけるドメイン名
メール処理方式における、ドメイン名の形式を図 4-3-20 に示す。
（NACCS

EDI 電文もしくは XML 電文の場合）

MAIL.PROD.NACCS6
サーバ名（＝“MAIL”）（固定）（EDIFACT 電文の場合）

EDIFACT.PROD.NACCS6
サーバ名
（固定）
（＝“EDIFACT”）

図 4-3-20

メール処理方式におけるドメイン名（半角大文字）

4-3-54

また、メインセンター～バックアップセンター間の切替は、NACCS センターにおいて、DNS サーバの情報を変更することにより行う。このため、利用者はバックアップセンター運用時のNACCS サーバ側メールアドレスを意識する必要はない。
参考までに、メインセンター被災時等にバックアップセンターに切り替わった際の NACCS セ
ンターサーバ側のドメイン名の形式を図 4-3-21 に示す。
（NACCS

EDI 電文もしくは XML 電文の場合）

MAIL.PROD.NACCS6
サーバ名
（固定）
（＝“MAIL”）（EDIFACT 電文の場合）

EDIFACT.PROD.NACCS6
サーバ名
（固定）
（＝“EDIFACT”）

図 4-3-21

バックアップセンター運用時におけるドメイン名（半角大文字）

4-3-55(5) 利用者が電文を送信する際のメールアドレスについて利用者が NACCS センターサーバのメールサーバに向けて処理要求電文を送信する際の SMTP
ヘッダー内の From 行と To 行のメールアドレスは、
From: 利用者側メールアドレス（例：AAAAA001@MAIL.PROD.NACCS6）To:
NACCS センターサーバ側メールアドレス（例：NACCS@MAIL.PROD.NACCS6）
または、
From: 利用者側メールアドレス（例：AAAAA001@EDIFACT.PROD.NACCS6）To:
NACCS センターサーバ側メールアドレス（例：NACCS@EDIFACT.PROD.NACCS6）となる。From 行は、通信プロトコル上必要なため、To 行は、宛先メールサーバを特定するために、それぞれ入力必須である。

(6) 利用者が電文を受信する際のメールアドレスについて利用者が NACCS センターサーバのメールサーバから処理結果電文を受信する際の SMTP ヘッ
ダー内の From 行と To 行のメールアドレスは、
From: NACCS センターサーバ側メールアドレス（例：NACCS@MAIL.PROD.NACCS6）
To:
利用者側メールアドレス（例：AAAAA001@MAIL.PROD.NACCS6）
または、
From: NACCS センターサーバ側メールアドレス（例：NACCS@EDIFACT.PROD.NACCS6）
To:
利用者側メールアドレス（例：AAAAA001@EDIFACT.PROD.NACCS6）となる。それぞれ、NACCS センターサーバ内のメールサーバにて付加される。

(7) メールアドレスの決定について
利用者側メールアドレス及びセンター側メールアドレスについては、NACCS センターが決定、通知するため、それに従うこと。

4-3-56

4.3.5

業務処理シーケンス
メール処理方式における電文処理シーケンスを、図 4-3-22 に示す。

NACCSセンター側
メールサーバ

メール処理方式利用者

メイン処理部①処理要求電文②処理要求電文③業務処理⑥処理結果電文（画面用）電文種別Ｒ④処理結果電文（画面用）電文種別Ｒ⑦処理結果電文（画面用）電文種別Ｃ⑤処理結果電文（画面用）電文種別Ｃ⑩処理結果電文（帳票用）電文種別Ｐ⑧処理結果電文（帳票用）電文種別Ｐ⑪処理結果電文（帳票用）電文種別Ｐ⑨処理結果電文帳票用）電文種別Ｐ

受信用
メール
ボックス

図 4-3-22

電文処理シーケンス① メール処理方式利用者は、センター側メールサーバに SMTP で処理要求電文を送信する。
・ SMTP の送信シーケンスについては、「4.3.1.2 通信プロトコルの詳細」を参照すること。
・ 処理要求電文のフォーマットは業務によって異なるので「業務仕様書」を参照すること。
・ 処理要求電文の形式は、NACCS EDI 形式、MIME 形式、XML 形式がある。
② メールサーバは、電文のチェックを行った後、メイン処理部に処理要求電文を送信する。
・ メールサーバでは、EDIFACT 電文から NACCS EDI 電文への変換も行う。
③ メイン処理部は、電文のチェックを行った後、業務処理を行う。
④⑤メイン処理部は、処理結果電文（画面用）を受信用メールボックスに登録する。
（業務仕様によって、処理結果電文（画面用）が複数発生する場合がある。図 4-3-22 は、電文種
別ＲとＣの処理結果電文（画面用）が発生している場合を示している。）
・ メールサーバでは、NACCS EDI 電文から EDIFACT 電文への変換も行う。

4-3-57

⑥⑦メール処理方式利用者は、POP により、メールサーバの利用者の受信用メールボックスから処理結
果電文（画面用）を受信する。
・ POP の送受信シーケンスについては、「4.3.1.2 通信プロトコルの詳細」を参照すること。
・ 処理結果電文（画面用）のフォーマットは、業務によって異なるので「業務仕様書」を参照すること。
・ 処理結果電文（画面用）の形式は、NACCS EDI 形式、MIME 形式、XML 形式がある。
⑧⑨

メイン処理部は処理結果電文（帳票用）をメールサーバに送信する。
（業務仕様によって、処理結果電文（帳票用）が発生しない場合や複数発生する場合がある。図4-3-22 は、帳票電文が２電文発生している場合を示している。）
・ メールサーバでは、NACCS EDI 電文から EDIFACT 電文への変換も行う。

⑩⑪ メール処理方式利用者は、POP により、メールサーバの利用者の受信用メールボックスから処理
結果電文（帳票用）を受信する。
・ POP の送受信シーケンスについては、「4.3.1.2 通信プロトコルの詳細」を参照すること。
・ 処理結果電文（画面用）のフォーマットは、業務によって異なるので「業務仕様書」を参照すること。
・ 処理結果電文（画面用）の形式は、NACCS EDI 形式、MIME 形式、XML 形式がある。

（注 1）利用者は、POP による取り出し要求をかけることで、その時点で取り出し可能である全ての電文を受信することができる。
（注 2）⑥⑦⑩⑪の利用者への到着順序は、保証されない。
（注 3）EXC 型電文、EXZ 型電文は、第三者の業務処理を契機として発生するが、図 4-3-22 の⑧、⑩（または⑨、⑪）のみのシーケンスとなる。

4-3-58

4.3.6

その他(1) 利用者側の接続制限
メール処理方式（ゲートウェイコンピュータ）は、ゲートウェイコンピュータを利用者シス
テム側に設置し、アクセス回線は専用線接続またはブロードバンド光接続のときに利用可能である。
(2) 利用上の制限事項
メール処理方式（ゲートウェイコンピュータ）利用者は、以下の事項について守らねばならない。
① 受信用メールボックスに対して処理結果電文の取り出し要求を行う際には、直前の取り出し要求によって電文の削除が完了し QUIT コマンドによる完了通知を行った後、次の接続までに必ず NACCS センターの定める一定時間（3 分）以上の間隔をあけなければならない。利
用者が受信用メールボックスに対し処理結果電文の取り出し要求を頻繁に行うと、メールサーバが高負荷状態となる。
② ゲートウェイ接続利用者は、RETR コマンドを発行して電文の取り出しを完了した後には、必ず DELE コマンドを発行し、メールボックス内の取り出し済み電文の削除を要求しなければならない。(注)③ 全ての処理要求電文の送信が完了した時点で、QUIT コマンドを送信しなければならない。
利用者からの全ての電文送信が完了した後、一定時間、ゲートウェイコンピュータから QUIT
コマンドを発行しない場合、センター側メールサーバでコネクションタイムアウトを発行
し、強制的に接続切断を行う。(注)④ NACCS センターサーバにおける受信用メールボックス領域の使用率が一定量を超えた場合、メイン処理部からの受信用メールボックスに送信されてくる電文の受信を停止する。この場合、利用者は、速やかに受信用メールボックスから電文の取り出しを行うこと。
⑤ 同一のメールアドレスによる複数同時接続（NACCS センターの定める一定時間以内の接続も同様）は、禁止する。
⑥ SMTP の通信プロトコルトレーラーとして、電文の最後に“．<CRLF>”（ピリオドのみの行）を付加すること。データ部分の最後に存在する“<CRLF>”と通信プロトコルトレーラーを合わせた“<CRLF>．<CRLF>”を認識することによって電文の終了を判断する。(注)(3) 添付ファイル格納テーブルに格納された添付ファイルの保存期間
業務ごとの添付ファイルの保存期間については、「業務仕様書」を参照のこと。

4-3-59(4) その他注意事項
メール処理方式（ゲートウェイコンピュータ）利用者は、以下の事項について注意する必要がある。
① POP3 の認証交換方式の 1 つである APOP（RFC1321、RFC1939）には対応しない。
② 処理要求電文の送信時、SMTP ヘッダー内の From 行の利用者システム側のドメイン名部分が「～.～.NACCS6」となっていない電文については、メールサーバで破棄する。利用者システ
ムでは、正しい設定で再度電文を送信する必要がある。
③ メール処理方式（ゲートウェイコンピュータ）の場合、複数の処理要求電文を連続して送信することができるが、メールサーバの仕組み上、必ずしも利用者が送信した処理要求電文の順序にしたがってメイン処理部での業務処理が行われるとは限らない。
④ １トランザクション内で複数の処理結果電文が発生した場合、受信用メールボックスへのそれらの到着順序は、保証されない。例を図 4-3-23 に示す。そのため、利用者システムでは処理結果通知電文が先に処理されることを前提とした作りとしてはならない。
⑤ NACCS センターサーバにおける送信用メールボックス領域の使用率が一定量を超えた場合、全利用者からの電文の受信を停止する。この場合、利用者には送信タイムアウトが応答される。利用者は、送信タイムアウトとなった電文を再送する必要があるため、利用者システム
側には、作成した電文を一時保存する機能が必要となる。
⑥ システムの高負荷時には、全利用者からの電文の受信を停止する等の運用制限をかける場
合がある。この場合、NACCS センターから利用者に対し電話、FAX または NACCS 掲示板等により連絡を行う。
⑦ メールサーバへの同時接続利用者数には制限があるため、システムの混雑時には接続できない場合がある。
⑧ 大規模障害及び大規模災害等で、バックアップセンターにて NACCS が運用される場合には、バックアップセンター用のメールサーバに接続すること。
⑨ 接続試験を実施するための環境は、バックアップセンターの一部に構築される。このため、大規模障害及び大規模災害の発生等によりメインセンターに影響があった場合には、バッ
クアップセンターによりシステム運転が実施されるため、接続試験が実施できない。

１トランザクション内で複数の処理結果電文が発生した場合、処理結果通知電文と出力情報電文（帳票用）の受信用メールボック
スへの到着順序は保証されない処理要求電文

送信用
メールボックス

処理結果通知電文

ゲートウェイコンピュータ

受信用
メールボックス

利用者
システム

メイン処理部

出力情報電文（帳票用）

NACCSセンターサーバ

図 4-3-23

複数の処理結果電文の到着順序について（例）4-3-60(5) 各種タイマー値
メール処理方式において規定するタイマー値一覧を表 4-3-22 に示す。また、各タイマーの設定箇所について図 4-3-24 から図 4-3-26 に示す。
表 4-3-22 タイマー値一覧
ＩＤ
監視内容
タイマー値
Ｔ０１
利用者システム送信時の利用者システムと、センター側メ 利用者が規定
ールサーバの SMTP コネクション監視時間
Ｔ０２
利用者システム受信時の利用者システムと、センター側メ 利用者が規定
ールサーバの POP3 コネクション監視時間
Ｔ０３
利用者システムが、センター側メールサーバに SMTP コネ ２分
クションを接続したあとの無通信時間。
Ｔ０４
利用者システムが、センター側メールサーバに POP3 コネ ２分
クションを接続したあとの無通信時間
Ｔ０５
NACCS センターサーバ内で何らかの異常が発生し、センタ ３分以上
ービジーである旨の処理結果通知電文が返却されてきた場合の再送可能間隔。
（注）タイマー値は、現行システムの設定値である。
（注）本表の ID 欄に示す T01～T05 は、図 4-3-24～図 4-3-26 に示す各タイマーの ID を示す。

4-3-61

利用者
システム

NACCSセンター側
メールサーバ
コネクション接続要求
HELO
MAIL
RCPT

Ｔ０３

Ｔ０１
DATA
電文送信
<CRLF>.<CRLF>
QUIT

図 4-3-24

SMTP コネクションのタイマー設定

利用者
システム

NACCSセンター側
メールサーバ
コネクション接続要求
USER
PASS
STAT/LIST

Ｔ０２
RETR
DELE
QUIT

図 4-3-25

POP3 コネクションのタイマー設定

4-3-62

Ｔ０４

利用者
システム

NACCSセンター側
メールサーバ
処理要求電文
処理結果電文（センタービジー）

Ｔ０５
処理要求電文
処理結果電文（正常）

図 4-3-26

センタービジーの場合のタイマー設定

4-3-63