Sending email failed with SMTPS 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.

「いいね!」 4

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.

「いいね!」 2

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

「いいね!」 1

Have there been any updates? My email provider also requires that the client automatically establish a TLS connection on connect on port 465.

How do I tell Discourse to use this option?

To be precise, in [swaks](https://linux.die.net/man/1/swaks) this is called --tlsc

--tlsc, --tls-on-connect
Initiate a TLS connection immediately on connection. Following common convention, if this option is specified the default port changes from 25 to 465, though this can still be overridden with the --port option.

I think the following is related: a never completed PR for Ruby’s action mailer describes how the action mailer needs to be configured. Specifically, the options tls and ssl need to be added. In Discourse, this could be in production.rb here

PS: I submitted a PR with a proposed fix which can also be used as a work-around

「いいね!」 2

ポート465でのSMTPSによる電子メール送信に関する実用的な解決策はありますか?いいえ、「ESPを変更する」、「サブミッション587を使用する」などは、問題の解決策ではありません :wink:

実用的な解決策ですか?いいえ… 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 は現在非推奨) への移行です。

「いいね!」 4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.