電子メールデータを生成する生成手段と、前記生成手段が生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信手段と、前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、を備えることを特徴とする送信装置。前記送信手段は、前記生成手段が生成した電子メールデータをメールサーバを経由させずに前記受信装置に送信する場合に、前記情報を送信することを特徴とする請求項1に記載の送信装置。前記送信手段は、前記生成手段が生成した電子メールデータを送信するために用いる通信プロトコルのコマンドの1つとして、前記情報を送信することを特徴とする請求項1または2に記載の送信装置。前記通信プロトコルとは、SMTPプロトコルであることを特徴とする請求項3に記載の送信装置。電子メールデータを受信装置に送信する送信装置であって、前記電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報を含む、前記電子メールデータを生成する生成手段と、前記生成手段が生成した電子メールデータを前記受信装置に送信する送信手段と、前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、を備えることを特徴とする送信装置。前記情報は、前記電子メールデータのヘッダフィールドに含まれることを特徴とする請求項5に記載の送信装置。電子メールデータを生成する生成工程と、前記生成工程で生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信工程と、前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信工程と、を備えることを特徴とする送信装置の制御方法。電子メールデータを受信装置に送信する送信装置の制御方法であって、前記電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報を含む、前記電子メールデータを生成する生成工程と、前記生成工程で生成した電子メールデータを前記受信装置に送信する送信工程と、前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信工程と、を備えることを特徴とする送信装置の制御方法。請求項7または8に記載の送信装置の制御方法をコンピュータに実行させるためのプログラム。FullMode規格に従いメールサーバを経由せずに送信機から受信機に画像データが送信する構成の場合において、特許文献1、特許文献2に開示される構成によれば、送信機から受信機に画像データを直接送信することは可能である。しかしながら、受信機がMDNの結果を送信機に送信する場合は、MDNを送信する宛先が直接送信できる宛先であるか、直接は送信できない宛先であるか判断することができない。このために、MDNは常にメールサーバを返して通信が行われることになり、メールサーバは必要不可欠な存在となっていた。しかしながら、メールサーバの設置、運用は容易ではない。ここで、メールサーバを経由することなく通信ができる環境でのみ運用される場合とは、メールサーバを構築することなく画像データを電子メールプロトコルに従って通信を行う場合がある。また、メールサーバが存在しても、大きな画像ファイルが送信されるIFAXでは、メールサーバの負荷が問題になることから、メールサーバをあえて使わないようにメールサーバの設定を行う場合が増えている。受信機が電子メールデータの受信に成功しても、受信後に電子メールデータを解析して、その中から画像を抽出するようなシステムでは、必ずしもデータの受信の成功が、受信機でのそのデータによる画像形成の成功とは限らない。例えば、受信機に内蔵されるデータ記憶用の記憶装置が、処理途中で一杯になる等の障害が発生した場合は、受信機での画像形成は失敗に終わってしまう。従って、最終的に通信が成功したかを確認するためには、MDNでの確認が必要になる。このようなメールサーバが設置されない、あるいは設定されない環境では、MDNの通信が行われず、送信した電子メールデータが受信機に正常に届いたのか判断できないという問題が発生している。本発明は上記の問題点に鑑みてなされたものである。その目的は、装置間の環境に応じて、電子メールの送達確認の送受信経路を適応的に選択して、送達確認を確実に送信することができる受信装置及びその制御方法、プログラムを提供することにある。上記の目的を達成するための本発明による受信装置は以下の構成を備える。即ち、電子メールデータを生成する生成手段と、前記生成手段が生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信手段と、前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、を備える。本発明によれば、装置間の環境に応じて、電子メールの送達確認の送受信経路を適応的に選択して、送達確認を確実に送信することができる受信装置及びその制御方法、プログラムを提供できる。以下、本発明の実施の形態について図面を用いて詳細に説明する。<実施形態1>図1は本発明の実施形態1の通信装置のネットワーク接続構成を示すブロック図である。100、101は、MFPMultiFunctionPeripheralである。MFP100や101は、スキャナ、プリンタ等のデバイスを搭載することで、スキャナ機能、コピー機能、FAX送受信機能、コンピュータ上で作成されたデータを印刷するプリンタ機能等の複数の機能を備えたマルチファンクション複写機である。MFP100、MFP101は、例えば、ドメイン名xyz.co.jpというネットワークに接続され、サーバ103やクライアントPC104等の複数のコンピュータ、ネットワーク機器と接続されている。このネットワークは、さらには全世界に広がるインターネット網110と接続されている。MFP100は、copy1.xyz.co.jpというHOST名とifaxcopy1.xyz.co.jpという機器の電子メールメールアドレスが付与されている。MFP101は、copy2.xyz.co.jpというHOST名とifaxcopy2.xyz.co.jpという機器の電子メールアドレスが付与されている。PC104には、汎用電子メールソフトがインストールされており、yamadaxyz.co.jpというメールアドレスが付与されている。サーバ103は、MailサーバSMTPサーバ機能とPOPサーバ機能の双方の機能を備えるサーバであり、pulser.xyx.co.jpというHOST名が付与されている。また、DNSサーバ機能を備えている。尚、Mailサーバ機能を備えるサーバ、POPサーバ機能を備えるサーバ、DNSサーバ機能を備えるサーバをそれぞれ別の端末としてもよいし、適宜統合した端末としてもよい。また、DNSサーバ機能を備えるサーバを、このようにMFP100とは独立した端末として一括管理することにより、ドメイン名とIPアドレスとを相互変換する端末を種々のMFPで共用することができる。また、ドメイン名やIPアドレスの変更があった場合、このサーバのみの変更で済む。もちろん、このDNSサーバ機能をMFP100に内蔵させるようにしてもよい。この場合は、ネットワークを介した通信を行わないので処理効率の向上が期待できる。MFP100、MFP101には、2種類の送信モードが構成されている。1つは、FAX/IFAX受信機能にて受信した画像、及びスキャナで読み取った白黒/カラー画像を、一般の電子メール宛先に送信することを前提として送信するEmail送信モードである。もう1つは、IFAX規格に従った装置に送信することを前提として送信するIFAX送信モードが存在する。尚、データの送信/受信には、例えば、SMTP、POP3プロトコルが使われる。Email送信モードでは、スキャナでカラー画像が読み取られる場合は、JPEGフォーマットあるいはPDFPortableDocumentFormat形式のファイルの画像を電子メールに添付して送信することができる。一方、スキャナで白黒画像が読み込まれた場合は、TIFFあるいはPDFの形式の画像を送信することができる。例えば、yamadaxyz.co.jpのメールアドレスを有するクライアント104に電子メールを送信する場合、サーバ103にSMTPプロトコルで画像データが添付された電子メールが送信される。そして、クライアントPC104は、POP3プロトコルにてその電子メールを受信し、汎用画像ビューアで添付されている画像を表示することができる。IFAX送信モードでは、MFPのスキャナ機能で読み取られた画像あるいは、FAX/IFAX受信機能で受信された画像データは、RFC2301に従ったTIFF形式の画像として送信される。そして、受信された画像データは受信側のMFPのプリンタ機能で印刷される。次に、MFP100の構成について、図2を用いて説明する。尚、以下の説明では、MFP100の構成を例に挙げて説明するが、MFP101についても、MFP100と同様の構成が実現される。図2は本発明の実施形態1のMFPの構成を示す図である。CPU130は、ROM131に格納されているプログラムと、RAM132を利用してシステム全体の制御を実行する。操作部133は、LCD表示パネルとスタートキー、テンキー等のハードキーから構成され、LCD上にソフトボタンを表示し、ユーザが指でそのソフトボタンをタッチすることを検出してユーザオペレーションを実行する。スキャナ134は、原稿の画像データを光電変換により電気データに変換する。スキャナ134では、原稿給送装置不図示から原稿をプラテンガラス上へ搬送し、原稿がプラテンガラス上に搬送されると、ランプを点灯し、そして、原稿読取ユニットの移動を開始し、原稿を露光走査する。原稿からの反射光は、ミラー及びレンズによってCCDイメージセンサへ導かれて電気信号に変換され、A/D変換回路によってデジタルデータに変換される。原稿の読取動作終了後、プラテンガラス上の原稿は排紙される。プリンタ135は、電気的画像データを記録紙に印刷する。電気的画像データに応じたレーザ光をレーザ発光部から発光させ、このレーザ光は感光ドラムに照射され、感光ドラム上にはレーザ光に応じた潜像が形成される。感光ドラムの潜像の部分には現像器によって現像剤が付着され、レーザ光の照射開始と同期したタイミングで、給紙カセットから記録紙を給紙して転写部へ搬送し、感光ドラムに付着された現像剤を記録紙に転写する。現像剤が転写された記録紙は定着部に搬送され、定着部の熱と圧力により現像剤は記像紙に定着される。定着部を通過した記録紙は排出ローラによって排出され、ソータは排出された記録紙をそれぞれのビンに収納して記録紙の仕分けを行う。画像処理回路136は、大容量の画像メモリ、画像回転回路、解像度変倍回路、MH、MR、MMR、JBIG、JPEG等の符号/復号化回路等の各種回路で構成され、シェーディング、トリミング、マスキング等の各種画像処理を実行することができる。ハードディスク137は、SCSI、IDE等のI/Fで接続されている大容量記録媒体である。ネットワークI/F138は、10BASE-T、100BASE-Tを代表とするイーサネット登録商標あるいはトークンリング等のネットワーク回線と接続するためのネットワークデータリンクを実現する。フォーマッタ部139は、IEEE1284準拠のパラレルインタフェース、USB等のシリアルインタフェースからなるPCI/F142またはネットワークI/F回路138を介して、外部機器例えば、クライアントPC104からデータを受信する。そして、フォーマッタ部139は、受信したデータ例えば、PDLPageDescriptionLanguageより画像データを作成し、画像処理回路136で画像処理を行い、プリンタ135で印刷するためのレンダリングを実行する。ファクス部140は、電話回線と接続し、NCUNetworkControlUnit、MODEMMOdulator/DEModulator等の回路で構成されるファクスI/F回路である。ファクス部140は、スキャナ134で読み取った画像データを画像処理回路136で画像処理を行い、電話回線経由にて他のFAX装置に送信する。一方、ファクス部140は、他のFAX装置から送信されたデータを受信して、画像処理回路136で画像処理を行ってプリンタ135で印刷する。スキャナ134、プリンタ135、画像処理回路136、フォーマッタ部139、ファクス部140は、CPU130からのCPUバス141とは別の高速ビデオバスで接続され、画像データを高速に転送できるように構成されている。スキャナ134で読み取った画像データを画像処理回路136で画像処理を行い、その画像処理後の画像データをプリンタ135で印刷するように動作することで、コピー機能が実現される。また、スキャナ134で読み取った画像データを画像処理回路136で画像処理を行い、ネットワークI/F138からネットワーク上に送信することで、Sendデータ転送/ファイル転送機能が実現される。更には、画像処理回路136でRFC2301に従った画像を作成し、電子メールプロトコルでデータを送受信することで、IFAX機能が実現される。次に、MFP100が所有するネットワークプログラムの構成について、図3を用いて説明する。図3は本発明の実施形態1のMFPが所有するネットワークプログラムの構成を説明する図である。ネットワークプログラムの構成は、IP層200、TCP/UDP層201、アプリケーション層202の3階層に大別して構成されている。ここで、IPはInternetProtocol、TCPはTransmissionControlProtocol、UDPはUserDatagramProtocolの略称である。IP層200は、発信ホストから宛先ホストヘルータ等の中継ノードと連携しながらメッセージを送り届けるサービスを提供するインターネットのプロトコル階層である。IP層200では、データを送信する発信先のアドレス、データを受信する宛先のアドレスを管理し、データをアドレス情報に従ってネットワーク内をどのような経路で宛先ホストまで届けるかを管理するルーティング機能を実行している。TCP/UDP層201は、発信アプリケーションプロセスから受信アプリケーションプロセスにメッセージを送り届けるサービスを提供するトランスポート階層である。TCPはコネクション型サービスであり、通信の高度な信頼性を保証する。一方、UDPはコネクションレス型のサービスであり、信頼性の保証を行わない。アプリケーション層202は、複数のプロトコルを規定し、このプロトコルには、例えば、以下のようなものがある。ファイル転送サービスであるFTPFileTransferProtocolがある。また、ネットワーク管理プロトコルであるSNMPがある。また、プリンタ印刷用のサーバプロトコルであるLPDがある。また、WWWWorldWideWebサーバのプロトコルであるHTTPdがある。また、電子メール送受信プロトコルであるSMTPSimpleMailTransferProtocolがある。また、メールダウンロードプロトコルPOP3PostOfficeProtocol-Version3がある。また、ユーザの電子メールアドレス等を管理しているディレクトリデータベースにアクセスするためのプロトコルであるLDAPLightweightDirectoryAccessProtocolがある。また、RFC1510で規定されているKerberos認証プログラムがある。次に、MFP100の操作部133の操作画面例について、図4を用いて説明する。図4は本発明の実施形態1のMFPの送信宛先情報を格納する宛先表登録画面である。尚、この宛先表登録画面では、例えば、MFP101のIFAX宛先等の各種宛先を登録することが可能である。宛先表登録画面において、送信種別フィールド250は、送信宛先にどのような手法で送信するかを決定する項目である。これは、例えば、プルダウンメニューで構成され、FAX、IFAX、Email、Fileから1つを選択することができる。ここでは、送信種別フィールド250には、IFAXが選択されている。IFAXが選択されると、アドレス、サーバ経由、解像度、用紙サイズ、圧縮方式の情報が表示される。アドレスフィールド251は、アドレスを入力するための項目である。ここでは、アドレスフィールド251には、MFP101の電子メールアドレスであるifaxcopy2.xyz.co.jpが入力されている。サーバ経由指定フィールド252は、送信時にデータをメールサーバに送り、メールサーバから目的の宛先であるMFP101に送信するか、直接MFP101に送信するかを選択するスイッチである。ここでは、メールサーバを経由しないことを示すしないが設定されている。一方、メールサーバを経由する場合には、するが設定される。送信宛先がインターネット経由の宛先である場合では、ファイアウォール等の中継ノードが存在するので、直接送信することはできないが、同一ネットワーク上の宛先である場合はメールサーバに負荷をかけることなく送信することができる。解像度指定フィールド253~256は、MFP101が受信することができる解像度を指定することができるスイッチである。解像度200×100dpiと200×200dpiは、通常は、どの機器でもIFAXによる受信を行うことができる解像度であるため、選択することはできない。一方、他の解像度に関しては、該当するフィールドを操作する毎に、その表示状態が白黒に反転し、黒表示されているフィールドは、その解像度が選択されていることを示している。図4では、解像度指定フィールド254と、解像度指定フィールド255が選択されていて、200×400dpiと400×400dpiの解像度はMFP101が受信できることを示している。ここで、例えば、スキャン時に、600×600dpiでスキャンされた画像はこのままではMFP101は受信することができない。そのため、この場合は、スキャンされた画像は、MFP101が受信できる最高解像度である400×400dpiに解像度変換される。用紙サイズ指定フィールド257及び258は、MFP101が受信できる用紙サイズを指定するためのスイッチである。ここで、用紙サイズA4は、通常、どの機器でも受信できる解像度であるため選択できない。ここで、MFP101は、B4、A3サイズの画像を受信することができるため、用紙サイズ指定フィールド257及び258は選択されている。ここで、例えば、スキャン時に、A3サイズで読み込まれた画像は、MFP101にはA3サイズの画像で送信するが、受信側がA3サイズの画像を受信できない場合は受信側が受信できる最大サイズの用紙サイズに変倍してから送信する。圧縮方式指定フィールド259及び260は、MFP101が受信できる圧縮画像フォーマットを選択するスイッチである。ここでは、MR、MMR方式を指定することが可能である。尚、文字等による文書画像であれば、MH<MR<MMRの順番で圧縮率が高い。また、MH方式は、通常、どの機器でも受信することができるため選択できない。ここで、MFP101は、MR、MMR方式の画像を受信することができるため、圧縮方式指定フィールド259及び260は選択されている。MFP101には、圧縮率が高いMMR方式の画像で送信するが、受信機がMMR方式の画像を受信できない場合は、受信側が受信できる最大の圧縮率の圧縮方式に圧縮して、画像を送信する。そして、この宛先表登録画面において、各種設定が完了して、その設定を確定する場合には、OKボタン270を操作することで、各種設定値が宛先表として、例えば、RAM123に記憶される。一方、設定操作をキャンセルする場合には、キャンセルボタン271を操作することで、各種設定値をリセットすることができる。次に、実施形態1の電子メールデータの構成例について、図5を用いて説明する。図5は本発明の実施形態1の電子メールデータの構成例を示す図である。ここでは、MFP100でスキャンした画像を電子メールに添付してMFP101に送信する際の電子メールデータの構成を示している。Dateフィールド300には、MFP100が送信した時間情報が入力されている。Fromフィールド301には、MFP100の電子メールアドレスが入力されている。Toフィールド302には、MFP101の電子メールアドレスが入力されている。Subjectフィールド303には、imageという文字列が入力されている。Disposition-Notification-Toフィールド304は、MFP100が送達確認を要求し、送達確認メールMDNデータを送信してもらうメールアドレスを指定するフィールドである。ここでは、MFP100のメールアドレスが入力されている。Message-Idフィールド305は、メール固有のIDを示す番号である。これは、同一番号のメールが存在しないようにメールアドレスと時間データを含むデータから構成されている。MIME-Versionフィールド306は、MIMEのバージョン番号が入力されている。Content-Typeフィールド307は、文字列------_422E51E54FF704D75EF8_により、電子メールデータが複数のブロックに分割されていることを示している。フィールド310~316が1つのブロックである。フィールド311よりこの部分が日本語JISコードで書かれた文字列であることが示され、フィールド314がデータ文字列、つまり、電子メールデータの本文である。フィールド316~330の部分がもう一つのブロックであり、フィールド317~319の情報より、この部分がGS2005.tifというファイル名のTIFF画像ファイルであることが示されている。また、フィールド321~328のデータは、このファイルをBASE64エンコードしたデータであることを示している。次に、本発明の実施形態1の図5の電子メールデータをMFP100からMFP101に直接送信する際のSMTPプロトコルによるシーケンスフロー、図6を用いて説明する。図6は本発明の実施形態1のSMTPプロトコルのシーケンスフローを示す図である。図4で示したように、MFP100の宛先表には、MFP100からMFP101に送信する場合は、サーバ経由指定フィールド252には、メールサーバを経由せずに直接送信ができることを示すサーバを経由しないの情報が設定されている。このため、MFP100ではMFP101に送信する場合、MFP101に直接SMTP接続400を行う。SMTP接続されたMFP101は、ドメイン名情報を含む文字列401を返答する。MFP100より、EHLOコマンド402を投げかけると、MFP101では自機が対応しているSMTP拡張コマンドを250-から始まる文字列とともに通知する403。具体的なSMTP拡張コマンドMFP101が有する機能を示すコマンドは、404から406に対応する。ここでは、MFP101は、8bitの電子メールデータを受信する受信機能、TLS暗号により通信路を暗号化する暗号化機能、MDNを直接返答する直接返答機能を有しているものとする。そこで、この場合、MFP101は、8bitの電子メールデータの受信機能を示す8BITMIMEコマンド404、TLS暗号による通信路の暗号化機能を示すSTARTTLSコマンド405をMFP100に送信する。更には、MFP101は、MDNの直接返答機能返答方法を示すDIRECTMDNコマンド406をMFP100に送信する。尚、MFP101には、機器設定としてMDNを直接返答する/しないのスイッチがある。従って、MDNの直接返答機能を有している場合には、するに設定されている場合にのみ、MFP100からのDIRECTMDNコマンド407に対して、MDNの直接返答を実行する。一方、しないに設定されている場合、MFP100からのDIRECTMDNコマンド407に対して、MDNの直接返答は実行しない。ここで、MFP100からのDIRECTMDNコマンド407は、MDNの直接返答を要求するコマンドである。また、MDNの直接返答とは、メールサーバを経由せずに、送信先にMDNを直接返答することを意味するものである。また、MFP101内の宛先表に、MFP100の宛先表が登録されている場合には、その宛先表からサーバ経由指定フィールド252図4の設定内容サーバ経由する/しないを取得可能である。そこで、このような場合には、その設定内容に従って、MDNの直接返答の実行の可否を判定するようにしても良い。つまり、設定内容にサーバ経由しないが設定されている場合には、MDNの直接返答を実行するようにしても良い。図5の説明に戻る。MFP101より、DIRECTMDNコマンド407を正常受信すると、MFP101から、250から始まる正常応答メッセージ408が返信される。次に、MFP100からメール送信者を示すMAILコマンド409をMFP101に送信する。これをMFP101が正常に受信すると、MFP101から、250から始まる正常応答メッセージ410が返信される。次に、MFP100から、メール受信者を示すRCPTコマンド411を送信する。これをMFP101が正常に受信すると、MFP101から、250から始まる正常応答メッセージ412が返信される。次に、MFP100から、これから電子メールデータを送信することを示すDATAコマンド413を送信後、電子メールデータ図5の300から329を送信する。その後、電子メールデータの終了を示す.414を送信する。MFP100から正常に電子メールデータを受信すると、MFP101は、354から始まる正常応答メッセージ415を返信する。次に、MFP100から、接続を切るためのQUITコマンド416を送信する。これに対して、MFP101から、221から始まるメッセージ417を返信する。以上の処理によって、MFP100とMFP101間のSMTP接続は終了する。次に、MFP101によるSMTP受信機能によるSMTP受信処理について、図7を用いて説明する。図7は本発明の実施形態1のSMTP受信処理を示すフローチャートである。尚、ここでのSMTP受信は、例えば、MFP100やクライアントPC104からのSMTP送信される電子メールデータを受信する場合がある。電源が供給されると、SMTP受信機能が起動し、ステップS501で、接続待ち状態となる。SMTP接続が開始されると、ステップS501からステップS502に処理が移行し、SMTP接続応答を返答する接続応答返信処理図6の401が動作する。接続応答返信後、受信したコマンドを調べ、ステップS503で、EHLOコマンドであるか否かを判定する。EHLOコマンドある場合ステップS503でYES、ステップS506に進む。一方、EHLOコマンドでない場合ステップS503でNO、ステップS504で、HELOコマンドであるか否かを判定する。HELOコマンドである場合ステップS504でYES、ステップS515に進む。一方、HELOコマンドでない場合ステップS504でNO、ステップS505に進み、コマンドエラーとして新たなコマンド受信を待機する。ステップS504において、受信したコマンドがHELOコマンドである場合、ステップS515で、HELOコマンドの応答返信処理を実行し、ステップS516へと処理を進める。ステップS503において、受信したコマンドがEHLOコマンドである場合、ステップS506で、自機が備えるSMTP拡張機能を含むメッセージをEHLOコマンド応答としてEHLOコマンドの応答返信処理を実行する。ここでのメッセージは、図6の404~406に示される、8BITMIME、STRTTLS、DIRECTMDN等である。次に、自機が備えるSMTP拡張機能で生成可能なコマンドを調査する。まず、ステップS507で、8BITMIMEコマンドであるか否かを判定する。8BITMIMEコマンドでない場合ステップS507でNO、ステップS509に進む。8BITMIMEコマンドである場合ステップS507でYES、ステップS508に進み、250OKの文字列を返答するOK返信処理を実行する。ステップS509で、DIRECTMDNコマンドであるか否かを判定する。DIRECTMDNコマンドでない場合ステップS509でNO、ステップS512に進む。一方、DIRECTMDNコマンドである場合ステップS509でYES、ステップS510に進み、250OKの文字列を返答するOK返信処理を実行する。ステップS511で、接続要求を発行した発行元のIPアドレスをRAM132に記憶する。ステップS512で、STRTTLSコマンドであるか否かを判定する。STRTTLSコマンドでない場合ステップS512でNO、ステップS516に進む。一方、STRTTLSコマンドである場合ステップS512でYES、ステップS513に進み、250OKの文字列を返答するOK返信処理を実行する。ステップS514で、TLS暗号化処理を実行する。ステップS516で、MAILコマンド処理を実行する。これは、MFP101に設定されている送信者のメールアドレス情報をMAILコマンド図6の409にて受信すると共に、250から始まる文字列であるMAILコマンドの応答図6の410を送信する。ステップS517で、RCPTコマンド処理を実行する。これは、送信宛先のメールアドレス情報が含まれるRCPTコマンド図6の411を受信し、250から始まる文字列からなるRCPTコマンド応答図6の412を送信する。ステップS518で、DATAコマンド処理を実行する。これは、図5の電子メールデータをこれから送信することを示すDATAコマンド図6の413を受信する。その後、次に送られてくる電子メールデータ図6の300、329、414を受信し、354から始まる文字列であるDATAコマンドの応答を送信する図6の415。尚、電子メールデータの終了は、.だけからなる文字列414を検出することにより判断し、一連の動作が終了する。ステップS519で、QUITコマンド処理を実行する。これは、送信を終了し、接続を切るQUITコマンド図6の416を受信し、221の文字列から始まるQUITコマンド図6の417を返答し、SMTP接続を切断する以上の処理が完了すると、SMTP受信が終了する。これにより、MFP101では、例えば、図5に示す電子メールデータを受信することになる。そして、この電子メールデータ中の、メール本文のデータ314はJISコードからSJISコードのテキスト情報に変換し、その後、ラスタライズ処理を施して画像データに変換する。また、この電子メールデータ中の画像データ部分321から328は、BASE64形式でデコードして、TIFFファイルに変換する。次に、TIFFファイルから1ページ単位の画像データを切り出し、切り出したデータに対して画像デコード処理を行う。そして、すべてのページに対する、画像デコード処理が正常に完了した場合、図8に示すMDNデータを作成する。次に、実施形態1のMDNデータの構成例について、図8を用いて説明する。図8は本発明の実施形態1のMDNデータの構成例を示す図である。図8の600から607の部分がこのメールのメールヘッダである。Dateフィールド600には、データ送信時の時間情報が入力されている。Fromフィールド601は、メールを送信する送信元であるMFP101の電子メールアドレスが入力されている。Subjectフィールド602には、MessageDispositionNotificationという文字列が入力されている。Toフィールド603には、図5で説明した画像が添付されているメールの、Disposition-Notification-Toフィールド304で設定されている宛先が設定される。これにより、MDNデータは、この宛先に送信が行われることになる。Message-IDフィールド604は、送信時刻、ホスト名、ドメイン名、ユーザ名情報を含む文字列であり、同一のIDのデータは他に存在しないように作成される。MIME-Versionフィールド605は、MIMEのバージョン番号が入力されている。Content-Typeフィールド606は、このメールがレポートタイプの通知メールであることが入力されている。フィールド607は、メールがxiSCzkWI5qcOuiWI6qaMueTIB6というバウンダリで区切られていることが入力されている。ここでは、フィールド609、615、622にて区切られている。そして、フィールド610~614でメールの第1の部分、フィールド616~621でメールの第2の部分に分割されている。フィールド610は、第1の部分がテキスト形式のデータであることを示し、フィールド612、613はそのデータ文字列である。フィールド616は、第2の部分が通知メッセージであることを示し、フィールド618は、このメッセージを作成したMFP101のホスト名、ドメイン名が記述される。Original-Message-IDフィールド619は、図5で説明した画像が添付されているメールのMessage-Id304が入力され、どのメールに対する通知メールなのかを判断することができる。Dispositionフィールド620は、この通知メールが自動的に応答されたものであり、その結果は正常に処理されたことを示している。次に、MFP101によるMDNデータを送信するMDN送信処理について、図9を用いて説明する。図9は本発明の実施形態1のMDN送信処理を示すフローチャートである。この処理は、MDNを送信する際に動作を開始する。ステップS701で、DIRECTMDNコマンド図4の407の内容を参照して、送信者からMDNDIRECTが指定されているか否かを判定する。MDNDIRECTが指定されている場合ステップS701でYES、ステップS702に進み、ステップS511で記憶したIPアドレスに対応する宛先に、図8のMDNデータを送信し、処理を終了する。一方、MDNDIRECTが指定されていない場合ステップS701でNO、ステップS703に進み、メールサーバ例えば、サーバ103にMDNデータを送信して、処理を終了する。メールサーバに送信されたMDNデータは、メールサーバを経由して最終的には、図5で説明した画像が添付されているメールのDisposition-Notification-Toの宛先に送信される。以上説明したように、実施形態1によれば、メールサーバを経由しなくても電子メールプロトコルによる通信が可能な環境では、送達確認のMDNデータもメールサーバを返さずに通信を行う。一方、メールサーバを経由しなければ通信ができない環境ではメールサーバを経由して送達確認のMDNデータの通信を行う。このように、装置間の環境に応じて、MDNデータの送受信経路を適応的に選択して、MDNデータを確実に送信することができる。また、送信したメール及びそれに添付される画像データが、受信側に正常に届いたか否かを送信側で判断することができる。<実施形態2>実施形態2では、実施形態1のMDN送信処理の応用例について説明する。図10は本発明の実施形態2のMDN送信処理を示すフローチャートである。この処理は、MDNを送信する際に動作を開始する。ステップS801で、DIRECTMDNコマンド図4の407の内容を参照して、送信者からMDNDIRECTが指定されているか否かを判定する。MDNDIRECTが指定されている場合ステップS801でYES、ステップS802に進む。ステップS802で、図5で説明した画像が添付されているメールのDisposition-Notification-Toの宛先を、DNSサーバサーバ103に問い合わせて、送信すべき宛先のIPアドレスを取得する。この際、DNSサーバには、HOST名のAレコードまたはメール配信専用のMXMaileXchangeレコードを用いて宛先のIPアドレスを取得する。ステップS803で、図8のMDNデータを、ステップS802で取得したIPアドレスに対応する宛先にSMTPプロトコルを用いて送信し、処理を終了する。一方、MDNDIRECTが指定されていない場合ステップS801でNO、ステップS804に進み、メールサーバ例えば、サーバ103にMDNデータを送信して、処理を終了する。メールサーバに送信されたMDNデータは、メールサーバを経由して最終的には、図5で説明した画像が添付されているメールのDisposition-Notification-Toの宛先に送信される。以上説明したように、実施形態2によれば、MDNデータの送信先を、DNSサーバに問い合わせることで、MDNデータの送信先を特定する。これにより、電子メールデータから、MDNデータの送信先を特定できない場合でも、確実にMDNデータを正しい宛先へ送信することが可能となる。<実施形態3>実施形態1では、MDNデータの要求は、SMTPプロトコルに従って送信先に送信する構成としているが、これに限定されない。例えば、電子メールデータ中に、MDNデータの要求を示す情報を記述する構成であっても良い。そこで、実施形態3では、このMDNデータの要求を示す情報が記述された電子メールを用いる場合の構成について説明する。図11は本発明の実施形態3の電子メールデータの構成例を示す図である。ここでは、MFP100でスキャンした画像を電子メールに添付してMFP101に送信する際の電子メールデータの構成を示している。Dateフィールド900には、MFP100が送信した時間情報が入力されている。Fromフィールド901には、MFP100の電子メールアドレスが入力されている。Toフィールド902には、MFP101の電子メールアドレスが入力されている。Subjectフィールド903には、imageという文字列が入力されている。Disposition-Notification-Toフィールド904は、MFP100が送達確認を要求し、送達確認メールMDNデータを送信してもらうメールアドレスを指定するフィールドである。ここでは、MFP100のメールアドレスが入力されている。X-MDNDIRECTフィールド905は、送信者が送達確認メールをメールサーバを介さず、送信機であるMFP100に直接送信してもらうことを希望していることを示している。Message-Idフィールド906は、メール固有のIDを示す番号である。これは、同一番号のメールが存在しないようにメールアドレスと時間データを含むデータから構成されている。MIME-Versionフィールド907は、MIMEのバージョン番号が入力されている。Content-Typeフィールド908は、文字列------_422E51E54FF704D75EF8_により、電子メールデータが複数のブロックに分割されていることを示している。フィールド911~916が1つのブロックであり、フィールド911よりこの部分が日本語JISコードで書かれた文字列であることが示され、フィールド915がデータ文字列である。フィールド917~931の部分がもう一つのブロックであり、フィールド917~920の情報より、この部分がGS2005.tifというファイル名のTIFF画像ファイルであることが示されている。また、フィールド922~929のデータは、このファイルをBASE64エンコードしたデータであることを示している。実施形態3の電子メールデータでは、実施形態1の電子メールデータの構成に加えて、送達確認メールの要求を明示的に記述している。次に、MFP101で、図11の電子メールデータを受信する際の電子メールデータ解析処理について、図12を用いて説明する。図12は本発明の実施形態3の電子メールデータ解析処理を示すフローチャートである。電子メールデータを受信すると、ステップS951で、画像抽出処理を実行する。ここでは、メール本文のデータ図11の915はJISコードからSJISコードのテキスト情報に変換し、その後、ラスタライズ処理を施して画像データに変換する。また、電子メールデータ中の画像データ部分図11の922から929は、BASE64形式でデコードして、TIFFファイルに変換する。次に、TIFFファイルから、1ページ単位の画像データを切り出し、切り出したデータに対して画像デコード処理を行う。次に、ステップS952で、Disposition-Notification-Toフィールド図11の904中に宛先が存在するか否かを判定する。宛先が存在する場合ステップS952でYES、ステップS953に進み、MDNデータを送信する宛先情報ここでは、ifaxcopy1.xyz.co.jpを抽出する。そして、ステップS954で、その宛先情報に対するMDNデータを作成し、送信する。一方、宛先が存在しない場合ステップS952でNO、ステップS955に進み、X-MDNDIRECTフィールド図11の905が存在するか否かを判定する。尚、ステップS952で、Disposition-Notification-Toフィールドに宛先が存在しないと判断してステップS955に進んだ場合、ステップS959に進む。なぜなら、Disposition-Notification-Toフィールドがない場合はMDNを要求していないため、原則X-MDNDIRECTフィールドが存在しないためである。逆に言えば、MDN要求を行う場合はDisposition-Notification-Toフィールドを付す。X-MDNDIRECTフィールドが存在する場合ステップS955でYES、ステップS956に進み、Disposition-Notification-Toの宛先を、DNSサーバに問い合わせて、送信すべき宛先のIPアドレスを取得する。この際、DNSサーバには、HOST名のAレコードまたはメール配信専用のMXMaileXchangeレコードを用いてDisposition-Notification-ToのIPアドレスを取得する。ステップS957で、MDNデータを、ステップS956で取得したIPアドレスに対応する宛先にSMTPプロトコルを用いて送信する。一方、X-MDNDIRECTフィールドが存在しない場合ステップS955でNO、ステップS958で、MDNデータをメールサーバ例えば、サーバ103に送信する。ステップS959で、受信した電子メールデータより抽出した画像データに対して印刷設定の有無を判定する。印刷設定がある場合ステップS959でYES、ステップS960に進み、その印刷設定に従って印刷を実行する。一方、印刷設定がない場合ステップS959でNO、ステップS961に進み、転送設定の有無を判定する。転送設定がある場合ステップS961でYES、ステップS962に進み、その転送設定に従って転送を実行する。尚、この転送設定による転送先としては、FAX、IFAXや、FTP、SMB等のファイル転送の宛先がある。一方、転送設定がない場合ステップS961でNO、処理を終了する。尚、ステップS959やステップS961における印刷設定及び転送設定の有無の判定は、例えば、電子メールデータの受信時に、電子メールデータに設定されている属性情報に従って行う。また、電子メールの受信方法としては、SMTP、POP受信を用いて説明したが、IMAP等の他の予め定められた通信プロトコルを用いて、電子メールを受信する構成であっても良い。以上説明したように、実施形態3によれば、MDNデータの要求をSMTPプロトコルに従って送信するのではなく、電子メールデータ中に、MDNデータの要求を示す情報を記述する構成とする。この構成によれば、例えば、MDNデータの要求をSMTPプロトコル中に従って直接送信先へ送信しようとして、誤ってメールサーバ経由で送信してしまった場合に、そのMDNデータの要求が消失してしまう可能性を防止することが可能となる。以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。