ホームサイトマップはじめてご利用になる方へshareEDGEメンバー登録ログイン
 
キーワード検索
shareEDGE製品購入の流れ 製品購入の流れ 支払処理へ
 メンバーシップ
アンチスパイウェア宣言

メールヘッダーについて

はじめに

このドキュメントは、Ken Lucke氏によりWebサイトに公開された文章を元にしています。原文では、もっと詳しい説明が紹介されていますがここでは省略しています。http://www.stopspam.org/email/headers.html

内容は非常に興味あるもので、またスパムメールと戦う人たちへの技術取得にとっても有意義であると思われるので、翻訳し掲載することにしました。

ここでは、架空のドメイン名とそのIPアドレスを例に使用しています。またここに記述しているすべてのIPアドレスも架空のものであり、将来あるドメインに割り当てられる可能性があります。

どこからメールは来るのか?

ここでは、メールの生涯について簡単に分析して見ましょう。この背景となる事柄はメールヘッダーに何が記述されているかを理解するために重要な事柄です。

表面的には、メールは送信者のマシンから直接受信者のマシンに渡されているように見えます。通常、これは事実ではありません。通常のメールは、その生涯の中で最低4つのコンピュータを経由します。

 

なぜなら、多くの組織ではメール サーバと呼ばれるメールを扱うための専用のマシンが準備されています。これは通常、ユーザがメールを読んだりするマシンと違うものです。もっとも通常は、家庭かコンピュータからインターネットに接続している場合、クラアントと呼ばれる家庭で利用しているマシン、サーバと呼ばれるISPのサーバがあります。ユーザがメールを送信する場合、その人は自身のコンピュータ上でメッセージを作成し、ISPのメール サーバにそれを送信します。この時点で、その人のコンピュータは、役割を完了しますが、メール サーバはそのメッセージを送信する必要があります。それは受信者のメール サーバを見つけ、接続し、メッセージを配信することで行われます。その後、この2番目のメールサーバ上に、受信者がそのメールを見つけ、それを自身のコンピュータに読み込み、通常メール サーバから削除処理が行われるまで保存されます。

架空の2人のユーザ, <rth@bieberdorf.edu><tmh@immense-isp.com>とについて考えて見ましょう。 tmh は、Immense ISP, Inc.のダイヤルアップ ユーザで、メール プログラム Loris Mail (架空の名前です)を利用しています。rth は、Bieberdorf 研究室の教授で研究室の他のコンピュータに接続された、彼の机のワークステーションを利用しています。

もし rthtmhに手紙を送る場合、彼は彼のワークステーションでメールを作成します。作成したメールは、そこからメール サーバ mail.bieberdorf.edu に送信されます (これがrth が見ることができる最後の処理ですそれ以降の処理が彼と関係のないマシンにより処理されます。)。メール サーバは、immense-isp.comの誰かからメッセージを受信したことを知り、メール サーバ mailhost.immense-isp.com に接続し、メールを配信します。これでメッセージは、mailhost.immense-isp.comに配信され、 tmh が彼のコンピュータからダイヤルインしてメールをチェックするまで保存されます。その時、メールサーバは、rthからのメールを含むすべての待機中のメールを配信します。

 

すべてのプロセスにおいて、メッセージにヘッダが3回追加されます。どんなメール プログラムを利用していようとメール作成時、プログラムがその制御をmail.bieberdorf.eduに引渡した時、Bieberdorfから Immenseに転送された時です。 (通常メッセージを読み込むダイヤルアップ ノードは、ヘッダへの追加は行いません。) これらのヘッダを見てみましょう。

rthのメーラにより作成され、mail.bieberdorf.eduに送信された時:

From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
X-Mailer: Loris v2.32
Subject: Lunch today?

mail.bieberdorf.eduがメッセージをmailhost.immense-isp.comに送信した時:

Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

