이것이 흔히 오해되는 부분인 것 같아 짚어주고 싶었습니다. 587 포트가 "미래"를 의미하는 것이 아닙니다. 465 포트에 대한 암시적 TLS(implicit TLS)가 미래를 의미합니다.
저는 이 글을 통해 이 사실을 깨달았습니다.
그리고 2018년에 나온 실제 RFC를 읽어보니 명확해집니다. STARTTLS가 앞으로의 방향이라는 것이 아니라, SMTPS가 앞으로의 방향이 아니며, 관리자들은 앞으로 465 포트(또는 587 포트)에 대한 암시적 TLS를 선택해야 한다는 것입니다.
465 포트에 대한 TLS 지원을 “하위 호환성 유지” 또는 유사한 개념으로 분류(그리고 우선순위를 낮추는)해서는 안 됩니다.
587 포트의 STARTTLS 메커니즘은 465 포트의 상황(7.3절에서 논의됨)으로 인해 상대적으로 널리 배포되어 있습니다. 이는 IMAP 및 POP 서비스와 다르며, 이들 서비스에서는 서버에서 STARTTLS보다 암시적 TLS가 더 널리 배포되어 있습니다. 일관성뿐만 아니라 부록 A에서 논의된 추가적인 이유들을 위해, MUA 소프트웨어가 사용하는 핵심 프로토콜을 점진적으로 암시적 TLS로 마이그레이션하는 것이 바람직합니다. 그러나 제출(submission) 시 암호화 사용을 극대화하기 위해, TLS를 통한 메시지 제출에 대해 여러 년간의 과도기 동안 두 메커니즘 모두를 지원하는 것이 바람직합니다. 그 결과, 클라이언트와 서버는 이 과도기 동안 587 포트의 STARTTLS와 465 포트의 암시적 TLS를 모두 구현해야 합니다(SHOULD). 구현이 정확하고, 클라이언트와 서버 모두 메시지 제출 전에 TLS 협상 성공을 요구하도록 설정되어 있다면, 587 포트의 STARTTLS와 465 포트의 암시적 TLS 간에는 보안 특성에서 큰 차이가 없습니다.
전환의 목표는 STARTTLS를 통한 587 포트의 submissions가 아니라, 465 포트의 암시적 TLS를 통한 submissions입니다(이제 비추천(deprecated)된 465 포트의 SMTPS와 대비되는 개념입니다).