Network Working Group K. Moore Request for Comments: 3461 University of Tennessee Obsoletes 1891 January 2003 Category: Standards Track Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Framework for the Delivery Status Notification Extension . . . 4 3. The Delivery Status Notification service extension . . . . . . 5 4. Additional parameters for RCPT and MAIL commands . . . . . . . 6 4.1 The NOTIFY parameter of the ESMTP RCPT command. . . . . . . . 7 4.2 The ORCPT parameter to the ESMTP RCPT command . . . . . . . . 8 4.3 The RET parameter of the ESMTP MAIL command . . . . . . . . . 9 4.4 The ENVID parameter to the ESMTP MAIL command . . . . . . . . 9
4.5 Restrictions on the use of Delivery Status Notification parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Conformance requirements . . . . . . . . . . . . . . . . . . . 10 5.1 SMTP protocol interactions. . . . . . . . . . . . . . . . . . 11 5.2 Handling of messages received via SMTP. . . . . . . . . . . . 11 5.2.1 Relay of messages to other conforming SMTP servers. . . . . 12 5.2.2 Relay of messages to non-conforming SMTP servers. . . . . . 13 5.2.3 Local delivery of messages. . . . . . . . . . . . . . . . . 14 5.2.4 Gatewaying a message into a foreign environment . . . . . . 14 5.2.5 Delays in delivery. . . . . . . . . . . . . . . . . . . . . 15 5.2.6 Failure of a conforming MTA to deliver a message. . . . . . 16 5.2.7 Forwarding, aliases, and mailing lists. . . . . . . . . . . 16 18.104.22.168 mailing lists . . . . . . . . . . . . . . . . . . . . . . 17 22.214.171.124 single-recipient aliases. . . . . . . . . . . . . . . . . 18 126.96.36.199 multiple-recipient aliases. . . . . . . . . . . . . . . . 18 188.8.131.52 confidential forwarding addresses . . . . . . . . . . . . 18 5.2.8 DSNs describing delivery to multiple recipients . . . . . . 19 5.3 Handling of messages from other sources . . . . . . . . . . . 19 5.4 Implementation limits . . . . . . . . . . . . . . . . . . . . 19 6. Format of delivery notifications . . . . . . . . . . . . . . . 20 6.1 SMTP Envelope to be used with delivery status notifications . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Contents of the DSN . . . . . . . . . . . . . . . . . . . . . 20 6.3 Message/delivery-status fields. . . . . . . . . . . . . . . . 21 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 9. Appendix - Type-Name Definitions . . . . . . . . . . . . . . . 24 9.1 "rfc822" address-type . . . . . . . . . . . . . . . . . . . . 24 9.2 "smtp" diagnostic-type. . . . . . . . . . . . . . . . . . . . 24 9.3 "dns" MTA-name-type . . . . . . . . . . . . . . . . . . . . . 25 10. Appendix - Example. . . . . . . . . . . . . . . . . . . . . . 26 10.1 Submission . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.2 Relay to Example.COM . . . . . . . . . . . . . . . . . . . . 28 10.3 Relay to Ivory.EDU . . . . . . . . . . . . . . . . . . . . . 29 10.4 Relay to Bombs.AF.MIL. . . . . . . . . . . . . . . . . . . . 30 10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV . . . . 31 10.6 "Delivered" DSN for Bob@Example.COM. . . . . . . . . . . . . 32 10.7 Failed DSN for Carol@Ivory.EDU . . . . . . . . . . . . . . . 33 10.8 Relayed DSN For Dana@Ivory.EDU . . . . . . . . . . . . . . . 34 10.9 Failure notification for Sam@Boondoggle.GOV. . . . . . . . . 35 11. Appendix - Changes since RFC 1891 . . . . . . . . . . . . . . 35 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 12.2 Informative References . . . . . . . . . . . . . . . . . . . 36 13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 37 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (format defined by ), sent to the envelope sender address (the argument of the SMTP MAIL command), containing an explanation of the error and at least the headers of the failed message. Experience with large mail distribution lists  indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems. Such experience has demonstrated a need for a delivery status notification service for Internet electronic mail, which: (a) is reliable, in the sense that any DSN request will either be honored at the time of final delivery, or result in a response that indicates that the request cannot be honored, (b) when both success and failure notifications are requested, provides an unambiguous and nonconflicting indication of whether delivery of a message to a recipient succeeded or failed, (c) is stable, in that a failed attempt to deliver a DSN should never result in the transmission of another DSN over the network, (d) preserves sufficient information to allow the sender to identify both the mail transaction and the recipient address which caused the notification, even when mail is forwarded or gatewayed to foreign environments, and (e) interfaces acceptably with non-SMTP and non-822-based mail systems, both so that notifications returned from foreign mail systems may be useful to Internet users, and so that the notification requests from foreign environments may be honored. Among the requirements implied by this goal are the ability to request non-return-of-content, and the ability to specify whether positive delivery notifications, negative delivery notifications, both, or neither, should be issued.
In an attempt to provide such a service, this memo uses the mechanism defined in  to define an extension to the SMTP protocol. Using this mechanism, an SMTP client may request that an SMTP server issue or not issue a Delivery Status Notification (DSN) under certain conditions. The format of a DSN is defined in . section 3 of this memo; (3) no parameters are allowed with this EHLO keyword value; (4) two optional parameters are added to the RCPT command, and two optional parameters are added to the MAIL command: An optional parameter for the RCPT command, using the esmtp-keyword "NOTIFY", (to specify the conditions under which a Delivery Status Notification should be generated), is defined in section 5.1, An optional parameter for the RCPT command, using the esmtp-keyword "ORCPT", (used to convey the "original" (sender-specified) recipient address), is defined in section 5.2, and An optional parameter for the MAIL command, using the esmtp-keyword "RET", (to request that DSNs containing an indication of delivery failure either return the entire contents of a message or only the message headers), is defined in section 5.3, An optional parameter for the MAIL command, using the esmtp-keyword "ENVID", (used to propagate an identifier for this message transmission envelope, which is also known to the sender and will, if present, be returned in any DSNs issued for this transmission), is defined in section 4.4; (5) no additional SMTP verbs are defined by this extension. The remainder of this memo specifies how support for the extension affects the behavior of a message transfer agent.
1]. The ESMTP client may also request (via the RET parameter) whether the entire contents of the original message should be returned (as opposed to just the headers of that message), along with the DSN. In general, an ESMTP server which implements this service extension will propagate Delivery Status Notification requests when relaying mail to other SMTP-based MTAs which also support this extension, and make a "best effort" to ensure that such requests are honored when messages are passed into other environments. In order for Delivery Status Notifications to be meaningful to the sender, ESMTP servers, which support this extension, should propagate the following information for use in generating DSNs to any other MTAs that are used to relay the message: (a) for each recipient, a copy of the original recipient address, as used by the sender of the message. This address need not be the same as the mailbox specified in the RCPT command. For example, if a message was originally addressed to A@B.C and later forwarded to A@D.E, after such forwarding has taken place, the RCPT command will specify a mailbox of A@D.E. However, the original recipient address remains A@B.C.
Also, if the message originated from an environment which does not use Internet-style user@domain addresses, and was gatewayed into SMTP, the original recipient address will preserve the original form of the recipient address. (b) for the entire SMTP transaction, an envelope identification string, which may be used by the sender to associate any delivery status notifications with the transaction used to send the original message. 1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in . NOTE: Although RFC 822 ABNF is used to describe the syntax of these parameters, they are not, in the language of that document, "structured field bodies". Therefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters. The syntax for "esmtp-value" in  does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". "xtext" is formally defined as follows: xtext = *( xchar / hexchar ) xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=". ; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value. hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits When encoding an octet sequence as xtext: + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself. (A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.)
+ ASCII CHARs that fall outside the range above must be encoded as "hexchar". RFC 822: notify-esmtp-value = "NEVER" / 1#notify-list-element notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" Notes: a. Multiple notify-list-elements, separated by commas, MAY appear in a NOTIFY parameter; however, the NEVER keyword MUST appear by itself. b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled in any combination of upper and lower case letters. The meaning of the NOTIFY parameter values is generally as follows: + A NOTIFY parameter value of "NEVER" requests that a DSN not be returned to the sender under any conditions. + A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" keywords requests that a DSN be issued on successful delivery or delivery failure, respectively. + A NOTIFY parameter value containing the keyword "DELAY" indicates the sender's willingness to receive "delayed" DSNs. Delayed DSNs may be issued if delivery of a message has been delayed for an unusual amount of time (as determined by the MTA at which the message is delayed), but the final delivery status (whether successful or failure) cannot be determined. The absence of the DELAY keyword in a NOTIFY parameter requests that a "delayed" DSN NOT be issued under any conditions. The actual rules governing interpretation of the NOTIFY parameter are given in section 6.
For compatibility with SMTP clients that do not use the NOTIFY facility, the absence of a NOTIFY parameter in a RCPT command may be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. 3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document. The entire ORCPT parameter MAY be up to 500 characters in length. When initially submitting a message via SMTP, if the ORCPT parameter is used, it MUST contain the same address as the RCPT TO address (unlike the RCPT TO address, the ORCPT parameter will be encoded as xtext). Likewise, when a mailing list submits a message via SMTP to be distributed to the list subscribers, if ORCPT is used, the ORCPT parameter MUST match the new RCPT TO address of each recipient, not the address specified by the original sender of the message.) The "addr-type" portion of the original-recipient-address is used to indicate the "type" of the address which appears in the ORCPT parameter value. However, the address associated with the ORCPT keyword is NOT constrained to conform to the syntax rules for that "addr-type". Ideally, the "xtext" portion of the original-recipient-address should contain, in encoded form, the same sequence of characters that the sender used to specify the recipient. However, for a message gatewayed from an environment (such as X.400) in which a recipient address is not a simple string of printable characters, the representation of recipient address must be defined by a specification for gatewaying between DSNs and that environment.
Due to limitations in the Delivery Status Notification format, the value of the original recipient address prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII  repertoire. If an addr-type is defined for addresses which use characters outside of this repertoire, the specification for that addr-type MUST define the means of encoding those addresses in printable US-ASCII characters when are then encoded as xtext.
The ABNF for the ENVID parameter is: envid-parameter = "ENVID=" xtext The ENVID esmtp-keyword MUST have an associated esmtp-value. No meaning is assigned by the mail system to the presence or absence of this parameter or to any esmtp-value associated with this parameter; the information is used only by the sender or his user agent. The ENVID parameter MAY be up to 100 characters in length. Due to limitations in the Delivery Status Notification format, the value of the ENVID parameter prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII  repertoire.
RFC 1123, section 2.3.3 requires error notifications to be sent with a NULL return address ("reverse-path"). This creates an interesting situation when a message arrives with one or more
nonfunctional recipient addresses in addition to a nonfunctional return address. When delivery to one of the recipient addresses fails, the MTA will attempt to send a nondelivery notification to the return address, setting the return address on the notification to NULL. When the delivery of this notification fails, the MTA attempting delivery of that notification sees a NULL return address. If that MTA were not to inform anyone of the situation, the original message would be silently lost. Furthermore, a nonfunctional return address is often indicative of a configuration problem in the sender's MTA. Reporting the condition to the local postmaster may help to speed correction of such errors.
If no ORCPT parameter was present in the RCPT command when the message was received, an ORCPT parameter MAY be added to the RCPT command when the message is relayed. If an ORCPT parameter is added by the relaying MTA, it MUST contain the recipient address from the RCPT command used when the message was received by that MTA. 1].
(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a success (2xx) reply-code in response to a RCPT command, the client MUST NOT issue any DSN for that recipient. (f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a permanent failure (5xx) reply-code in response to a RCPT command, the client MUST issue a "failed" DSN for that recipient. 9], POP  or a similar message access protocol, "delivery" occurs when the message is made available to the IMAP (POP, etc.) service, rather than when the message is retrieved by the recipient's user agent. Similarly, for a recipient address which corresponds to a mailing list exploder, "delivery" occurs when the message is made available to that list exploder, even though the list exploder might refuse to deliver that message to the list recipients. (a) If the NOTIFY parameter was supplied for that recipient, with an esmtp-value containing the SUCCESS keyword, the MTA MUST issue a "delivered" DSN for that recipient. (b) If the NOTIFY parameter was supplied for that recipient which did not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for that recipient. (c) If the NOTIFY parameter was not supplied for that recipient, the MTA MUST NOT issue a DSN.
notification thus issued will be translated into a DSN and delivered to the original sender, then the MTA SHOULD gateway the message into the foreign environment, requesting notification under the desired conditions, without itself issuing a DSN. (b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the destination environment cannot return an appropriate notification on successful delivery, the MTA SHOULD issue a "relayed" DSN for that recipient. (c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a DSN MUST NOT be issued. If possible, the MTA SHOULD direct the destination environment to not issue delivery notifications for that recipient. (d) If the NOTIFY parameter was not supplied for a particular recipient, a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD attempt to ensure that appropriate notification will be provided by the foreign mail environment if eventual delivery failure occurs, and that no notification will be issued on successful delivery. (e) When gatewaying a message into a foreign environment, the return-of-content conditions specified by any RET parameter are nonbinding; however, the MTA SHOULD attempt to honor the request using whatever mechanisms exist in the foreign environment.
NOTE: Although delay notifications are common in present-day electronic mail, a conforming MTA is never required to issue "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is provided to allow the SMTP client to specifically request (by omitting the DELAY parameter) that "delayed" DSNs NOT be issued. 11] (section 5.3.6), this document defines the difference between an "alias" and "mailing list" as follows: When forwarding a message to the addresses associated with an "alias", the
envelope return address (e.g., SMTP MAIL FROM) remains intact. However, when forwarding a message to the addresses associated with a "mailing list", the envelope return address is changed to that of the administrator of the mailing list. This causes DSNs and other nondelivery reports resulting from delivery to the list members to be sent to the list administrator rather than the sender of the original message. The DSN processing for aliases and mailing lists is as follows:
characters required by ). If other SMTP extensions are supported by the MTA, the MTA MUST be able to accept a command-line large enough for each SMTP command and any combination of ESMTP parameters which may be used with that command. 3], which uses the framework defined in . Delivery Status Notifications are to be returned to the sender of the original message as outlined below. section 5.3.3 of . The DSN recipient address (in the RCPT command) is copied from the MAIL command which accompanied the message for which the DSN is being issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT be used. The NOTIFY parameter MAY be used, but its value MUST be NEVER. The ENVID parameter (with a newly generated envelope-id) and/or ORCPT parameter MAY be used. 3]). The multipart/report content-type may be used for any of several kinds of reports generated by the mail system. When multipart/report is used to convey a DSN, the report-type parameter of the multipart/report content-type is "delivery-status". As described in , the first component of a multipart/report content-type is a human readable explanation of the report. For a DSN, the second component of the multipart/report is of content-type message/delivery-status (defined in ). The third component of the multipart/report consists of the original message or some portion thereof. When the value of the RET parameter is FULL, the full message SHOULD be returned for any DSN which conveys notification of delivery failure. (However, if the length of the message is greater than some implementation-specified length, the MTA MAY return only the headers even if the RET parameter specified FULL.) If a DSN contains no notifications of delivery failure, the MTA SHOULD return only the headers. The third component must have an appropriate content-type label. Issues concerning selection of the content-type are discussed in .
3] for the message/delivery-status type. When generating a DSN for a message which was received via the SMTP protocol, a conforming MTA will generate the following fields of the message/delivery-status body part: (a) if an ENVID parameter was present on the MAIL command, an Original-Envelope-ID field MUST be supplied, and the value associated with the ENVID parameter must appear in that field. If the message was received via SMTP with no ENVID parameter, the Original-Envelope-ID field MUST NOT be supplied. Since the ENVID parameter is encoded as xtext, but the Original-Envelope-ID header is NOT encoded as xtext, the MTA must decode the xtext encoding when copying the ENVID value to the Original-Envelope-ID field. (b) The Reporting-MTA field MUST be supplied. If Reporting MTA can determine its fully-qualified Internet domain name, the MTA- name-type subfield MUST be "dns", and the field MUST contain the fully-qualified domain name of the Reporting MTA. If the fully-qualified Internet domain name of the Reporting MTA is not known (for example, for an SMTP server which is not directly connected to the Internet), the Reporting-MTA field may contain any string identifying the MTA, however, in this case the MTA- name-type subfield MUST NOT be "dns". A MTA-name-type subfield value of "x-local-hostname" is suggested. (c) Other per-message fields as defined in  MAY be supplied as appropriate. (d) If the ORCPT parameter was provided for this recipient, the Original-Recipient field MUST be supplied, with its value taken from the ORCPT parameter. If no ORCPT parameter was provided for this recipient, the Original-Recipient field MUST NOT appear. (e) The Final-Recipient field MUST be supplied. It MUST contain the recipient address from the message envelope. If the message was received via SMTP, the address-type will be "rfc822". (f) The Action field MUST be supplied.
(g) The Status field MUST be supplied, using a status-code from . If there is no specific code which suitably describes a delivery failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent failure) MUST be used. (h) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Remote-MTA field MUST be supplied for each of those recipients. The mta-name-type subfields of those Remote-MTA fields will be "dns". (i) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients. The diagnostic-type subfield will be "smtp". See section 9.2 of this document for a description of the "smtp" diagnostic-code. (j) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be supplied for each recipient, which contains the address of that recipient which was presented to the remote SMTP server. (k) Other per-recipient fields defined in  MAY appear, as appropriate.
RFC822 mailbox addresses are generally expected to be of the form [route] addr-spec where "route" and "addr-spec" are defined in , and the "domain" portions of both "route" and "addr-spec" are fully- qualified domain names that are registered in the DNS. However, an MTA MUST NOT modify an address obtained from the message envelope to force it to conform to syntax rules. (c) If addresses of this type are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a DSN Original-Recipient or Final-Recipient DSN field. RFC822 addresses consist entirely of graphic characters from the US-ASCII repertoire, so no translation is necessary.
For a single-line SMTP reply to an SMTP command, the diagnostic-code SHOULD be an exact transcription of the reply. For multi-line SMTP replies, it is necessary to insert a SPACE before each line after the first. For example, an SMTP reply of: 550-mailbox unavailable 550 user has moved with no forwarding address could appear as follows in a Diagnostic-Code DSN field: Diagnostic-Code: smtp ; 550-mailbox unavailable 550 user has moved with no forwarding address (c) A list of valid diagnostic codes of this type and the meaning of each code. SMTP reply-codes are currently defined in  and . Additional codes may be defined by other RFCs. 2].
(c) If MTA names of this type do not consist entirely of graphic characters from the US-ASCII repertoire, a specification for how an MTA name of this type should be expressed as a sequence of graphic US-ASCII characters. MTA names of type "dns" consist entirely of graphic US-ASCII characters, so no translation is needed.
RFC 1891, the former two domains have been registered.
- Clarified that ENVID and ORCPT parameters must consist entirely of US-ASCII characters prior to encoding as xtext. - A Security Considerations section was added.  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.  Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.  Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.  Coded Character Set - 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.  Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Westine, A. and J. Postel, "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, March 1991.  Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.  Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.