mailhost.immense-isp.com がメッセージの処理を完了し、tmh が読み込むために保存した時:

Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

これがtmh が彼のメールをダウンロードし、読み込んだ時に見る最後のヘッダ部分です。次に各行ごとにその意味を説明します。

Received: from mail.bieberdorf.edu

このメールがマシンitself mail.bieberdorf.eduか受信したものであることを意味します...

(mail.bieberdorf.edu [124.211.3.78])

..本当の名前がmail.bieberdorf.edu (例 これは自分自身を正しく識別します---see Section Whatever for more on this) IPアドレスは、124.211.3.78です。

by mailhost.immense-isp.com (8.8.5/8.7.2)

受信したマシンは、mailhost.immense-isp.comであることを意味します。メールプログラムsendmail, version 8.8.5/8.7.2 が実行されています。(バージョン番号は気にする必要はありません。)

with ESMTP id LAA20869

受信マシンがメッセージにID番号LAA20869を割り当てました。(これは、マシンにより内部で利用されます。---これは、マシンログを ファイルのメッセージを検索する場合に必要となる場合があります。しかし、多くの場合、誰にも役に立ちません。)

for <tmh@immense-isp.com>;

メッセージが tmh@immense-isp.com宛てであることを意味します。このヘッダ情報は、To:行とは関係ありません。

Tue, 18 Mar 1997 14:39:24 -0800 (PST)

このメール送信がTuesday, March 18, 1997, at 14:39:24 Pacific Standard Time (グリニッジから8時間遅れ"-0800")に処理されたことを意味します。

Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)

これは、メールが alpha.bieberdorf.edu (rthのワークステーション) から mail.bieberdorf.eduに渡され、この受け渡しが14:36:17 Pacific Standard Timeに処理されたことを意味しています。送信マシンは、自分自身を alpha.bieberdorf.eduとして識別し、実際の名前がalpha.bieberdorf.edu、IPアドレスは、124.211.3.11です。Bieberdorfのメールサーバでは、sendmail バージョン8.8.5が実行されていて、このメッセージへのID番号に004A21を内部処理用に割り当てられたことを意味します。

From: rth@bieberdorf.edu (R.T. Hood)

メールがrth@bieberdorf.eduにより送信され、彼の実の名前がR.T. Hoodであることを意味します。

To: tmh@immense-isp.com

メールが tmh@immense-isp.com宛てであることを意味します。

Date: Tue, Mar 18 1997 14:36:14 PST

メールが14:36:14 Pacific Standard Time on Tuesday, March 18, 1997に作成されたことを意味します。

Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>

このメッセージは、識別のために、この番号が割り当てられ(mail.bieberdorf.eduにより) ました。このID は、Received: ヘッダーのSMTPや ESMTP ID 番号とは違ったものです。なぜならこれは生涯このメッセージに添付されます。他の IDは、特定のマシンで単に、特定のメール トランザクションに関連したものです。そのため、あるマシンでのID番号は、他のマシンにとっては無意味なものです。時には、(この例のように) Message-IDが、送信者のメール アドレスを含んでいる場合があります。しかし、多くの場合、あまり意味はありません。

X-Mailer: Loris v2.32

メールがプログラムLoris, version 2.32を使って作成されたことを意味します。

Subject: Lunch today?

件名。

エンベロープ ヘッダー

簡単言うと、"エンベロープ" ヘッダーは、送信者ではなく、メッセージを受信するマシンによって実際に生成されます。この定義により、 Received: はエンベロープ ヘッダーです。しかしながら用語は、"envelope From" や"envelope To" として参照されます。

エンベロープ From ヘッダは、MAIL FROM コマンドの情報より派生されるヘッダです。簡単に言うと、送信マシンがMAIL FROM: ginger@turmeric.com とSMTPプロトコルで通信した場合、受信マシンは、ヘッダからエンベロープ Fromヘッダを次のように生成します。

From ginger@turmeric.com

