Password reset email is not being sent

[piiq]

When I enter an email for password reset in the Kitsu interface I see the following in the logs:

Gunicorn

PUT //auth/reset-password HTTP/1.0" 200 18 "https://{site url}/reset-change-password/{uuid}

Nginx

POST //auth/reset-password HTTP/1.0" 200 32 "https://{site url}/reset-password"

Also I see the information about in the kitsu UI

I conclude that the request for password reset email is made but the system doesn't react to it in any way.

{
name: "Zou",
version: "0.12.9",
database-up: true,
key-value-store-up: true,
event-stream-up: true
}

Is the email supposed to be sent?

P.S. The invitations with the default passwords for new users are being sent out and delivered just fine.

[frankrousseau]

I don't see anything wrong. Maybe that your email provider banned your email.

[piiq]

The strange thing is that the registration emails (invitations) go through ok. Can you advice how to debug this?

[frankrousseau]

Like I said, sometimes email providers, like Mailgun, ban some emails. It seems to be the case here. Your team emails are not blacklisted while yours is. All email providers give you access to some kind of logs. You should look on this side prior to investigating further into Zou.

[piiq]

This has not been resolved for me, but I will close this for now as the problem is not urgent and we found a solution by setting the default password for a user with zou set_default_password user@email

[piiq]

@frankrousseau I've done some debugging on this issue. It appears that if MAIL_DEBUG environment variable is set to anything apart from False it triggers the mail debug mode. The mail debug mode blocks password reset and notification emails from being sent. I was a bit confused by this. In the documentation it says MAIL_DEBUG (default: "0"): set 1 if you are in a development environment (emails are printed in the console instead of being sent). But actually the comparison in zou goes like if current_app.config["MAIL_DEBUG"] this is a bit strange, because if MAIL_DEBUG=0 is specified in the environment variables - condition returns True because MAIL_DEBUG exists and is set to 0 Emails started to go out only after I commented out the MAIL_DEBUG=0 setting in the .env file.

[flinfo]

Just a note that probably doesn't affect your situation but might be helpful to others, is I had install ssmtp and exim4.

[frankrousseau]

The MAIL_DEBUG issue should be fixed. Can you try again?