/user/forgot_password says it mailed when it didn't #8731

New Issue

GiteaMirror · 2025-11-02T08:15:45-06:00

GiteaMirror commented

2025-11-02 08:15:45 -06:00

Originally created by @delanym on GitHub (Mar 22, 2022).

Description

When I try reset my password

if no SMTP server is setup, gitea will say the admin has not enabled email so you can't reset your password.
if the SMTP server is setup without TLS, it gives a bullshit message about "A confirmation email has been sent to..."

I had to go to the /admin/config page "SMTP Mailer Configuration" to get the actual issue, as per https://github.com/go-gitea/gitea/issues/7966

Maybe this can be included in https://github.com/go-gitea/gitea/pull/18982

Gitea Version

1.16.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker compose image: gitea/gitea:1

Database

PostgreSQL

Originally created by @delanym on GitHub (Mar 22, 2022). ### Description When I try reset my password - if no SMTP server is setup, gitea will say the admin has not enabled email so you can't reset your password. - if the SMTP server is setup without TLS, it gives a bullshit message about "A confirmation email has been sent to..." I had to go to the /admin/config page "SMTP Mailer Configuration" to get the actual issue, as per https://github.com/go-gitea/gitea/issues/7966 Maybe this can be included in https://github.com/go-gitea/gitea/pull/18982 ### Gitea Version 1.16.4 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Docker compose image: gitea/gitea:1 ### Database PostgreSQL

GiteaMirror added the type/proposal label 2025-11-02 08:15:45 -06:00

GiteaMirror closed this issue

2025-11-02 08:15:45 -06:00

GiteaMirror commented

2025-11-02 08:15:46 -06:00

@zeripath commented on GitHub (Mar 22, 2022):

Emails are sent asynchronously to a queue. It would be highly inappropriate for the user's webpage to be held up waiting for the email to fail to be sent, thus when an email is requested the message says that an email has been sent because it has successfully been placed in a queue.

It's your responsibility as an administrator to check your logs and your configuration.

Now... it actually looks like you've got the same problem as in #7966.

If you'd like to deliberately workaround this TLS stuff:

https://github.com/go-gitea/gitea/issues/7966#issuecomment-633712301

Shows the basics of a PR to do it.

@zeripath commented on GitHub (Mar 22, 2022): Emails are sent asynchronously to a queue. It would be highly inappropriate for the user's webpage to be held up waiting for the email to fail to be sent, thus when an email is requested the message says that an email has been sent because it has successfully been placed in a queue. It's your responsibility as an administrator to check your logs and your configuration. --- Now... it actually looks like you've got the same problem as in #7966. If you'd like to deliberately workaround this TLS stuff: https://github.com/go-gitea/gitea/issues/7966#issuecomment-633712301 Shows the basics of a PR to do it.

GiteaMirror commented

2025-11-02 08:15:46 -06:00

@delanym commented on GitHub (Mar 22, 2022):

Passing the buck from the admin to the users, and then from the devs to the admin.

@delanym commented on GitHub (Mar 22, 2022): Passing the buck from the admin to the users, and then from the devs to the admin.

GiteaMirror commented

2025-11-02 08:15:46 -06:00

@zeripath commented on GitHub (Mar 22, 2022):

Are you deliberately trying to be rude and inflammatory?

I appreciate that you're annoyed and irritated but ... the logs are there, the documentation is there, the basics of a PR have been provided in the past.

An approach of asking nicely if the solution offered in my comment on #7966 could be implemented or even just proposing the PR would be better.

Shall we start again?

I don't think we can change the flash message reported to the user about the email being sent. It's at the wrong level and the mail is sent asynchronously from there.
We're logging the problem and we have a test email button - does that not show the problem?
The underlying issue is described in #7966 - I wrote the basics of a PR that would permit this kind of insecure authentication. Would that have worked for you?

@zeripath commented on GitHub (Mar 22, 2022): Are you deliberately trying to be rude and inflammatory? I appreciate that you're annoyed and irritated but ... the logs are there, the documentation is there, the basics of a PR have been provided in the past. An approach of asking nicely if the solution offered in my comment on #7966 could be implemented or even just proposing the PR would be better. Shall we start again? * I don't think we can change the flash message reported to the user about the email being sent. It's at the wrong level and the mail is sent asynchronously from there. * We're logging the problem and we have a test email button - does that not show the problem? * The underlying issue is described in #7966 - I wrote the basics of a PR that would permit this kind of insecure authentication. Would that have worked for you?

GiteaMirror commented

2025-11-02 08:15:46 -06:00

@delanym commented on GitHub (Mar 22, 2022):

I would prefer secure email, but I dont get to make that decision.
Look, the point is, firstly, don't offer an option if its not an option (insecure mail). And don't mislead by spelling out "A confirmation email has been sent". Can easily reword it to "Your request has been processed" or something similar.

Im not a front-end dev - I don't get why waiting for a confirmation is going to hold up the forgot_password page. All I know is I've worked with countless systems that can do these things without issue.

@delanym commented on GitHub (Mar 22, 2022): I would prefer secure email, but I dont get to make that decision. Look, the point is, firstly, don't offer an option if its not an option (insecure mail). And don't mislead by spelling out "A confirmation email has been sent". Can easily reword it to "Your request has been processed" or something similar. Im not a front-end dev - I don't get why waiting for a confirmation is going to hold up the forgot_password page. All I know is I've worked with countless systems that can do these things without issue.

GiteaMirror commented

2025-11-02 08:15:47 -06:00

@wxiaoguang commented on GitHub (May 9, 2023):

Email system is a async system.

Even if the Email is posted to your MTA (say: SMTP server), there is still a chance that you won't get it.

So, to debug a complex system, keep in mind that every step could fail, and it always needs logs & tests to see what happens.

@wxiaoguang commented on GitHub (May 9, 2023): Email system is a async system. Even if the Email is posted to your MTA (say: SMTP server), there is still a chance that you won't get it. So, to debug a complex system, keep in mind that every step could fail, and it always needs logs & tests to see what happens.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8731