Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)
Extracted elements (24)
EPP predates internationalized email address specifications, so it has no native support for SMTPUTF8 addresses. This extension adds a second email slot to the contact object rather than modifying the base contact mapping, preserving backward compatibility.
The second email address can serve two roles: an alternate ASCII-only fallback when the primary SMTPUTF8 address has delivery issues, or an SMTPUTF8 contact address where the base ASCII address is the fallback. The 'primary' attribute on <addlEmail:email> signals which role applies.
This extension does not update or change any other EPP extension that includes an email address. Adding SMTPUTF8 support to other EPP extensions requires separate updates to those specifications.
When a contact object contains two email addresses, all users should be aware that either address may forward to the other — a message sent to an ASCII-only address may receive a reply from an SMTPUTF8 address and vice versa.
An extended contact object MUST NOT be provided or returned by either an EPP client or an EPP server when support for this extension has not been successfully negotiated at the start of an EPP session.
If both client and server have indicated support for SMTPUTF8 addresses during session establishment, they MUST be able to process an SMTPUTF8 address in any extended contact object during the established EPP session.
Implementations MUST NOT depend on the 'addlEmail' XML namespace prefix and instead MUST employ a proper namespace-aware XML parser and serializer to interpret and output XML documents.
The <contact:disclose><contact:email/> 'flag' attribute value MUST also be applied to all additional email addresses added by a contact extension, ensuring consistent disclosure behavior.
The EPP <create> command MUST contain a child <addlEmail:addlEmail> element for the client to set an alternate email address when this extension is in use.
The EPP <update> command MUST contain a child <addlEmail:addlEmail> element for the client to set or unset an alternate email address. If the alternate email address cannot be applied to the object, the server MUST return EPP error result code 2201.
The 'primary' attribute MUST NOT be present if the <addlEmail:email> element is empty.
The validation rules described in RFC 6531 MUST be followed when processing internationalized email addresses associated with this extension, covering Mailbox, Local-part, and Domain ABNF extended for UTF8-non-ascii and U-label.
When the extension is negotiated, the client MUST: provide SMTPUTF8-compliant addresses in requests, accept SMTPUTF8-compliant addresses in responses, and support the RFC 6531 SMTP extension when sending or receiving email.
When the extension is negotiated, the server MUST: accept SMTPUTF8-compliant addresses, validate them per RFC 6531, store internationalized characters, return SMTPUTF8-compliant addresses in responses, and support the RFC 6531 SMTP extension when sending or receiving email.
The content of <addlEmail:email> elements must be processed in the same way as <contact:email> elements, including potential publication in RDAP directory services. Many data protection regulations classify email addresses as personal data, so all policies governing collection, transmission, and processing of contact information MUST apply equally to additional email addresses.
Extension support is signaled by including the namespace URI 'urn:ietf:params:xml:ns:epp:addlEmail-1.0' in the client's <svcExtension><extURI> in the <login> command and in the server's greeting, per EPP session negotiation (RFC 5730 Section 2.4).
The <addlEmail:addlEmail> element is the top-level extension element, containing a single <addlEmail:email> child that holds either an ASCII or SMTPUTF8 address. An empty <addlEmail:email/> unsets the second address in an update or indicates no second address in an info response.
The <addlEmail:email> element carries an OPTIONAL boolean 'primary' attribute (default false). When true, it indicates the extension email should be treated as the primary contact address. The 'primary' attribute MUST NOT be present when the element is empty.
IANA registered the XML namespace URI 'urn:ietf:params:xml:ns:epp:addlEmail-1.0' and the XML Schema URI 'urn:ietf:params:xml:schema:epp:addlEmail-1.0' in the IETF XML Registry (RFC 3688), with IESG as registrant contact.
The extension was registered in the IANA 'Extensions for the Extensible Provisioning Protocol (EPP)' registry (RFC 7451) as 'Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)', Standards Track, applicable to any TLD, status Active.
Invalid domain names in email addresses enable homograph attacks: a malicious actor can register a visually similar U-label domain and use social engineering to assume control of the contact's domain. Registries SHOULD validate domain name syntax in email addresses and check code points against the IANA 'IDNA Rules and Derived Property Values' registry.
The syntax for internationalized email local-parts is very liberal and domains are normalized during MX lookup while local-parts are unconstrained. Implementers should test that their database can store difficult local-parts such as U+0061 U+0300 U+00E0 (see RFC 5198 for normalization context).
Unconstrained Unicode in SMTPUTF8 email addresses introduces security threats not present with ASCII-only addresses (as noted in RFC 6530). Because EPP email addresses appear in RDAP and are often copy-pasted during domain transfers, policies SHOULD disallow unconstrained Unicode; the domain-part SHOULD conform to IDNA2008 and the local-part SHOULD be restricted to non-threatening Unicode, e.g., limited to Unicode Annex 31 characters.
The XML Schema for the extension defines namespace 'urn:ietf:params:xml:ns:epp:addlEmail-1.0'. The addlEmailType is a sequence containing one emailType element; emailType extends xs:token with an optional boolean 'primary' attribute (default false). The empty element value unsets the address.