“submissions” 서비스(기본 포트 465)를 위한 TCP 연결이 수립되면 즉시 TLS 핸드셰이크가 시작됩니다. 클라이언트는 [RFC7817]에 설명된 인증서 검증 메커니즘을 구현해야 합니다(MUST). TLS 세션이 수립되면, TCP 연결의 나머지 기간 동안 메시지 제출 프로토콜 데이터 [RFC6409]가 TLS 애플리케이션 데이터로 교환됩니다. (참고: “submissions” 서비스 이름은 이 문서의 7.3절에서 정의되며, TLS 없이 사용된 서비스 이름 뒤에 "s"가 붙는다는 Implicit TLS 기반 서비스 이름의 일반적인 관례를 따릅니다.) 포트 465의 상황(7.3절에서 논의됨)으로 인해 포트 587의 STARTTLS 메커니즘은 비교적 널리 배포되어 있습니다. 이는 서버에서 STARTTLS보다 Implicit TLS가 더 널리 배포되는 IMAP 및 POP 서비스와 다릅니다. MUA 소프트웨어가 사용하는 핵심 프로토콜을 일관성뿐만 아니라 부록 A에서 논의된 추가적인 이유들로 인해 시간이 지남에 따라 Implicit TLS로 마이그레이션하는 것이 바람직합니다. 그러나 제출 시 암호화의 사용을 극대화하기 위해, 수년간의 전환 기간 동안 TLS를 통한 메시지 제출에 대해 두 메커니즘 모두를 지원할 수 있도록 하는 것이 바람직합니다. 그 결과, 클라이언트와 서버는 이 전환 기간 동안 포트 587의 STARTTLS와 포트 465의 Implicit TLS를 모두 구현해야 합니다(SHOULD). 구현이 정확하고 클라이언트와 서버 모두 메시지 제출 전에 TLS 협상의 성공을 요구하도록 설정되어 있다면, 포트 587의 STARTTLS와 포트 465의 Implicit TLS 간에는 보안 특성에서 상당한 차이가 없습니다.
참고: Discourse 기본값에서 TLS 관련 기본 설정이 두 가지 있습니다:
# smtp 인증 메커니즘
smtp_authentication = plain
# smtp 연결에 대한 TLS 암호화 활성화
smtp_enable_start_tls = true
# smtp 서버 인증서 검증 모드
# 비활성화하려면 'none'으로 설정
smtp_openssl_verify_mode =
# RFC 8314 3.3에 따라 Implicit TLS 강제
smtp_force_tls = false