Subject: [ietf-smtp] Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 29 Mar 2014 16:36:22 +0000

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 <[email-masked]>

       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 <[email-masked]>

       Author/Change controller: IESG

       References: [draft-melnikov-smime-msa-to-mda-04]] and [RFC6409].

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Mar 2014 21:44:12 +0100

>schemes, but for designating Mail Submission Agents.

Is your registration fully consistent with all those existing implemen-
tations? Is it necessary or beneficial for your particular use case to
use `smtp` or could you also use a different name if there are problems
with other existing uses of the scheme?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Mar 2014 19:12:12 +0000

Alexey Melnikov wrote:
> I am also registering submit:// URI
> scheme, which is a similar URI schemes, but for designating Mail Submission
> Agents.

My understanding from your email and from a glance at
draft-melnikov-smime-msa-to-mda is that the proposed "submit" scheme is
not currently widely deployed, and hence the actual name is flexible.

My feedback is that the name "submit" is not a good name for the proposed use.
Specifically, RFC 4395 states:
>   Avoid using names that are either very general purpose or associated
>   in the community with some other application or protocol.

There are many types of things you can "submit" (HTTP forms, etc.)
and since the proposed use here is specific to specific to SMTP, it should
not use a general purpose word like "submit" along.

"smtpsubmit" or similar would be much more appropriate.

-Dave

---

From: Bill McQuillan <[email-masked]>
Date: Mon, 31 Mar 2014 15:33:43 -0700

> "smtpsubmit" or similar would be much more appropriate.

I hope that whichever keyword is used, it is clearly 
distinguished from "mailto".

I know I'm a bit confused about this proposal. Is "submit"
intended to be a lower abstraction level? Or a replacement?

-- 
Bill McQuillan <[email-masked]>

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Mon, 31 Mar 2014 23:59:57 -0400

At 15:33 -0700 on 03/31/2014, Bill McQuillan wrote about Re: 

>distinguished from "mailto".

Mailto invokes a MUA and supplies the To data and optionally other 
headers such as subject, message body, cc, bcc, etc for a created 
message.

>intended to be a lower abstraction level? Or a replacement?

 From reading the proposal, Submit seems to be a way of supplying the 
SMTP server to be used to inject email into the system (ie: What you 
would enter into a MUA "SMTP Server" Parm). It is a SMTP Server 
dedicated as the Mail Submission Agent role as opposed to the more 
generic MTA role (which is listed in a MX record) which can not only 
the target of a MUA injection connection but also a SMTP Server to 
SMTP Server message forwarding connection. The SMTP type seems to be 
a generic Server of the latter type/function.

>_______________________________________________
>ietf-smtp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-smtp