포트 465에 관해서는 RFC 8314를 참고하십시오.
이 RFC에 따르면, SMTP 메일 제출 에이전트(MSA)에 대해 포트 465와 587 모두 유효한 포트입니다.
포트 465는 연결 설정 시 TLS/SSL 협상이 필요하며, 포트 587은 TLS 협상을 선택하는 경우 STARTTLS를 사용합니다.
IANA 레지스트리는 이 목적을 위해 포트 465의 정당한 사용을 허용하도록 업데이트되었습니다.
SMTP 메일 릴레이의 경우 포트 25만 사용되므로, 메일 릴레이에서 TLS를 사용하는 유일한 방법은 STARTTLS입니다.
@kyekiller 님, 포트 465를 사용하실 경우 이 설정을(false로) 설정해 보시는 것을 고려해 보십시오:
DISCOURSE_SMTP_ENABLE_START_TLS: false
주석 처리를 해도 큰 도움이 되지 않을 가능성이 높습니다. Discourse 컨테이너 파일에서 이 설정의 기본값이 true로 설정되어 있기 때문입니다. 따라서 이 줄을 주석 처리해도 여전히 true로 설정됩니다:
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (선택 사항, 기본값 true)
도움이 되길 바랍니다.
다음도 참고하십시오 (RFC 발췌):
“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
다음도 참고하십시오: