שגיאת אישור אימייל למשלוח ישיר

תמיכה

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

Users are experiencing issues with the mail-receiver container failing to deliver inbound emails due to an SSL certificate verification error, despite the site’s certificate being valid. Alexander_Wright reports the error occurs when POSTing to Discourse’s email handler, resulting in deferred delivery. JammyDodger suggests rebuilding the mail-receiver container, referencing a meta.discourse.org topic about a Let’s Encrypt root certificate change. Alexander_Wright confirms this resolves the issue. Dannii and Jonathan5 note they also missed the need to rebuild, highlighting the lack of in-app alerts. codinghorror questions where such alerts would originate since email is a separate service, suggesting documentation should emphasize rebuilds. Dannii proposes potential improvements — like logging errors to the forum error log, triggering admin alerts via webhooks, or using localhost for internal communication — though acknowledges these add complexity for rare events like certificate changes. The consensus is that rebuilding the container fixes the issue, but better visibility or automated alerts would help prevent future outages.

1

I’ve been running the excellent mail-receiver container since it was launched.

Recently, I’ve noticed that inbound emails are no longer being received. The error is:

<22>Jan 16 08:05:18 postfix/qmgr[84]: D5E7AE22F1: from=<alexander.wright@camra.org.uk>, size=8238, nrcpt=1 (queue active)
<23>Jan 16 08:05:18 receive-mail[485271]: Recipient: lounge@discourse.camra.org.uk
<19>Jan 16 08:05:18 receive-mail[485271]: Failed to POST the e-mail to https://discourse.camra.org.uk/admin/email/handle_mail: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)
<19>Jan 16 08:05:18 receive-mail[485271]:   /usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `connect_nonblock'
  /usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `ssl_socket_connect'
  /usr/local/lib/ruby/2.3.0/net/http.rb:928:in `connect'
  /usr/local/lib/ruby/2.3.0/net/http.rb:863:in `do_start'
  /usr/local/lib/ruby/2.3.0/net/http.rb:852:in `start'
  /usr/local/lib/ruby/2.3.0/net/http.rb:1384:in `request'
  /usr/local/lib/ruby/site_ruby/mail_receiver/discourse_mail_receiver.rb:42:in `process'
  /usr/local/bin/receive-mail:12:in `<main>'
<22>Jan 16 08:05:18 postfix/pipe[485270]: D5E7AE22F1: to=<lounge@discourse.camra.org.uk>, relay=discourse, delay=1072, delays=1072/0.01/0/0.14, dsn=4.3.0, status=deferred (temporary failure)

The sites certificate is valid, so what’s going on?

Help required, please!

2

Is this any use?

I’m not sure how long your incoming mail has been off for, but maybe a rebuild of the mail-receiver could help either way?

3

That’s the ticket. Apologies, my search skills are clearly not up to scratch this morning.

4

I too missed that a rebuild was necessary. Would’ve been nice if anything in the admin panel had indicated it (other than the lack of received emails). Oh well.

5

Where would this indication come from, I wonder, since email is a totally different service? I think the rebuild has to be in the notes for the email setup and config.

6

Just brainstorming (cause I have no idea how any of the code works):

The container communicates via webhooks, so it should be possible to send things other than emails in through other webhooks.

Could it send all errors into the main forum error log? Or filter them to Ruby errors?

If it can’t send emails for 3 days/a week, could it engage some webhook, which then sends an admin message?

Except in this case of a certificate error, would webhooks not work either? Can it send webhooks over localhost (or a local IP) instead of going out to the internet and back again?

Perhaps when you set up the mail receiver it should request an email address for a failure message to be sent to?

But this all adds complexity for something unlikely to happen, and for unanticipated things like a certificate change.

7

I bet many people are in the same boat. Late last year I spotted Self-hosted mail-receiver update following Let's Encrypt root certificate change but wrongly thought I’d rebuilt the mail-receiver container since that date. It was only this topic that prompted me to check.