Hi,
I wanted to use smtp:// URIs in X.509 URI subjectAltName values. My use
case is returning such URIs in S/MIME certificates of S/MIME capable
Mail Transfer Agents (MTAs). My colleague pointed out that smtp:// URIs
are not registered with IANA (despite being used by several products,
including at least one open source), so here is my attempt to register
it. I am also registering submit:// URI scheme, which is a similar URI
schemes, but for designating Mail Submission Agents.
SMTP URI registration
URI scheme name: smtp
Status: permanent
URI scheme syntax:
smtpuri = "smtp://" authority ["/" [ "?" query ]]
authority = <defined in RFC 3986>
query = <defined in RFC 3986>
If :<port> is omitted from authority, the port defaults to 25.
The query component is reserved for future extensions.
URI scheme semantics:
The smtp: URI scheme is used to designate SMTP servers (e.g.
listener endpoints, S/MIME agents performing Domain signing), SMTP
accounts.
There is no MIME type associated with this URI.
Encoding considerations:
SMTP user names are UTF-8 strings and MUST be percent-encoded as
required by the URI specification [RFC3986], Section 2.1.
Applications/protocols that use this URI scheme name:
The smtp: URI is intended to be used by applications that might
need access to an SMTP server (for example email clients or MTAs
can use smtp: URIs in configuration files)
or for SMTP servers to describe their listener endpoints.
A web browser can launch an email client application that can use
the specified smtp: URI for account configuration or for showing
SMTP server capabilities.
These URIs can also be used in LDAP data stores for storing server or
account configuration, as well as in X.509 certificates
containing URIs.
Interoperability considerations:
Several implementations are already using smtp: URIs for server
configuration in configuration files or APIs.
Security considerations: Clients resolving smtp: URIs that wish to
achieve data confidentiality and/or integrity SHOULD use the
STARTTLS command (if supported by the server) before starting
authentication, or use a SASL mechanism, such as GSSAPI, that
provides a confidentiality security layer.
Contact: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
Author/Change controller: IESG
References: [[draft-melnikov-smime-msa-to-mda-04]] and [RFC5321].
SUBMIT URI registration
URI scheme name: submit
Status: permanent
URI scheme syntax:
submituri = "submit://" authority ["/" [ "?" query ]]
authority = <defined in RFC 3986>
query = <defined in RFC 3986>
If :<port> is omitted from authority, the port defaults to 587.
The query component is reserved for future extensions.
URI scheme semantics:
The submit: URI scheme is used to designate SMTP Submission
servers (e.g. listener endpoints, S/MIME agents performing Domain
signing), SMTP accounts.
There is no MIME type associated with this URI.
Encoding considerations:
SMTP user names are UTF-8 strings and MUST be percent-encoded as
required by the URI specification [RFC3986], Section 2.1.
Applications/protocols that use this URI scheme name:
The submit: URI scheme is intended to be used by applications
that might
need access to an SMTP Submission server (for example email
clients) or for SMTP Submission servers to describe their listener
endpoints.
The submit: URI scheme is intended to be used by applications
that might
need access to an SMTP Submission server (for example email clients)
or for SMTP Submission servers to describe their listener endpoints.
A web browser can launch an email client application that can use
the specified submit: URI for account configuration or for showing
SMTP server capabilities.
These URIs can also be used in LDAP data stores for storing server or
account configuration, as well as in X.509 certificates
containing URIs.
Interoperability considerations:
None.
Security considerations: Clients resolving submit: URIs that wish
to achieve data confidentiality and/or integrity SHOULD use the
STARTTLS command (if supported by the server) before starting
authentication, or use a SASL mechanism, such as GSSAPI, that
provides a confidentiality security layer.
Contact: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
Author/Change controller: IESG
References: [draft-melnikov-smime-msa-to-mda-04]] and [RFC6409].
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp