Installation process | the Docker way

[ppowalowski]

I noticed the postal runtime is an intransparent mixture of bash-scripts, absolute folder paths and independent containers.
It would be much more appreciated if it was done the regular docker way:

• one docker-compose.yml
• all configurations and volumes define the service, not more not less
• all scripts and binaries inside of docker containers
• Environment variables either defined through the compose file or however the admin likes
• download, run, ready to go

I understand that sometimes it's good to prepare the environment but my simple mind doesn't tell me why anything needs to run specifically on the host to do so.

Desired way:

start: docker compose up
remove: docker compose down
update: docker compose pull && docker compose up -d

Maybe somebody can teach my mind, I am reading the postal script and didn't find any good reason yet.
This seemingly was inspired by the good old mail world which suffers from a strange force that needs to run things on the host itself.

Also I noticed the containers want to run in network_mode: host this is a very strange decision as docker directly opens ports on the host which should also stay the admin decision.

[ppowalowski]

After further screening I came to the conclusion that this bash-script wrapper setup is absolute horror.
Do it the right way.

I am fiddeling around with it for hours now and always translating bash script stuff to proper commands is horrific mindboggle.
Fix it so everybody can use it easily without using the crappy postal bash wrapper. What is this?
Remove the wrapper and list the commands which the stupid wrapper calls in your documentation. Done.

[ppowalowski]

Example:
docker exec {runner-container-name} postal initialize

[ppowalowski]

I am throwing the towel - this is not done the docker way and we do not want to polute our servers with this kind of bash boggle wobble strange wrapper docker compose run wamboozle. Didn't even get it up and running.

Fix it somebody.

[ppowalowski]

Ok, we got it up an running. I have to confirm it would be much better to discard the wrapper scripts and just document the usage with docker exec explanations.

Unfortunately we hit the limit, that relay servers don't support authentication, killing the whole use of postal in our situation.
This urgently should be added especially as the App-internal messages can be sent through an SMTP with authentication support.

[ppowalowski]

Another remark: I noticed that -outgoing mails- cannot be relayed through another SMTP. This is what we would like to have.
Have our services use Postal as main Mail-Gateway which should then either send directly or relay E-Mails to another Smarthost (with authentication). Also for archiving purpose we would like to forward them to another local SMTP.

[MexHigh]

The Postal SMTP server requires authentication by default. That's what the credentials feature is for. So what do you mean?

[ppowalowski]

I was thinking it was possible to relay mails through another SMTP, but actually this is not even a feature so we unfortunately had to drop the idea of postal.

[MexHigh]

Despite the unfriendly tone of @ppowalowski, I second that! I don't see any reason why there is a wrapper script on top of the already user-friendly docker compose commands. It just abstracts the architecture, which is a thing that matters for most self-hosters.

Could you give an explanation about why there was a postal wrapper introduced?

[ppowalowski]

I'd be glad to contribute a change but we are missing the relay feature as stated above. Otherwise I'd have committed a change. Hope more people find this helpful and add a change to improve the deployment procedure to a more straight forward approach 👍🏻

[abhilashtekiestech]

As a self-host, I'm also facing a similar challenge with this postal wrapper, along with the relay feature I have faced challenge in retry mechanism which should be in control of the host rather than heavily integrated with the SMTP gateway. according to me, this tool can provide more value to users if its work is to send the outgoing mail to postal SMTP or other SMTP and based on the response further action can be taken by the user.