Configure QQ Mail sending, email arrives normally, but Discourse reports errors and sends duplicates

סיכום מבוסס בינה מלאכותית

A user reports issues with configuring QQ Mail for sending emails in Discourse, where emails are successfully delivered but Discourse repeatedly sends them and shows errors. The user’s configuration includes SMTP settings for smtp.qq.com with port 587, and the problem occurs during user registration and test emails. Logs show an SMTP Error Net::SMTPUnknownError with unclear messages. The user shares error logs and a doctor report, and others confirm similar issues with QQ Mail, suggesting it’s a known problem. A developer acknowledges the issue and notes a fix has been merged to improve error messages. Another user confirms that using Mailgun resolves the issue, and a developer notes that QQ Mail is a recurring source of problems. The consensus is that the issue is likely due to QQ Mail’s behavior rather than Discourse configuration.

The installation tutorial I initially followed:

My settings:

  DISCOURSE_DEVELOPER_EMAILS: 'xxx@gmail.com'

  ## TODO: Configure the mail server
  ##       (used for validation of new accounts, notifications, digests, etc.)
  ## required: hostname of the SMTP mail server used to send mail
  DISCOURSE_SMTP_ADDRESS: smtp.qq.com
  ## uncomment to set the port to something other than the default (25)
  DISCOURSE_SMTP_PORT: 587
  ## USER_NAME / PASSWORD required if the SMTP provider needs authentication
  ## WARNING: a '#' in the SMTP password can be misinterpreted; ensure it's inside string quotes, e.g.:
  ##   DISCOURSE_SMTP_PASSWORD: "#pass#ord"
  DISCOURSE_SMTP_USER_NAME: xxx@qq.com
  DISCOURSE_SMTP_PASSWORD: "xxx"
  ## uncomment to enable implicit TLS at connection time, probably needed for using port 465
  #DISCOURSE_SMTP_FORCE_TLS: true
  ## uncomment to set the HELO/EHLO domain, only set if required by provider
  #DISCOURSE_SMTP_DOMAIN: discourse.example.com
  ## the address from which notifications are sent
  DISCOURSE_NOTIFICATION_EMAIL: xxx@qq.com
  ## uncomment to change server certificate verification
  #DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: peer # peer|none
  ## uncomment to override the authentication method
  DISCOURSE_SMTP_AUTHENTICATION: login # plain|login|cram_md5

Situation 1:

When trying user registration, Discourse repeatedly sends emails.


I had to manually terminate the retry job in sidekiq.

Situation 2:

I tried using the internal test email.
An error prompt appears after clicking send.
However, when I check my mailbox, the email successfully arrived.

If someone can help me solve this puzzle, I will continue to use QQ Mail, otherwise I will have to try changing the email provider.

Are there errors in yourforum.com/logs?

You problem reminds me of 我搭建了discourse,激活了账户邮箱,为什么还是每隔一会儿不断发送激活账户信息的邮件??怎么配置解决这个bug - #23 by supermathie and Duplicate registration email issue

Thank you for the reply. The two examples you provided are almost identical to my situation. I have carefully reviewed the relevant content, but I still cannot figure out how to solve it.

There are indeed errors in the logs.


howdy, sorry about that. I am working on fixing this to provide actual error messages. I will reply here when merged.

howdy again, the PR has been merged. once you have the updated code, please let me know if you are still not seeing a human readable error message.

This is the record of me running doctor
https://mathcollapse.20000816.xyz/ZWM4MzAzZjUzZDZjMGU1.txt

This is the error log after the update

Message (2 copies reported)

SMTP Error Net::SMTPUnknownError with message: 
 response: 


Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:218:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `map'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:129:in `error'
/var/www/discourse/lib/email/sender.rb:308:in `rescue in send'
/var/www/discourse/lib/email/sender.rb:295:in `send'
/var/www/discourse/lib/tasks/emails.rake:230:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:279:in `block in execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:279:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:279:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:199:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:199:in `invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/task.rb:188:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:188:in `invoke_task'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:138:in `block in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:138:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:138:in `block in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:147:in `run_with_threads'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:132:in `top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:83:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:214:in `standard_exception_handling'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.1/lib/rake/application.rb:80:in `run'
bin/rake:13:in `<top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in `load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in `kernel_load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:23:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:452:in `exec'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor.rb:538:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:35:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:29:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:28:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:20:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'

Thank you for your help, but I still cannot resolve the QQ mailbox issue, so I had to switch to a Gmail account, and now it is completely normal.

QQ Mail doesn’t work, I’m having the same issue. Using Mailgun can solve the problem.

huh, dang, sorry about that not giving a better error but glad to hear you got it working regardless. I have opened an internal topic to investigate further and maybe update some docs to warn about this, but it seems to be a recurring issue with QQ Mail specifically. there have been multiple reports of QQ Mail causing this same issue over the years.

It seems this is a common problem with QQ Mail! It’s not a Discourse setting issue.