.github/pull_request_template.md

@@ -0,0 +1,36 @@
+# 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,6 +66,11 @@ 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,8 +13,9 @@ function add_config_value() {
  postconf -e "${key} = ${value}"
 }
 
-# Read password from file to avoid unsecure env variables
+# Read password and username 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