Part 1 - Service Descriptions
Domain names in the .name TLD may be registered through ICANN-accredited registrars that have Registry-Registrar Agreements ("RRAs") in effect with the Registry Operator and are qualified (hereafter in this Part, "Approved Registrars"), according to the following criteria:
The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.
During their term, domain name registrations will be maintained in the .name Shared Registration System. They will be reported by the .name Whois service, as described in Appendix O. In addition, domain names with registrations including the names and IP addresses (Ipv4) of at least two nameservers will be delegated in the .name TLD zone or a sub-zone, as described in Appendix C, Part 4.
Defensive Registrations in the .name TLD may be made through Approved Registrars, according to the following criteria:
The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.
During their term, Defensive Registrations will be maintained in the .name Shared Registration System. They will be reported by the .name Whois service, as described in Appendix O. A Defensive Registration will not resolve in the DNS. Domain names that would match a Defensive Registration may be registered following the judgement of dispute resolution proceedings or if the Defensive Registration has expired. After such point, the domain name would resolve in the DNS.
Please refer to Appendices G, L and M for more information related to Defensive Registrations.
The NameWatch Service is a monitoring service available through registrars that notifies subscribers to the service when domain names or SLD E-mail addresses are initially registered in the .name registry. When a domain name or an SLD E-mail address registration matches (i.e. is identical to or includes) a watched string, the NameWatch registrant(s) will receive a notice that the registration was made.
Only initial registrations are watched. Renewals, expirations, changes in contact data, changes in nameservers, transfers between registrars or registrants, and other activity are not watched. The domain name or SLD E-mail address registration will not be blocked or otherwise restricted as a result of a match with a Watched String.
The NameWatch Service allows, at the user's option, for the following matches/comparisons between the string on watch and the domain name or SLD E-mail registration:
As an example, if the strings "exampleA", "exampleB" and "ampleB" are registered in the NameWatch service, registration of the domain name exampleA.exampleB.name, will trigger the a notification for all the above mentioned strings, but not for a watch on "exampleC".
The NameWatch service similarly applies to SLD E-mail registrations. As an example, if the strings "exampleA", "exampleB" and "ampleB" are registered in the NameWatch service, registration of the SLD E-mail exampleA@exampleB.name, will trigger the NameWatch service for all the above-mentioned strings, but not for a watch on "exampleC".
Watched strings must consist
entirely of ASCII letters (case insensitive), digits, and hyphens and
may not exceed 63 characters in length. The matching of a watched string
against substrings will only be done on watched strings of at least
three characters. This restriction is to avoid generic entries that
will match enormous, and possibly irrelevant, datasets. Because of this
restriction, watched strings consisting of only one or two characters
will match only identically named domains of one or two characters,
which are permitted only at the third level.
The interface for registering NameWatch strings is implemented in the Registrar section of the .name registry website, rather than through the SRS. This web-site interface is protected through the use of SSL (Secure Socket Layer), and only Registrars will be able to access this part of the Registry Operator system.
The character set used for the information submitted through the website will be governed by the type of browser used. Some browsers specify character set types in the content type tag and can thus be handled by the Registrar Operator. However, input from browsers that do not support this feature will be handled with the default character set of ISO 8859-1.
Through the use of a form in the NameWatch interface new entries can be registered and automatically quality checked by the Registry Operator. The form will collect the information needed to add a NameWatch-monitored string, and the registration will be in effect as soon as the criteria for a valid NameWatch string is met, i.e. the string fulfils the maximum length, minimum length and character set requirements.
Information Requested from the Watcher
The ICANN Accredited Registrars will be the intermediate registration point for the Watcher. (I.e. only registrars may use the NameWatch Interface.)
The following information will be requested from the Watcher registering a string into the NameWatch service:
The Watcher will also be able to choose from a set of reporting schemes including:
The desired frequency of reporting applies to all NameWatch strings added by the Watcher. The Watcher will get a summary of all strings according to the chosen reporting scheme.
Information Returned to the Watcher
Whenever an initial registration is made that matches the criteria set by the Watcher, information will be gathered about the registration and stored in a logfile. This log will be sent to the Registrar through which the Namewatch registration was done, according to the schedule set up for each NameWatch string. The Registrar can then submit this log to the Watcher.
The logfile will consist of one entry per line. The data in the logfile will be given in the reduced character format with semicolon as the field separator.
Reporting will include status for the strings for which there have been no match and the log for strings for which there exist one or more matches.
The report will be an incremental summary of the integration period spanning from the time of the last report to the time of the new report.
For each entry the Watcher has registered, the following will be included:
If matches have been found in the last integration period:
If no matches were located in the last integration period:
For the purpose of this section D, "Corresponding Name Service" shall designate the relationship between the third level domain name and the SLD E-mail service. The Corresponding Name Service of a third level domain name firstname.lastname.name shall thus be the SLD E-mail address firstname.lastname@example.org, and vice versa. Further, "Name" shall cover both SLD E-mail addresses and third level domain names.
The following terminology, specific to the e-mail forwarding service, is used throughout this section:
Multiple mail-exchangers placed in one or more of the Registry Operator's facilities will run this service; these will consist of SMTP mail server software, as specified later in this section, as well as the mail-forwarding server application.
The forwarding application will have access to a local copy of the forwarding database, for the purpose of looking up a user account, and transferring messages from the incoming queue to the outgoing queue, redirected to the forwarding address. A maintenance application is scheduled to run at regular intervals, not to exceed 24 hours, in order to transfer updates and/or an up-to-date copy of the complete forwarding database.
The local copy of the forwarding database shall contain the user's SLD E-mail address as registered with the Registry Operator, and the user-provided forwarding address. No other information about the forwarding user shall be transferred to the mail-exchangers.
The Registry Operator provides a mechanism to register e-mail forwarding information via the SRS interface, as specified in the "SRS interface" section elsewhere in this Appendix. The "SRS interface" section details the specific data required and commands to be used.
As specified in the launch plan, the launch of live registrations for the e-mail forwarding service will occur at the same time as the live SRS interface is launched, and all such registrations will be handled by the live SRS interface. No special provisions are needed to handled e-mail forwarding registrations except for the above mentioned extensions to the SRS interface.
Effect on DNS
E-mails for the forwarded addresses will be sent to one of Registry Operator's mail-exchangers as directed by MX records inserted in the DNS servers for each-second level domain, as referenced in the DNS section in Appendix C, Part 4. This setup will comply with all sections related to mail routing and DNS in RFC 2821, and will be periodically reviewed in order to ensure compliance with updated standards as they become available, to the extent feasible. Changes to DNS MX records will be required only when adding or removing mail-exchangers, and will be handled manually by the operations staff responsible for DNS administration. MX records will be added (or deleted) to reflect the SLDs used by SLD E-mail registrations, as described in Appendix C, Part 4.
A complete copy of the forwarding address database will be distributed to all Registry Operated mail-exchangers at regular intervals, and at least once every 24 hours. This database shall be used by the mail exchangers to determine whether e-mails received have been sent to an existing forwarding user or not.
If the address is valid, the database will be used to determine which address to forward the message to. The distribution of the full forwarding database to each mail-exchanger enables the Registry Operator to increase system stability, as any mail-exchanger in any location can continue providing forwarding service to all forwarding users regardless of the state of the other mail-exchangers.
The mail-exchangers shall comply with RFC 2821 - Simple Mail Transfer Protocol, including the service extension mechanism, and the specific service extensions "8bit-MIMEtransport", as specified in RFC 1652, and "SMTP Command Pipelining," as specified in RFC 2920.
The e-mail forwarding system shall be 8bit clean, but shall not assume that receiving systems are 8bit clean, except as allowed by the service extension defined in RFC 1652, as mentioned above.
This service places no restrictions on the content encoding or character sets used in the headers or body of a mail message, as long as such encodings and character sets comply with internet mail standards, and specifically that the encoding of headers and body follows the requirements set out in RFCs 2822 - Internet Message Format, 2076 - Common Internet Message Headers, and 2045-2049 (MIME).
This includes, but is not limited to, accepting messages using MIME encoding to support alternative character sets and character set encodings for internationalization purposes both in the message header and body.
However, the service shall not actively attempt to reject messages violating the requirements mentioned in the above paragraph, unless such violations result in the system being unable to reliably determine the intended recipient, and/or such violations lead to the message being rejected by the receiving mail system. The Registry Operator shall not be responsible for updating its software in order to prevent the rejection of any messages that violate above-mentioned standards.
Further SMTP Service Extensions will be implemented at the Registry Operator's discretion as the need arises, to ensure proper interoperability with common mail systems and expected client functionality. Further Service Extensions will be documented as and when they are added.
The mail-exchangers shall forward any message which meets with the requirements stated above, except in the cases where such messages exceed size or rate limits defined in the e-mail forwarding service definition (such definition to be provided to ICANN during the implementation process); in the case of messages exceeding those limits, the decision to allow or deny forwarding of such messages is at the Registry Operator's discretion. Such decisions should apply to the entire system, and not be applied to specific users or groups of users (except in the case that multiple service levels at differentiated fees are introduced), and should be enforced without regard for the actual content of such messages.
Registry Operator shall monitor applicable standards development, and seek to adopt updates, security fixes and related changes on an ongoing basis to ensure secure and stable email delivery to the forwarding users.
Unsolicited Commercial Email
To reduce the problem of
Unsolicited Commercial Email (UCE or "spam"), the Registry
Operator shall seek to implement the relevant parts of RFC 2505 - Anti-Spam
Recommendations for SMTP MTAs. Specifically, the Registry Operator's
mail-exchangers will not allow un-authenticated relaying in any form.
Registry Operator reserves the right to implement recommendations in RFC 2505 at its discretion regarding rate control of messages, blocking of specific domains or users, and restrictions to SMTP commands not required for normal operators.
In the case of blocking of users or domains, or rate control targeting specific users or domains, such blocking or rate control shall not be done arbitrarily, and should be the result of documented abuse of the system to send unsolicited commercial e-mail to Registry Operators forwarding users. Commands that may be restricted include, but are not limited to, "VRFY" and "EXPN"", as defined in RFC 2821.
Registry Operator further reserves the right to implement additional anti-spam measures, such as using MAPS RBL, to block UCE or mail from systems with a history of abuse from entering the Registry Operator's mail-forwarding service. However, due to the nature of such systems which actively block messages, Registry Operator shall make public any decision to implement such systems a reasonable time in advance, so as to allow Registrars or Registrants to give feedback on the decision.
In order to facilitate reactions to unsolicited commercial e-mail, or other abuse of the system, the Registry Operator shall publish an e-mail address that can be used by users of the mail-forwarding service and/or third parties that wish to complain about abuse of the forwarding service or the forwarding addresses. Registry Operator reserves the right to cancel forwarding service for users that systematically abuse the system.
Acceptable use policy
An "Acceptable Use Policy" which specifies what constitutes abuse of the email forwarding system shall be made available to the Registrant either from the Registrar that the Registrant registers through, or from the Registry Operator's website. The Registry Operator may update this "Acceptable Use Policy" when required, and will inform Registrars about such updates, making the updated version available to the public.
Unless significant changes are made, the Registry Operator is not required to directly contact Registrant to inform about such changes, and in the event of significant changes, sending e-mail to all registered forwarding addresses shall be considered as proper notice.
Handling of outgoing mail and delivery errors
Messages received by the mail-exchangers addressed to a valid forwarding user will be placed in the outgoing mail queue. Messages will stay in the queue until successfully delivered, until the receiving mail server has rejected the message with a fatal error message (as defined in RFC 2821) that indicate that message can not be delivered, or until a fixed number of days (not fewer than five) have passed. The Registry Operator may at its own discretion implement features to give the originator of the message a warning of delays, but is not required to do so.
In the case that the mail-exchanger is unable to deliver a message within the period, whether due to local or remote errors, or Registrant or Registrar error when registering the forwarding address, an error message will be sent to the originator of the message, stating the technical nature of the error.
Such a message shall at least contain the intended recipient of the message, the subject of the failed message, the date as found in the message headers, whether the error was local or remote, and a readable English text message identifying the type of problem.
The message should also include an e-mail address that can be used in the case that the user has questions about the reasons of failure. Registry Operator does not guarantee individual responses in the case of major failures in the system, and can in such circumstances respond to users by automated messages explaining the nature of the problem.
E-mail communication and mass mailings to forwarding users
Registry Operator is allowed to use the forwarding address to inform the forwarding users about important technical and/or operational issues that may affect the availability of the forwarding service in the case of unavailability or scheduled maintenance. Registry Operator is however not required to do so except as mandated by courts of law or in the case that Registry Operator choose to promise such updates to Registrants.
Registry Operator will not use the forwarding address for sending e-mails of a commercial nature unless permission for such mailings is explicitly granted by Registrant (known as the "opt-in").
The service will be running on multiple servers in multiple locations each holding a complete copy of the forwarding database. This enables the Registry Operator to increase capacity and redundancy when needed, and enables the system to remain fully operational as long as at least one mail-exchanger is operational.
Adding additional mail-exchanger requires only that a copy of the required mail forwarding software be installed, and a copy of the forwarding database be transmitted to the new mail-exchanger, followed by adding the new mail-exchanger in Registry Operator's DNS servers, and can thus be made without disrupting other services provided.
The Registry Operator will create statistics on the number of users on the service, amount of email traffic forwarded and other network statistics for internal operations. As required by courts of law or allowed by Registry Operators Acceptable Use Policy for the email forwarding service, Registry Operator may also make reports documenting usage patterns and log information available to appropriate parties for the purpose of tracing any person or persons using the service for unlawful purposes or in violation of said policy document.
General security measures such as password aging policy, firewalls, IDS and network traffic monitoring systems will be provided for the email forwarding servers by using the facilities already available to the rest of the system. In addition, the email forwarding servers may employ measures outlined in RFC 2505 or elsewhere to limit incoming traffic from systems that threaten the stability or security of the forwarding service by abuse or user error.
Comments concerning the layout, construction and functionality of this site
should be sent to email@example.com.