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 года IETF выпустила RFC, рекомендующую использование порта 465 для «явного» TLS. Одной из причин этого является растущая тенденция к обязательному шифрованию, что делает STARTTLS несколько избыточным. RFC 8314 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
Появились ли какие-либо обновления? Мой почтовый провайдер также требует, чтобы клиент автоматически устанавливал TLS-соединение при подключении к порту 465.
Как указать Discourse использовать эту опцию?
Если быть точным, в swaks это называется --tlsc
--tlsc, --tls-on-connect
Немедленно инициировать TLS-соединение при подключении. Следуя общепринятой практике, при указании этой опции порт по умолчанию меняется с 25 на 465, хотя его всё ещё можно переопределить с помощью опции --port.
Я думаю, что следующее имеет отношение к делу: в незавершенном PR для Action Mailer в Ruby описывается, как необходимо настроить Action Mailer. В частности, необходимо добавить опции tls и ssl. В Discourse это можно сделать в файле production.rb здесь
PS: Я отправил PR с предлагаемым исправлением, который также можно использовать как временное решение.
Есть ли практические решения для отправки электронной почты через SMTPS на порту 465? Нет, «смените ESP», «используйте submission 587» и подобные советы не являются решением рассматриваемой проблемы 
Практические решения? Нет… это довольно распространённая политика — требовать использования порта 587.
Так в чём же проблема?
Вы имеете в виду на стороне ESP? Конечно, но не на стороне клиента (здесь — сервер Discourse). Я всё ещё проверяю и перепроверяю варианты, поэтому пока рано делать окончательный вывод, что у меня это «просто не работает». Но надеюсь, что здесь никто не пытался принудительно использовать порт 587 на стороне клиента, верно?
Просто хотел обратить на это внимание, поскольку, похоже, это стало распространённым заблуждением: порт 587 — это не «будущее», а невидимый TLS через порт 465.
Меня привела к этому революционная статья.
После прочтения актуального RFC от 2018 года всё становится ясно: дело не в том, что STARTTLS — это путь вперёд, а в том, что SMTPS — это не путь вперёд. Администраторам следует выбирать невидимый TLS через порт 465 (или 587) для будущего.
Поддержка TLS через порт 587 не должна классифицироваться (и, вероятно, должна быть деприоритизирована) как «обеспечение обратной совместимости» или что-то подобное.
Механизм STARTTLS на порту 587 распространён относительно широко из-за ситуации с портом 465 (обсуждается в разделе 7.3). Это отличается от сервисов IMAP и POP, где невидимый TLS развёрнут на серверах более широко, чем STARTTLS. Желательно со временем перейти на использование невидимого TLS для основных протоколов, используемых программным обеспечением MUA, как для обеспечения единообразия, так и по дополнительным причинам, обсуждаемым в Приложении A. Однако для максимального использования шифрования при отправке сообщений желательно поддерживать оба механизма для передачи сообщений через TLS в течение переходного периода в несколько лет. В результате клиенты и серверы ДОЛЖНЫ реализовать как STARTTLS на порту 587, так и невидимый TLS на порту 465 в течение этого переходного периода. Обратите внимание, что если реализации корректны и если как клиент, так и сервер настроены на требование успешного согласования TLS перед отправкой сообщений, то между свойствами безопасности STARTTLS на порту 587 и невидимого TLS на порту 465 нет существенной разницы.
Переход происходит не к submissions через порт 587 с использованием STARTTLS, а к submissions через невидимый TLS на порту 465 (в отличие от SMTPS через порт 465, который теперь устарел).