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).
Keith
On 7/22/20 8:18 AM, Дилян Палаузов wrote:
Hello,
> 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.
Greetings
Дилян
На 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]
Madrid.
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":https://www.rfc-editor.org/errata/eid2950
Disallow empty quoted string:https://www.rfc-editor.org/errata/eid3135
Header field name length limit:https://www.rfc-editor.org/errata/eid5918
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
8BITMIME
SMTPUTF8 (a.k.a. EAI)
Terminology:
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
Documents:
https://datatracker.ietf.org/doc/draft-resnick-rfc5322bis/?include_text=1
https://www.rfc-editor.org/errata_search.php?rfc=5322&rec_status=15&presentation=table
https://datatracker.ietf.org/doc/draft-klensin-rfc5321bis/?include_text=1
https://www.rfc-editor.org/errata_search.php?rfc=5321&rec_status=15&presentation=table
https://datatracker.ietf.org/doc/draft-klensin-email-core-as/?include_text=1
------------------------------------------------------------------------
If we go too quickly through triage of some issues, here are some others
that
we can discuss:
G.5. Remove or deprecate the work-around from code 552 to 452
The suggestion in Section 4.5.3.1.10 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 4.2.4.2. 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp