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.
There’s a January 2018 IETF RFC which recommends use of port 465 for “implicit” TLS. A motivation for this is the increasing trend for mandatory encryption, which renders STARTTLS somewhat redundant. 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` オプションで上書きすることは可能です。
以下の内容が関連していると思います：Ruby の Action Mailer に関する 完了しなかった PR では、Action Mailer の設定方法について説明されています。具体的には、tls および ssl オプションを追加する必要があります。Discourse では、これは ここ の production.rb に設定できます。
PS: 暫定的な回避策としても利用可能な 修正案の PR を提出しました。
ポート465でのSMTPSによる電子メール送信に関する実用的な解決策はありますか？いいえ、「ESPを変更する」、「サブミッション587を使用する」などは、問題の解決策ではありません 
実用的な解決策ですか？いいえ… 587の使用を強制するのが一般的なポリシーです。
それで、問題は何ですか？
ESP側ということですか？はい、可能ですが、クライアント側（ここではDiscourseサーバー）では不可能です。まだオプションをチェックし直しているので、「単に動作しない」と断定するには至っていませんが、クライアント側で587を強制しようとした人はいないことを願っていますよね？
これは一般的な誤解になっているようなので指摘しておきたいのですが、587 は「未来」ではなく、465 での暗黙的 TLS が「未来」なのです。
そして、2018年の実際のRFCを読むと、STARTTLS が前進ではなく、SMTPS が前進ではなく、ポート 465 (または 587) での暗黙的 TLS が管理者が今後選択すべきものであることが明らかです。
ポート 465 での TLS のサポートは、「後方互換性の維持」やそれに類する考え方として分類されるべきではありません（そして、おそらく優先順位を下げるべきではありません）。
ポート 587 での STARTTLS メカニズムは、ポート 465 の状況（セクション 7.3 で議論）により、比較的広く展開されています。これは、IMAP および POP サービスとは異なり、サーバーでは STARTTLS よりも暗黙的 TLS が広く展開されています。MUA ソフトウェアで使用されるコアプロトコルを、一貫性のため、および付録 A で議論されている追加の理由のために、時間の経過とともに暗黙的 TLS に移行することが望ましいです。しかし、暗号化の送信における利用を最大化するために、移行期間中は、TLS を使用したメッセージ送信のために、STARTTLS をポート 587 で、暗黙的 TLS をポート 465 でサポートすることが望ましいです。その結果、クライアントとサーバーは、この移行期間中は、ポート 587 での STARTTLS とポート 465 での暗黙的 TLS の両方を実装すべきです。 STARTTLS をポート 587 で、暗黙的 TLS をポート 465 で使用する場合、実装が正しく、クライアントとサーバーの両方がメッセージ送信前に TLS の正常なネゴシエーションを要求するように構成されていれば、セキュリティプロパティに実質的な違いはありません。
移行は、STARTTLS を介した 587 での submissions ではなく、ポート 465 での暗黙的 TLS を介した submissions (ポート 465 での SMTPS は現在非推奨) への移行です。