feat: Removed supervisor and rsyslog

As mentioned in discussion #54, since version 3.3.0, postfix can run in
foreground mode, and since 3.4.0 it can log directly to stdout.

.github/pull_request_template.md

@@ -1,36 +0,0 @@
-# Creating a Pull Request
-
-We use github actions to do automatic [semantic versioning](https://github.com/semantic-release/semantic-release), so please use the following nomenclature for the commit message according to the type of change:
-
-* Prefix with `feat:`, and it will trigger a minor version bump. 
-* Prefix with `fix`:, and it will trigger a patch version bump. 
-* Prefix with `BREAKING CHANGE:`, and it will trigger a major version bump.
-
-## Description of the change
-<!--Please be very clear on the intention of the modifications included in the pull request.-->
-<!--If it is a bug, explain what is the issue at hand and how you are fixing it. -->
-<!--If it is an improvement, explain why do you think it is needed and the benefits it brings to the project. -->
-<!--Ideally I would recommend to create an issue first to discuss the new feature with the developers.-->
-
-## Motivation and Context
-<!--- Why is this change required? What problem does it solve? -->
-<!--- If it fixes an open issue, please link to the issue here. -->
-
-## How Has This Been Tested?
-<!--- Please describe in detail how you tested your changes. -->
-<!--- Include details of your testing environment, tests ran to see how -->
-
-## Types of Changes
-<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] Documentation (adding or updating documentation)
-
-## Checklist:
-<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
-<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
-- [ ] My change requires a change to the documentation and I have updated the documentation accordingly.
-- [ ] My change adds a new configuration variable and I have updated the `.env.example` file accordingly.
-
-And lastly, many thanks for taking your time to help us improve this project !

README.md

@@ -66,11 +66,6 @@ The following env variable(s) are optional.
 * `SMTP_PASSWORD_FILE` Setting this to a mounted file containing the password, to avoid passwords in env variables. Used like
     -e SMTP_PASSWORD_FILE=/secrets/smtp_password
     -v $(pwd)/secrets/:/secrets/
-
-* `SMTP_USERNAME_FILE` Setting this to a mounted file containing the username, to avoid usernames in env variables. Used like
-    -e SMTP_USERNAME_FILE=/secrets/smtp_username
-    -v $(pwd)/secrets/:/secrets/
-
 * `ALWAYS_ADD_MISSING_HEADERS` This is related to the [always\_add\_missing\_headers](http://www.postfix.org/postconf.5.html#always_add_missing_headers) Postfix option (default: `no`). If set to `yes`, Postfix will always add missing headers among `From:`, `To:`, `Date:` or `Message-ID:`.
 
 * `OVERWRITE_FROM` This will rewrite the from address overwriting it with the specified address for all email being relayed. Example settings:

run.sh

@@ -13,9 +13,8 @@ function add_config_value() {
  postconf -e "${key} = ${value}"
 }
 
-# Read password and username from file to avoid unsecure env variables
+# Read password from file to avoid unsecure env variables
 if [ -n "${SMTP_PASSWORD_FILE}" ]; then [ -f "${SMTP_PASSWORD_FILE}" ] && read SMTP_PASSWORD < ${SMTP_PASSWORD_FILE} || echo "SMTP_PASSWORD_FILE defined, but file not existing, skipping."; fi
-if [ -n "${SMTP_USERNAME_FILE}" ]; then [ -f "${SMTP_USERNAME_FILE}" ] && read SMTP_USERNAME < ${SMTP_USERNAME_FILE} || echo "SMTP_USERNAME_FILE defined, but file not existing, skipping."; fi
 
 [ -z "${SMTP_SERVER}" ] && echo "SMTP_SERVER is not set" && exit 1
 [ -z "${SERVER_HOSTNAME}" ] && echo "SERVER_HOSTNAME is not set" && exit 1