Network Working Group A. Gulbrandsen
Request for Comments: 5530 Oryx Mail Systems GmbH
Category: Standards Track May 2009
IMAP Response Codes
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.
IMAP応答は、応答のタイプ（OK、NO、BAD）、任意の機械読み取り可能な応答コード、および人間可読テキストから成ります。
This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.
この文書では、より優れた相互運用性とエラー報告のために、機械読み取り可能な応答コードの様々を収集し、文書化します。
Section 7.1 of [RFC3501] defines a number of response codes that can help tell an IMAP client why a command failed. However, experience has shown that more codes are useful. For example, it is useful for a client to know that an authentication attempt failed because of a server problem as opposed to a password problem.
[RFC3501]の7.1節では、コマンドが失敗した理由をIMAPクライアントに伝えることができます応答コードの数を定義します。しかし、経験はより多くのコードが有用であることを示しています。例えば、それはパスワードの問題とは対照的に、認証試行があるため、サーバーの問題の障害が発生したことを知ることは、クライアントのために有用です。
Currently, many IMAP servers use English-language, human-readable text to describe these errors, and a few IMAP clients attempt to translate this text into the user's language.
現在、多くのIMAPサーバは、これらのエラーを記述するために英語、人間が読めるテキストを使用して、いくつかのIMAPクライアントは、ユーザーの言語にこのテキストを翻訳しようとします。
This document names a variety of errors as response codes. It is based on errors that have been checked and reported on in some IMAP server implementations, and on the needs of some IMAP clients.
この文書名応答コードなどのエラーの様々な。これはチェックして、いくつかのIMAPサーバの実装で報告、および一部のIMAPクライアントのニーズにされたエラーに基づいています。
This document doesn't require any servers to test for these errors or any clients to test for these names. It only names errors for better reporting and handling.
この文書では、これらの名前をテストするためにこれらのエラーまたは任意のクライアントをテストするために、任意のサーバーを必要としません。それより良い報告と処理のための唯一の名前のエラーを。
Formal syntax is defined by [RFC5234] as modified by [RFC3501].
[RFC3501]によって修正され、正式な構文は[RFC5234]で定義されます。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision.
「C：」で始まる例ラインはで始まるクライアントとものによって送信された「S：」サーバーで。 "[...]" エリジオンを意味します。
This section defines all the new response codes. Each definition is followed by one or more examples.
このセクションでは、すべての新しい応答コードを定義します。各定義は、1つ以上の例が続いています。
UNAVAILABLE Temporary failure because a subsystem is down. For example, an IMAP server that uses a Lightweight Directory Access Protocol (LDAP) or Radius server for authentication might use this response code when the LDAP/Radius server is down.
UNAVAILABLE一時的な障害サブシステムがダウンしているため。 LDAP / RADIUSサーバがダウンした場合たとえば、認証のためのLDAP（Lightweight Directory Access Protocol）サーバまたはRADIUSサーバを使用してIMAPサーバーは、この応答コードを使用する場合があります。
C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] User's backend down for maintenance
AUTHENTICATIONFAILED Authentication failed for some reason on which the server is unwilling to elaborate. Typically, this includes "unknown user" and "bad password".
AUTHENTICATIONFAILED認証は、サーバーが精巧に消極的である上、いくつかの理由で失敗しました。通常、これは「不明なユーザー」と「無効なパスワード」が含まれます。
This is the same as not sending any response code, except that
when a client sees AUTHENTICATIONFAILED, it knows that the
problem wasn't, e.g., UNAVAILABLE, so there's no point in
trying the same login/password again later.
C: b LOGIN "fred" "foo" S: b NO [AUTHENTICATIONFAILED] Authentication failed
C：B LOGIN "フレッド" "FOO" S：NO [AUTHENTICATIONFAILED】認証が失敗bは
AUTHORIZATIONFAILED Authentication succeeded in using the authentication identity, but the server cannot or will not allow the authentication identity to act as the requested authorization identity. This is only applicable when the authentication and authorization identities are different.
AUTHORIZATIONFAILED認証は、認証IDを使用してに成功しましたが、サーバーは、認証アイデンティティが要求された認証アイデンティティとして機能することはできませんすることはできませんか。認証と承認のアイデンティティが異なっている場合にのみ適用されます。
C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN [...] S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
Cは：AUTHENTICATE PLAIN [...] S C2：C2 NO [AUTHORIZATIONFAILED]オーセンティケータは、管理者ではありません
EXPIRED Either authentication succeeded or the server no longer had the necessary data; either way, access is no longer permitted using that passphrase. The client or user should get a new passphrase.
EXPIREDいずれかの認証が成功したか、サーバーがもはや必要なデータがありませんでした。いずれかの方法で、アクセスはもはやそのパスフレーズを使用して許可されません。クライアントまたはユーザーが新しいパスフレーズを取得する必要があります。
C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more
PRIVACYREQUIRED The operation is not permitted due to a lack of privacy. If Transport Layer Security (TLS) is not in use, the client could try STARTTLS (see Section 6.2.1 of [RFC3501]) and then repeat the operation.
PRIVACYREQUIRED操作が原因のプライバシーの欠如に許可されていません。トランスポート層セキュリティ（TLS）が使用されていない場合、クライアントはSTARTTLSを試してみてください（[RFC3501]のセクション6.2.1を参照）、操作を繰り返してできました。
C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C：受信トレイのSを選択D：D NO [PRIVACYREQUIRED]の接続には、プライバシーを提供しています
CONTACTADMIN The user should contact the system administrator or support desk.
ユーザーをCONTACTADMINすると、システム管理者やサポートデスクにお問い合わせください。
C: e login "fred" "foo"
S: e OK [CONTACTADMIN]
NOPERM The access control system (e.g., Access Control List (ACL), see [RFC4314]) does not permit this user to carry out an operation, such as selecting or creating a mailbox.
NOPERMアクセス制御システム（例えば、アクセス制御リスト（ACL）、[RFC4314]を参照）は、メールボックスを選択または作成するように、操作を実行するためにこのユーザを許可しません。
C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access denied
INUSE An operation has not been carried out because it involves sawing off a branch someone else is sitting on. Someone else may be holding an exclusive lock needed for this operation, or the operation may involve deleting a resource someone else is using, typically a mailbox.
それは他の誰かが上に座っている枝をのこぎりで切る必要とするため、操作INUSE行われていません。他の誰かが、この操作に必要な排他ロックを保持することができる、または操作は、通常、メールボックスを他の誰かが使用しているリソースを削除することを含むことができます。
The operation may succeed if the client tries again later.
クライアントが後で再び試みる場合、操作は成功するかもしれません。
C: g delete "/archive/projects/experiment-iv" S: g NO [INUSE] Mailbox in use
C：G "/アーカイブ/プロジェクト/実験-IV" を削除S：グラム使用中のNO [INUSE]メールボックス
EXPUNGEISSUED Someone else has issued an EXPUNGE for the same mailbox. The client may want to issue NOOP soon. [RFC2180] discusses this subject in depth.
他の誰かが同じメールボックスのEXPUNGEを発行していEXPUNGEISSUED。クライアントはすぐにNOOPを発行することもできます。 [RFC2180]は深さでこの主題について論じています。
C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42
S: h OK [EXPUNGEISSUED] Search completed
CORRUPTION The server discovered that some relevant data (e.g., the mailbox) are corrupt. This response code does not include any information about what's corrupt, but the server can write that to its logfiles.
CORRUPTIONサーバは、いくつかの関連データ（例えば、メールボックス）が破損していることを発見しました。この応答コードが破損しているのですが、サーバーがそのログファイルにそれを書くことができるかについての情報が含まれていません。
C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Cannot open mailbox
SERVERBUG The server encountered a bug in itself or violated one of its own invariants.
サーバーをSERVERBUGこと自体にバグに遭遇したり、独自の不変量の1に違反しています。
C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen
CLIENTBUG The server has detected a client bug. This can accompany all of OK, NO, and BAD, depending on what the client bug is.
CLIENTBUGサーバーは、クライアントのバグを検出しました。これは、クライアントのバグが何であるかに応じて、[OK]のすべて、NO、およびBADに同行することができます。
C: k1 select "/archive/projects/experiment-iv"
[...]
S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages)
[...]
S: k2 OK [CLIENTBUG] Done
CANNOT The operation violates some invariant of the server and can never succeed.
操作は、サーバーの一部不変に違反することができず、決して成功しないことができます。
C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported
LIMIT The operation ran up against an implementation limit of some kind, such as the number of flags on a single message or the number of flags used in a mailbox.
操作を制限するような単一のメッセージにフラグの数またはメールボックスに使用されるフラグの数など、いくつかの種類の実装の限界に直面しました。
C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
S: m NO [LIMIT] At most 32 flags in one mailbox supported
OVERQUOTA The user would be over quota after the operation. (The user may or may not be over quota already.)
制限容量超過ユーザーが操作した後、クォータを超えることでしょう。 （ユーザは、または既に割当て上であってもなくてもよいです。）
Note that if the server sends OVERQUOTA but doesn't support the
IMAP QUOTA extension defined by [RFC2087], then there is a
quota, but the client cannot find out what the quota is.
C: n1 uid copy 1:* oldmail S: n1 NO [OVERQUOTA] Sorry
C：N1 uidのコピー1：* S oldmail：N1 NO [制限容量超過]申し訳ありません
C: n2 uid copy 1:* oldmail S: n2 OK [OVERQUOTA] You are now over your soft quota
C：n2のuidはコピー1：* oldmail S：N2 OK [制限容量超過]あなたのソフトクォータの上になりました
ALREADYEXISTS The operation attempts to create something that already exists, such as when the CREATE or RENAME directories attempt to create a mailbox and there is already one of that name.
操作は、CREATEまたはRENAMEディレクトリがメールボックスを作成しようとすると、その名前の1がすでに存在しているときのように、すでに存在しているものを作成しようとしALREADYEXISTS。
C: o RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists
NONEXISTENT The operation attempts to delete something that does not exist. Similar to ALREADYEXISTS.
存在しない操作が存在しないものを削除しようとします。 ALREADYEXISTSに似ています。
C: p RENAME this that
S: p NO [NONEXISTENT] No such mailbox
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminal "resp-text-code".
以下の構文仕様は、[RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。 [RFC3501]は非末端「RESPテキストコード」を定義します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lowercase characters to define token strings is for editorial clarity only.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するには、上または小文字の使用は、編集上明確にするためです。
resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT"
Revealing information about a passphrase to unauthenticated IMAP clients causes bad karma.
認証されていないIMAPクライアントにパスフレーズについての情報を明らかにすることは悪いカルマの原因となります。
Response codes are easier to parse than human-readable text. This can amplify the consequences of an information leak. For example, selecting a mailbox can fail because the mailbox doesn't exist, because the user doesn't have the "l" right (right to know the mailbox exists) or "r" right (right to read the mailbox). If the server sent different responses in the first two cases in the past, only malevolent clients would discover it. With response codes it's possible, perhaps probable, that benevolent clients will forward the leaked information to the user. Server authors are encouraged to be particularly careful with the NOPERM and authentication-related responses.
応答コードは、人間が読めるテキストよりも解析が容易です。これは、情報漏洩の影響を増幅することができます。メールボックスが存在しないため、ユーザが「L」右（メールボックスが存在知る権利）または「R」権利（メールボックスを読み取るための権利）を有していないため、例えば、メールボックスを選択すると、失敗することができます。サーバは、過去に最初の2つの場合に異なる応答を送信した場合、唯一の悪意のクライアントがそれを発見するでしょう。応答コードで、それは慈悲深いクライアントは、ユーザーに漏洩した情報を転送することは、おそらく可能性、可能です。サーバーの作者はNOPERMと認証関連の応答に特に注意することをお勧めします。
The IANA has created the IMAP Response Codes registry. The registry has been populated with the following codes:
IANAは、IMAP応答コードレジストリを作成しました。レジストリは、以下のコードが読み込まれました：
NEWNAME RFC 2060 (obsolete) REFERRAL RFC 2221 ALERT RFC 3501 BADCHARSET RFC 3501 PARSE RFC 3501 PERMANENTFLAGS RFC 3501 READ-ONLY RFC 3501 READ-WRITE RFC 3501 TRYCREATE RFC 3501 UIDNEXT RFC 3501 UIDVALIDITY RFC 3501 UNSEEN RFC 3501 UNKNOWN-CTE RFC 3516 UIDNOTSTICKY RFC 4315 APPENDUID RFC 4315 COPYUID RFC 4315 URLMECH RFC 4467 TOOBIG RFC 4469 BADURL RFC 4469 HIGHESTMODSEQ RFC 4551 NOMODSEQ RFC 4551 MODIFIED RFC 4551 COMPRESSIONACTIVE RFC 4978 CLOSED RFC 5162 NOTSAVED RFC 5182 BADCOMPARATOR RFC 5255 ANNOTATE RFC 5257 ANNOTATIONS RFC 5257 TEMPFAIL RFC 5259 MAXCONVERTMESSAGES RFC 5259 MAXCONVERTPARTS RFC 5259 NOUPDATE RFC 5267 METADATA RFC 5464 NOTIFICATIONOVERFLOW RFC 5465 BADEVENT RFC 5465 UNDEFINED-FILTER RFC 5466 UNAVAILABLE RFC 5530 AUTHENTICATIONFAILED RFC 5530 AUTHORIZATIONFAILED RFC 5530
NEWNAME RFC 2060（廃止）の紹介RFC 2221 ALERTのRFC 3501 BADCHARSETのRFC 3501 PARSE RFC 3501 PERMANENTFLAGSのRFC 3501 READ-ONLY RFC 3501 READ-WRITEのRFC 3501 TRYCREATEのRFC 3501 UIDNEXTのRFC 3501 UIDVALIDITY RFC 3501 UNSEEN RFC 3501 UNKNOWN-CTEのRFC 3516 UIDNOTSTICKY RFC 4315 APPENDUID RFC 4315 COPYUIDのRFC 4315 URLMECHのRFC 4467がtooBigのRFC 4469 BADURL RFC 4469 HIGHESTMODSEQのRFC 4551 NOMODSEQのRFC 4551 MODIFIED RFC 4551 COMPRESSIONACTIVEのRFC 4978 CLOSED RFC 5162 NOTSAVED RFC 5182 BADCOMPARATORのRFC 5255注釈RFC 5257注釈RFC 5257 TEMPFAILのRFC 5259 MAXCONVERTMESSAGESのRFC 5259 MAXCONVERTPARTS RFC 5259 NOUPDATEのRFC 5267 METADATA RFC 5464 NOTIFICATIONOVERFLOWのRFC 5465 BADEVENTのRFC 5465 UNDEFINED-FILTER RFC 5466 UNAVAILABLE RFC 5530 AUTHENTICATIONFAILEDのRFC 5530 AUTHORIZATIONFAILEDのRFC 5530
EXPIRED RFC 5530 PRIVACYREQUIRED RFC 5530 CONTACTADMIN RFC 5530 NOPERM RFC 5530 INUSE RFC 5530 EXPUNGEISSUED RFC 5530 CORRUPTION RFC 5530 SERVERBUG RFC 5530 CLIENTBUG RFC 5530 CANNOT RFC 5530 LIMIT RFC 5530 OVERQUOTA RFC 5530 ALREADYEXISTS RFC 5530 NONEXISTENT RFC 5530
EXPIRED RFC PRIVACYREQUIRED RFC 5530 CONTACTADMINのRFC 5530 NOPERMのRFC 5530 INUSEのRFC 5530 EXPUNGEISSUED RFC 5530 CORRUPTIONのRFC 5530 SERVERBUGのRFC 5530 CLIENTBUGのRFC 5530ことはできませんRFC 5530 LIMITのRFC 5530制限容量超過のRFC 5530 ALREADYEXISTS RFC 5530に存在しないRFC 5530 5530
The new registry can be extended by sending a registration request to IANA. IANA will forward this request to a Designated Expert, appointed by the responsible IESG Area Director, CCing it to the IMAP Extensions mailing list at <ietf-imapext@imc.org> (or a successor designated by the Area Director). After either allowing 30 days for community input on the IMAP Extensions mailing list or a successful IETF Last Call, the expert will determine the appropriateness of the registration request and either approve or disapprove the request by sending a notice of the decision to the requestor, CCing the IMAP Extensions mailing list and IANA. A denial notice must be justified by an explanation, and, in cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
新しいレジストリは、IANAに登録要求を送信することにより、拡張することができます。 IANAは、<ietf-imapext@imc.org>でメーリングリストIMAP拡張（または地域ディレクターが指定する後継者）にそれをCCing、責任をIESGエリアディレクターによって任命指定エキスパート、この要求を転送します。メーリングリストIMAP拡張または成功したIETFラストコールにコミュニティの入力のために30日間可能のいずれかの後、専門家は、登録要求の妥当性を判断し、いずれかの要求者に意思決定の通知を送信することにより、要求を承認または不承認になる、CCing IMAP拡張はリストとIANAを郵送します。拒否通知は、それが可能である場合には、許容可能となるように要求を変更することができる方法についての具体的な提案が提供されなければならない、説明によって正当化し、する必要があります。
For each response code, the registry contains a list of relevant RFCs that describe (or extend) the response code and an optional response code status description, such as "obsolete" or "reserved to prevent collision with deployed software". (Note that in the latter case, the RFC number can be missing.) Presence of the response code status description means that the corresponding response code is NOT RECOMMENDED for widespread use.
各応答コードのため、レジストリは、「展開ソフトウェアとの衝突を防ぐために予約」「廃止」または説明（または拡張）関連のRFC応答コードおよび任意の応答コードのステータスの説明のリストを含みます。 （後者の場合、RFCの数が不足することができることに留意されたい。）応答コードステータス説明の存在は、対応する応答コードが広く使用には推奨されないことを意味します。
The intention is that any future allocation will be accompanied by a published RFC (including direct submissions to the RFC Editor). But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published, for example, before requesting IETF LC for the document.
その意図は、将来の割り当ては（RFC編集者に直接提出を含む）に公開RFCを伴うことになるということです。 RFCが公開されることは明らかと思われるしかし、一度公表のために承認される前RFCへの値の割り当てを可能にするために、指定Expertは、文書のためのIETF LCを要求する前に、例えば、割り当てを承認することができます。
The Designated Expert can also approve registrations for response codes used in deployed software when no RFC exists. Such registrations must be marked as "reserved to prevent collision with deployed software".
指定専門家はまた、何のRFCが存在しない場合に配備ソフトウェアで使用される応答コードの登録を承認することができます。このような登録は、「展開のソフトウェアとの衝突を防ぐために予約済み」としてマークする必要があります。
Response code registrations may not be deleted; response codes that are no longer believed appropriate for use (for example, if there is a problem with the syntax of said response code or if the specification describing it was moved to Historic) should be marked "obsolete" in the registry, clearly marking the lists published by IANA.
レスポンスコードの登録が削除されないことがあります。もはや使用するのに適したと考えられている応答コードは、（例えば、応答コードが言ったか、それを記述した仕様が歴史的に移動された場合の構文に問題がある場合は）明らかにマーキング、レジストリで「時代遅れ」とマークされなければなりませんIANAによって公開リスト。
Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale Wiggins, and Sarah Wilkin helped with this document.
ピーター・コーツ、マーク・クリスピン、フィリップ・ギュンター、アレクセイ・メルニコフ、ケンマーチソン、クリス・ニューマン、ティモ・シレーヌン、フィリップ・ヴァン・フーフ、デールウィギンズ、そしてサラウィルキンは、この文書を手伝ってくれました。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[RFC2087]マイヤーズ、J.、 "IMAP4クォータ拡張"、RFC 2087、1997年1月。
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC2180] Gahrns、M.、 "IMAP4マルチアクセスされるメールボックスの実践"、RFC 2180、1997年7月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]メルニコフ、A.、 "IMAP4アクセス制御リスト（ACL）拡張"、RFC 4314、2005年12月。
Author's Address
著者のアドレス
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
ARNT Gulbrandsenのオリックスメールシステム社Schweppermannstr。 8 D-81671ミュンヘン、ドイツ
Fax: +49 89 4502 9758 EMail: arnt@oryx.com
ファックス：+49 89 4502 9758 Eメール：arnt@oryx.com