When the following is true:
- User attempts to create an account
- Instance has "require registration application" enabled
- Instance's email is not working/unavailable
the application seems to get lost, the user never receives an email (even after email functionality is restored), nor can that email/username be used going forward to re-submit the account creation request.
Additionally, since the user never verifies their email, the instance admin never gets a registration application.
It's not currently an issue for me, however, would it be possible to delete these ghost users? If you lookup the profile/username in the database, you can view it via the web UI, but the only options appear to be either blocking the user or banning them. It might be good to be able to completely delete the accounts, no?
It's because the postfix docker container is not connected to a docker network that has access to the "lemmy" or "lemmy-ui" container, it's being connected to the "default" docker network. I submitted a pull request for it here that should fix it.
To make it work in the meantime:
cd into the Lemmy install directory and run
docker compose downEdit docker-compose.yml in the same directory, and in the postfix section, put this just below the
postfix:line:Run
docker compose up -dThe indentation of that code is very important. Your postfix section should look like this when it's done:
That should connect the "postfix" container in to a docker network that can communicate with the "lemmy" and "lemmy" UI containers. There's another bug in the default config that doesn't assign a hostname to all the containers, but it doesn't always manifest all the time. You can fix that by making sure each service has a hostname assigned to it, like
hostname: lemmy,hostname: lemmy-ui,hostname: postfixetc in the respective service's section of theservice:section of the docker compose file.yep that did the trick.
Heres what I am now using for postfix. This will output logs to ./volumes/postfix/mail.log so its easily parsable as well. May be worth adding it to your PR.
Docker at this depth is a bit new to me. Curious. Why does it need to be bound to the lemmyinternal and lemmyexternalproxy nets, and not just internal?
Because the "lemmyinternal" network is set as an
internaltype network in the Docker compose file, which is exactly what it sounds like: internal-only. Postfix wouldn't have a way to egress to the WAN if not connected to the "lemmyexternal" network, so the initial connection step to send the mail from the "lemmy" container would work, but postfix sending it would fail, as it doesn't have a route out to the Internet.Makes sense. Thanks for the quick explainer (and especially for the tip in the first place.
Just getting logs in a format I’m used to out of docker had me on a bit of a tangent.
You're welcome! Docker/Docker Compose are a great tools once your wrap your brain around them and why containers are ephemeral, etc. Docker's docs could really use improvement though, you never know if what you're looking for is in the section that's dedicated to to that feature, or if the only mention of it is buried deep in the 10th sentence of the 20th paragraph on a completely different page that has absolutely nothing to do with what you're looking for.
I get an error that the network ‘lemmyinternal’ doesn’t exist when making this change in docker-compose.yml - anything I’m missing?
Make sure the
networkssection at the top of your docker compose file looks like this:Thanks! Somehow missed that in the original post - that worked but I am now seeing “email_not_sent” when trying to test forgot password, how can I get to the postfix log to see what the issue is?
Make sure the postfix container is connected to the lemmyexternalproxy network.