コロンの省略について---"From", From:"ではなく。多くの場合、エンベロープ ヘッダには、コロンが含まれません。この略式はすべてに共通ではありません。しかし、これは一般に知っておく必要があります。

対照的に、エンベロープTo は、RCPT TO コマンドから派生して生成されます。送信マシンがSMTPプロトコルでRCPT TO: tmh@bieberdorf.edu として通信した場合、エンベロープ To は tmh@bieberdorf.eduになります。時々、実際のヘッダには、この情報が含まれていません。これは時にはReceived: ヘッダに含まれます。

エンベロープ情報の存在の重要な結果に、メッセージ From: と To: ヘッダーには意味がないということです。そして直感に反して From: ヘッダーの内容, To: ヘッダーの内容は送信者により提供されます。メールは、唯一エンベロープ Toを基準に配信され、メッセージ To: ヘッダーは一切利用されません。

次のようなSMTPトランザクションを見て、このことを考えて見ましょう。

HELO galangal.org
250 mail.bieberdorf.edu Hello turmeric.com [104.128.23.115], pleased to meet you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org... Sender ok
RCPT TO: tmh@bieberdorf.edu
250 tmh@bieberdorf.edu... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
.
250 OAA08757 Message accepted for delivery

以下は、これに対応するヘッダー (明確にするために抜粋します)です。

From forged-address@galangal.org
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5) for <tmh@bieberdorf.edu>...
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)

エンベロープ Fromの内容、メッセージ From:、およびメッセージTo:はすべて送信者により書かれたもので、現実的とは思えないものです。この例では、なぜ、From、From:、およびTo: ヘッダーが捏造されたメール内で信用のできないものかを説明しています。これらは簡単に欺くことが可能なものです。

Received: ヘッダーの重要性

上の例で見てきたように、Received: ヘッダーは、メッセージの履歴に関する詳細な記録を提供していて、恐らく他のヘッダー部分が偽りであったとしてもメールの送信元について情報を捕らえることができます。このセクションでは、これら重要なヘッダーに関連する詳細と、特に一般的な偽造のテクニックをどう回避するかについて解説します。

疑うこともなく、最も価値ある Recevied: ヘッダー内の偽造保護は、受信ホストにより記録される送信者の情報です。送信者は、それを識別するものを偽ることができます (レシーバにHELO コマンドにうその情報で送信することで)。幸運にも、新しいメール送信プログラムでは、これらの情報の間違いを検出し、訂正することができます。

例えば、マシン turmeric.com、IPアドレスが104.128.23.115、がメッセージをmail.bieberdorf.eduに送信したとします。しかし、偽ってHELO galangal.org と送信したとします。結果、Received: 行は、以下のようになります。

Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...

(明確にするために、他の行は省略しています。) マシンbieberdorf.edu は、galangal.orgが実際に送信マシンでないことを明らかにはしていませんが、送信者の正しいIPアドレスを記録しています。もし、誰かメールの受信者が、ヘッダー内に現れるgalangal.orgが捏造者によるものであると調べることがあるとすると、IPアドレス 104.128.23.115 (UNIX プログラムの nslookupを使って...) を利用し、そのアドレスが実際には、 turmeric.com ( galangal.orgではなく)に属しているということを見つけることができます。送信マシンのIPアドレスの記録は、捏造の疑いがあることを確認するには十分な情報でもあります。

最近のメール プラグラムでは実際この処理を自動的に行います。送信マシンの名前を照会します。 (照会プロセスは、reverse DNS (Domain Name Serviceにとって)と呼ばれます。---"reverse"(逆引き) とは、つまり、通常名前をアドレスに変換するための処理であるからです。) もし、mail.bieberdorf.edu がこれを行ったこのソフトウェアを使用していて、Received: 行は以下のようになります。

Received: from galangal.org (turmeric.com [104.128.23.115]) by mail.bieberdorf.edu...

