[Top] [All Lists]

Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF

2020-07-28 06:49:01
Strictly speaking, 8314 does not prefer 465 over 587.  It prefers Implicit TLS over STARTTLS.

The default port for submission over Implicit TLS is 465, but a client and server can use a different port by mutual agreement.

The default port for submission over cleartext (upgradable using STARTTLS if both client and server support it) is 587, but again, a different port can be used by mutual agreement.

8314 prefers Implicit TLS over STARTTLS (because it's harder for an attacker [or middlebox] to hijack a TLS connection that starts at TCP Open than for an attacker to hijack an ordinary TCP connection that is subsequently upgraded to use TLS using STARTTLS).    But either type of connection is permitted and considered secure for user interface purposes as long as the connection otherwise meets minimum confidentiality requirements. One implication is that there's no requirement in 8314 for mail service providers to shift customers to Implicit TLS if they're already using STARTTLS.  (But ideally mail service providers would support Implicit TLS if they're not already doing so.)

But the intention in 8314 was that this choice of Implicit TLS vs. STARTTLS should be made at account configuration time, NOT on a per-session basis.   Unfortunately it now appears to me that the language that should have made this clear was inadvertently removed in a late edit (but still prior to Last Call).


On 7/22/20 8:18 AM, Дилян Палаузов wrote:

> G.6.  Clarify where the protocol stands with respect to submission and TLS issues
> 1.  submission on port 587 or port 465

RFC 8314 says in the Introduction:

“This memo now recommends that:

o Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.”

My reading is thay the above text clarifies to prefer 465 over 587.


На 22 юли 2020 г. 14:49:46 GMT+03:00, Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com> написа:

    Revision of core Email specifications (emailcore) agenda for [virtual]

    WEDNESDAY, July 29, 2020 (UTC)
    11:00-12:40 (1 hour 40 mins)

    Agenda bashing, introduction, meeting format (chairs) -  5 mins
    Problem statement (chairs) -  5 mins

    Review of proposed changes to "Internet Message Format" (RFC 5322)
    draft-resnick-rfc5322bis - 15 mins

       Issue with ABNF for "field":
       Disallow empty quoted string:
       Header field name length limit:

    Triage of raised issues for "Simple Mail Transfer Protocol" (RFC 5321)
    draft-klensin-rfc5321bis - 10 mins

    Example topics (we tackle as many as we have time for)

       G.9.  Revisiting Quoted Strings

       G.7.11.  Bring back 1yz reply codes?

    Core Email Applicability Statement: - 35 mins

       G.6.  Clarify where the protocol stands with respect to submission and
             TLS issues

         1.  submission on port 587 or port 465

         2.  TLS relay on a port different from 25 (whenever)

       Suggested SMTP Extensions:
        G.8.  Enhanced Reply Codes and DSNs
        SMTPUTF8 (a.k.a. EAI)

        G.3.  Meaning of "MTA" and Related Terminology
        G.7.2.  SMTP Model, terminology, and relationship to RFC 5598
        G.11.  SMTP Clients, Servers, Senders, and Receivers

       G.1.  IP Address Literals in EHLO, MAIL or RCPT

       G.7.3.  Resolvable FQDNs and private domain names

       G.10.  Internationalization Consideration section needed?

    High level discussion of how the proposed WG going to decide
    which issues to tackle (chairs) -  5 mins

    Charter Review and discussion (chairs) - 25 mins

    If we go too quickly through triage of some issues, here are some others
    we can discuss:

    G.5.  Remove or deprecate the work-around from code 552 to 452

         The suggestion in Section may have outlived its usefulness
         and/or be inconsistent with current practice.  Should it be removed
         and/or explicitly deprecated?

    G.7.1.  Issues with 521, 554, and 556 codes

         See new Section  More text may be needed, there or
         elsewhere, about choices of codes in response to initial opening and
         to EHLO, especially to deal with selective policy rejections.
    ietf-smtp mailing list

ietf-smtp mailing list
ietf-smtp mailing list