Registration mails and password reset mails not being sent with version 1.11.1

[Ibmurai]

• Gitea version (or commit ref): 1.11.1
• Git version: 2.22.2
• Operating system: Alpine/Docker/Ubuntu 18.04
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

When a user requests a password reset link or registers an account the email is never sent.
I have confirmed on our email system that the mails are never sent.
I have tested with 1.10.3 and 1.10.4 (which I use in production now), and the emails are sent when using those versions.
I use sendmail, if that matters. :)
Sending a test email from the Configuration page works.
...

Screenshots

[guillep2k]

Sorry for the dumb question. Have you checked that the following is set in you app.ini?:

[service]
REGISTER_EMAIL_CONFIRM            = true

(Cuould you please post the relevant entries in your config, properly sanitized?)

[Ibmurai]

Here is my complete, aggressively sanitized, app.ini :)

APP_NAME = *******
RUN_MODE = prod

[repository]
ROOT = /data/git/repositories

[repository.local]
LOCAL_COPY_PATH = /data/gitea/tmp/local-repo

[repository.upload]
TEMP_PATH = /data/gitea/uploads

[server]
APP_DATA_PATH    = /data/gitea
SSH_DOMAIN       = *******
HTTP_PORT        = 3000
ROOT_URL         = *******
DISABLE_SSH      = false
START_SSH_SERVER = true
SSH_PORT         = 22
SSH_LISTEN_PORT  = 2222
LANDING_PAGE = login

[database]
PATH    = /data/gitea/gitea.db
DB_TYPE = mysql
HOST    = db:3306
NAME    = *******
USER    = *******
PASSWD  = *******

[indexer]
ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve

[session]
PROVIDER_CONFIG = /data/gitea/sessions
COOKIE_NAME = *******

[picture]
AVATAR_UPLOAD_PATH            = /data/gitea/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars

[attachment]
ENABLED = false

[log]
ROOT_PATH = /data/gitea/log

[security]
INSTALL_LOCK   = true
SECRET_KEY     = *******
INTERNAL_TOKEN = *******
LOGIN_REMEMBER_DAYS = 7
COOKIE_USERNAME = *******
COOKIE_REMEMBER_NAME = *******
PASSWORD_COMPLEXITY = lower

[service]
DISABLE_REGISTRATION = false
REQUIRE_SIGNIN_VIEW  = true
ENABLE_NOTIFY_MAIL = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
DEFAULT_ENABLE_DEPENDENCIES = false
ALLOW_CROSS_REPOSITORY_DEPENDENCIES = false
AUTO_WATCH_NEW_REPOS = false
DEFAULT_ORG_VISIBILITY = private
NO_REPLY_ADDRESS = *******
DEFAULT_ALLOW_CREATE_ORGANIZATION = false
DEFAULT_ENABLE_DEPENDENCIES = false
ALLOW_CROSS_REPOSITORY_DEPENDENCIES = false
ENABLE_TIMETRACKING = false
DEFAULT_ENABLE_TIMETRACKING = false
REGISTER_EMAIL_CONFIRM = true
EMAIL_DOMAIN_WHITELIST = *******

[oauth2]
JWT_SECRET = *******

[mailer]
ENABLED        = true
MAILER_TYPE    = sendmail
FROM           = *******
SENDMAIL_PATH  = /usr/bin/msmtp

[indexer]
REPO_INDEXER_ENABLED = true

[git]
VERBOSE_PUSH = false

[time]
DEFAULT_UI_LOCATION = *******

[webhook]
SKIP_TLS_VERIFY = true

[guillep2k]

Can you check whether your mailer supports the following syntax?

/usr/bin/msmtp -f from@you.addr -i to@their.addr

or rather?

/usr/bin/msmtp -F from@you.addr -i to@their.addr

There's been a change regarding this parameter, recently (#9961)

[Ibmurai]

It works with -f but not with -F.

[guillep2k]

This could be a setup problem, even if you've had some degree of success in your tests. Please try the following from the command line:

echo -e "Subject: HELLO!\n\nBody." |
/usr/bin/msmtp -F from@you.addr -i to@their.addr

But this time make sure that:

1. If possible, try sudoing into Gitea's identity to run the command (in my case, the username is git): sudo su git.
2. to@their.addr is an address outside your organization (e.g. GMail) or at least one of the addresses that failed for you.
3. from@you.addr is the address set up in the FROM setting.

It often happens that mailers can send mails to servers in their vecinity, but not to the rest of the internet. Also, depending on your recipient's configuration, your server could also be blacklisted.

Finally, it would be useful if you could check logs and/or set up some debug on your msmtp configuration.

Given that Gitea is sending the test mail correctly, I doubt this is a problem from Gitea itself. I've specifically tested with 1.11.1 (albeit my system's got sendmail instead of msmtp) and I had no problems whatsoever.

[zeripath]

It's likely the issue with the workerpool lock up - try switching off 1.11.1 to release/v1.11 we'll have 1.11.2 out very soon

[Ibmurai]

It's likely the issue with the workerpool lock up - try switching off 1.11.1 to release/v1.11 we'll have 1.11.2 out very soon

Sounds great!
I'll try to test with release/v1.11 on monday.

@guillep2k But msmpt and it's configuration is untouched when I switch between 1.10.4 and 1.11.1 and with 1.10.4 it just works...

[guillep2k]

@guillep2k But msmpt and it's configuration is untouched when I switch between 1.10.4 and 1.11.1 and with 1.10.4 it just works...

Sorry, it just wasn't clear to me if the tests were being done with the same or different servers. I didn't want to assume. 😄

Hopefully, 1.11.2 will get you working!

[zeripath]

If you are unable to rebuild from release/v1.11 or move to master. If you set in app.ini:

[queue]
BLOCK_TIMEOUT=0

That should avoid the problem with the worker pool.

[Ibmurai]

I can confirm that the problem is gone with 1.11.3 and 1.11.4 :)