ここでは、捏造が明らかです。この行は、"turmeric.com, アドレス 104.128.23.115が名前をgalangal.orgと偽っている"ことを意味しています。説明の必要もなく、このような情報は、捏造されたメールを識別するためにとても役立つ情報をいえます。(このため、スパマーはReverse DNS情報を通知するリレイ マシンを利用することを回避しようとしています。時に、彼らがこのようなIPを記録する機能を有していないマシンを見つけたとしても---それらがもはやネット上に多く存在していないと思われます。)

メール捏造の他のトリックとして、これは一般的に増加して来たものは、メールを送信する前に、偽りのReceived: ヘッダーを追加することです。これにより、turmeric.com から送信された'命題'メールの Received: 行は以下のようになります。

Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from nowhere by fictitious-site (8.8.3/8.7.2)...
Received: No Information Here, Go Away!

明らかに最後の2行は、意味がなく、送信者によりかかれ、送信前に、メッセージに追加されたものです。

送信者には、 turmeric.comから発信されたメールを制御することはできないため、Received: ヘッダーが常に上位部に追加されるため、捏造された行はリストの下部に現れます。これは、誰か行を上から下に読む場合、メッセージ履歴を読む場合、捏造された行以降を安全に無視することができることを意味しています。(たとえその Received: 行以降がもっともらしいとしても、捏造であることは間違いありません。)

もちろん送信者は、明らかに捏造されたデータを使うことはなく、以下のようなもっともらしいReceived:行を使います。

Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)...
Received: from graprao.com by lemongrass.org (8.6.4)...

ここでは、唯一の捏造の暴露は、一番最初のRecevied:行のgalangal.org のためのIPアドレスの部分です。捏造者が lemongrass.org とgraprao.comのための正しいIPアドレスを使用していた場合、捏造を見破ることはとても難しくなります。しかし、最初の行のIPの不一致によりこのメッセージが捏造され、サイト 104.128.23.115(例 turmeric.com)に混入されたことが分かります。しかしながら、殆どのヘッダー捏造は洗練されていなくて、付加されたReceived:行は明らかにゴミである場合が多くあります。

