First registration email return code lost

bug
1

For the first registration email, installed with latest docker image, my SMTP server is responding with:

Unexpected return code 554 (expected 250):
“Access denied: User `arn:aws:iam::[acct]:user/[user]' is not authorized to perform `ses:SendRawEmail' on resource `arn:aws:ses:us-west-1:[acct]:identity/[identity]'”.

However, Discourse log file production.log shows this:

Started PUT "/finish-installation/resend-email" for [ip] at 2020-11-16 20:58:10 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: ...
Completed 200 OK in 23ms (Views: 6.4ms | ActiveRecord: 0.0ms | Allocations: 6023)
...
Delivered mail [randid]@[hostname] (191.3ms)

It seems to me the website, or at least the logs, should return an error, rather than a success message.

Thanks,
Jeff

1 Like
2

Generally emails are sent in a background queue so this is invisible to the user.

I am open though to having the wizard be a bit more fancy and loud about failures, but it is going to have to poll the server to figure this out. It is probably a pretty big change, I am not sure.

2 Likes
3

For the wizard: it’s okay if the wizard doesn’t display the failure. However, it should also not indicate that the email was sent successfully. Something closer to truth would be more helpful. If it’s too difficult to show the return status, it would be better to say, “registration email successfully added to the queue. check /path/to/log for status.”

For the log: The worker thread should log the status, especially when there’s an error. I’m not familiar with the architecture, but I don’t see anything useful in “unicorn.stderr.log” or anywhere else. Something must be gobbling the return code and error message…

1 Like
4

If you are feeling adventurous I would be more than happy to see a PR that improves this

2 Likes
5

Thanks for being open to the change. I’ll add it to my to-do list, but I won’t be offended if someone else gets to it first :slight_smile:

1 Like
6

After admin login, the email errors are visible from the admin console, indicating that they are stored in the database, and could have been accessible via the database before the first admin registration was completed.

The table skipped_email_logs has the info I was looking for.

If you are logged into the discourse container as user discourse, you can run:

psql discourse -c "select * from skipped_email_logs"