The discussion revolves around the use of SMTPS port 465 for sending emails with Discourse. The original poster, manishramteke, is experiencing issues with sending emails using port 465, despite it working with their email client. mpalmer suggests that the issue might be with the mail provider or server configuration, and recommends using port 25 or 587 with STARTTLS instead.
However, vados points out that implicit TLS over port 465 is actually the recommended approach, citing an RFC from 2018. djr013 also mentions this RFC, which recommends using port 465 for implicit TLS.
Godmar_Back asks how to configure Discourse to use implicit TLS on port 465, and shares a proposed fix in a pull request. silverdr is looking for practical solutions to send emails over SMTPS on port 465.
The discussion highlights the importance of understanding the differences between SMTPS, STARTTLS, and implicit TLS, and the need for Discourse to support implicit TLS on port 465.
Hi Team,
Using email service from godaddy and smtp ssl port 465 in config, but sending mail fails with
Job exception: end of file reached.
For me 465 works with email client such as thunderbird. What can be done to make email work with discourse on port 465.
Running SMTP on other port such as 3535 works well. If I go with non secure port will security of my email contents and credentials get compromised?
Regards
Manish
This sounds like a problem with your mail provider or the server running Discourse (such as a firewall issue). It is not a problem with Discourse itself.
Also note that port 465 hasn’t been for SMTPS for so long that the IETF has removed its registration as a well-known port. You should use port 25 or 587 with STARTTLS.
Hi Matt,
I am able to telnet port 465 from discourse server and no firewall is configured for now.
Email providers still supports 465 for secure connection for client which does not support STARTTLS. However that’s not the case here, so I can move to port 25 with STARTTLS on.
Regards
Manish
Sad to here this.
My email service provider does not support for port 587.
Your ESP needs to be dragged, kicking and screaming, into the 21st century.
I have been googling for this, to see if I should use port 465 or not.
Can you confirm as of 2018, if the recommended and safe settings is to use port 587 with STARTTLS (DISCOURSE_SMTP_ENABLE_START_TLS env for dockers) ?
Sendgrid still offers port 465 “for SSL connections” as they say. I was thinking in using it.
Sendgrid use 587 too. Use 587 with starttls. TLS is effectively the successor to SSL.
2018년 1월 IETF RFC 문서에서는 “암시적(implicit)” TLS 사용을 위해 포트 465의 사용을 권장하고 있습니다. 이 권장 사항의 배경은 필수 암호화 사용이 증가하는 추세로 인해 STARTTLS가 다소 중복되는 요소를 갖게 되었기 때문입니다. RFC 8314 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
업데이트가 있나요? 제 이메일 제공업체도 포트 465에서 연결 시 클라이언트가 자동으로 TLS 연결을 수립하도록 요구합니다.
Discourse에 이 옵션을 사용하도록 설정하는 방법은 무엇인가요?
정확히 말하면, [swaks](https://linux.die.net/man/1/swaks)에서는 이를 --tlsc라고 부릅니다.
--tlsc, --tls-on-connect
연결 시 즉시 TLS 연결을 시작합니다. 일반적인 관례에 따라 이 옵션이 지정되면 기본 포트가 25에서 465로 변경되지만, --port 옵션으로 여전히 덮어쓸 수 있습니다.
포트 465에서 SMTPS를 통해 이메일을 보내는 데 대한 실질적인 해결책이 있을까요? 아니요, “ESP를 변경하세요”, “587 포트의 submission을 사용하세요” 같은 것들은 해당 문제에 대한 해결책이 아닙니다 
실용적인 해결책? 아니요… 587 포트를 사용하도록 강제하는 것은 꽤 흔한 정책입니다.
그렇다면 문제점은 무엇일까요?
ESP 쪽에서 말하는 건가요? 네, 맞습니다. 하지만 클라이언트(여기서는 Discourse 서버) 쪽에서는 아닙니다. 아직까지도 옵션들을 계속 확인하고 재확인 중이라, 제 경우엔 "그냥 안 된다"고 단정할 수는 없는 상태입니다. 다만, 여기서 클라이언트 쪽에서 587 포트를 강제 적용해 보신 분은 없으시죠?
이것이 흔히 오해되는 부분인 것 같아 짚어주고 싶었습니다. 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와 대비되는 개념입니다).