一般的なヘッダーのリスト

  • Apparently-To: 多くの受信者を持つメッセージは、時にはフォーム "Apparently-To: rth@bieberdorf.edu" (受信者毎に1行)のヘッダー部のリストが長くなります。これらのヘッダーは、正統なメールで見られるものではありません。これらは、通常メーリング リストの記号で、近年、メーリングリストは、一般的にはソフトウェアでは十分に洗練されていて大きなヘッダーを生成することはありません。
  • Bcc: ("Blind Carbon Copy"の略です。) 受信メールにこのヘッダーがある場合、何か変です。これは Cc: (以下を参照)のように使われます。しかし、ヘッダーには現れません。目的は、メールのコピーを返信を受けたくない受信者、またはヘッダーに表示されたくない受信者に送信するためのものです。見えないカーボンコピー(BCC)は、スパマーでは、ポピュラーです。多くの未経験のユーザが、発信元の分からないメールを受信して当惑されることができるからです。
  • Cc: ("Carbon Copy"の略で、ライプライタを知っている人なら容易に想像することができます) このヘッダーは、ある種"To:"の拡張です。これは追加の受信者を指定します。"To:" と"Cc:" の違いは、含蓄的要素があります。いくつかのメーラでは、お返信文を生成する場合に違った方法をとります。
  • Comments: これは標準ではない、自由形式のヘッダーフィールドです。これは最も一般的に"Comments: Authenticated sender is <rth@bieberdorf.edu>"として見る事ができます。このようなヘッダーは、いくつかのメーラ (ポピュラなフリーウェア プログラム Pegasus) で送信者を識別するために利用されます。しかし、しばしばスパマによって手動で追加され (虚偽の情報で) ます。慎重に扱ってください。
  • Content-Transfer-Encoding: このヘッダーは、MIMEに関係があります。非テキスト コンテンツをメールに含める標準的な方法です。これはメールの配信にとって直接関与しません。しかし、どのようにMIME互換のメール プログラムがメッセージの内容を解読するかについて関係します。
  • Content-Type: もう一つの MIME ヘッダーで、MIME互換のメール プログラムにどんな種類のコンテンツがメッセージに含まれているかを知らせます。
  • Date: このヘッダーは、まさに期待しているものです。これは日付を表していて、通常メッセージが作成されて送信された日付です。もしこのヘッダーが送信者のコンピュータで省略された場合、 恐らくメール サーバによって、または他の経路にあるマシンによって付加されます。これを絶対的に正しいものとして扱うべきではありません。捏造も可能です。また世界中には時刻の間違ったコンピュータが多く存在しています。
  • Errors-To: "ユーザが見つからない"などの拒否メッセージのような、メーラにより生成されたエラーの送信先アドレス (送信者のアドレスではなく)。 こではそれほど一般的なヘッダーではありません。送信者は通常送信したアドレスでエラーのメッセージを受信したいと考えるからであり、また多くの(すべての)メール サーバ ソフトウェアがデフォルトでそのような設定をしています。
  • From (コロンなし) こでは、先に説明した"エンベロープ From" です。
  • From: (コロン付き) こでは先に説明した"メッセージ From:" です。
  • Message-Id: (Message-id: または Message-ID:) Message-Id は、各メッセージに割り当てられた多少ユニークな識別子で、通常に最初に出会ったメールサーバによるものです。習慣上、これはフォーム"gibberish@bieberdorf.edu"では、"gibberish" 部分は絶対で、二番目の部分は、IDを割り当てられたマシンの名前になります。時には、多くありませんが、"gibberish" は送信者のユーザ名を含みます。メッセージ IDが奇形であるあらゆるメール(例えば 空文字や@ 記号のないもの)、またはメッセージ IDのサイトが実の発信元ではないメールは、恐らく捏造されたものといえます。
  • In-Reply-To: 時折メールに見られるUsenetヘッダーです。In-Reply-To: ヘッダーは、以前すでに返信したいくつかのメッセージのメッセージIDを提供します。直接Usenetに関連したメールを除いて、このヘッダーが現れるのは珍しいことです。スパマーはこれを利用することで知られています。 恐らくフィルタリング プログラムから回避するためだと思われます。
  • Mime-Version: (またはMIME-Version:) さらに他のMIMEヘッダーです。これは送信者によって使用されたMIMEプロトコルのバージョンを表しています。他のMIMEヘッダーのように、これは通常、無視することが可能です。 殆ど多くのメール プログラムはこれを正しく行います。
  • Newsgroups: このヘッダーは、Usenetに接続されたメールにのみ現れます。---メールが Usenet投稿のコピーであったり、投稿への返答の場合です。最初のケースでは、これはメッセージの投稿されたnewsgroupを表し、次のケースでは、返答メッセージの投稿されたnewsgroupです。
  • Organization: 完全にフリーフォームのヘッダーで、通常、ネットへのアクセスを持つメッセージの送信者の組織の名前を含んでいます。送信者は、このヘッダーを制御することができます。また、幼稚なエントリ"Royal Society for Putting Things on Top of Other Things"は、日常茶飯事です。
  • Priority: 本質的には、フリーフォーム ヘッダーで、メールの優先度を表します。多くのソフトウェアはこれを無視します。これは時にはスパマーに利用され、通常、"優先度:緊急"(または同様に)として、メッセージが読まれるように工夫します。
  • Received: 詳細は上記
  • References: References: ヘッダーは、Usenet投稿以外では、ごくまれにメールで見られます。Usenetでは、どのメッセージへの投稿を表す"上位"の投稿です。これは通常、単にUsenetヘッダーのコピーです。 これはまた、Usenet投稿への応答メールにも現れます。返答する投稿のメッセージIDと投稿からのリファレンスです。
  • Reply-To: 返信の送られる先を表しています。このヘッダーには多くの正統な用途があります (恐らくご使用のソフトウェアは、From: アドレスを使わないで、正しいアドレスに応答することになります。)、これはまた、スパマーにより批判をさせるために利用されます。時折、ネイティブなスパマーは、このReply-To: ヘッダーを使って返事を要求します。しかし、時にReply-To: ヘッダーはジャンク メールのアドレスまたは、無実の被害者のものです。
  • Sender: このヘッダーは、メールでは、普通ではありません (代わりに X-Sender: が通常使われます)、しかし特にUsenet投稿などで時折見られます。Usenet投稿の場合、これは送信者を識別し、From:行よりもより信憑性があります。
  • Subject: 送信者によって指定される完全なフリーフォーム フィールドで、メッセージの件名を意図的に表しています。
  • To: "message To: " 上記に解説しています。To: ヘッダーには、受信者のアドレスを記述する必要がないことに注意しておいてください。
  • X-headers は、大文字のXとハイフンで始まる一般的なヘッダー用語です。便宜的にX-headersは標準ではなく、情報のみを提供します。 逆にすべての標準でないヘッダーは、"X-"で始まる名前を利用します。このルールはしばしば守られていません。
  • X-Confirm-Reading-To: このヘッダーは、メッセージが受信または読まれたら自動的に確認通知を要求しています。これは通常無視されます。いくつかのソフトウェアは対応しています。
  • X-Distribution: スパマーが彼のソフトウェアを使っての問題に対する応答、Pegasus Mailの作成者がこのヘッダーを追加しました。Pegasusで送信された、大量の数の受信者を持つすべてのメッセージには、ヘッダー"X-Distribution: bulk"が追加されます。 これは明らかに受信者がそれらに対してフィルタとして利用するためのものです。
  • X-Errors-To: Errors-To:のように、このヘッダーは、エラーの送信先アドレスを表しています。これは恐らくそれほど使われていません。
  • X-Mailer: (または X-mailer:) 送信者により利用されたメール ソフトウェアを識別するためのフリーフォームのヘッダー フィールドです (広告や何かの目的)。多くのジャンクメールがその目的のために作成されたメーラによって送信されているため、このフィールドは、フィルタとして利用するには、とても有効です。
  • X-PMFLAGS: このヘッダーは、Pegasus Maiにより追加されました。その意味は明らかではありません。これはPegasusによって送信されたすべてのメッセージに追加されます。そのため受信者には、 X-Mailer:によりカバーされるもの以上の情報を提供しません。
  • X-Priority: もう一つの優先フィールドで、優先度を割り当てるためにEudoraにより著しく利用されます (メッセージ上にグラフィカルな記法として表れます)。
  • X-Sender: ニュースのヘッダー、 このヘッダーは、表面上From:ヘッダーよりも信頼性のある送信者の識別子を表しています。実際、捏造するのは同じく簡単で、そのためFrom: ヘッダーと同じように疑いをもって理解されます。
  • X-UIDL: これは、ユニークな識別子でPOPプロトコルによりサーバからメールを読み込む場合に利用されます。これは通常、受信者のメール サーバと受信者の実際のメール ソフトウェア間で追加されます。メールがメール サーバにX-UIDL: ヘッダー付きで到着すると、これはジャンク(スパム)です (このようなヘッダーを想像することはできません。しかし、いくつかの不明な理由により、多くのスパマーが追加しています)。
 

Copyright c 1997-2003 by Ken Lucke - all rights reserved
© 2005 nextEDGE Technology K.K Translation - all rights reserved.

シェアエッジ プロジェクト (c) 2004, 2017株式会社ネクステッジテクノロジーAll rights reserved.