Repository navigation
Helm chart opendkim - #30
Conversation
…s and console configuration
…ng and configuration
… scripts for streamlined deployment Co-authored-by: Copilot <copilot@github.com>
- Introduced `02-sample-resources.sh` to automate the creation of a SPA resource. - The script sources common functions and loads environment variables from a `.env` file. - It defines default parameters for the SPA and includes functions to extract JSON values, get organization unit IDs, and fetch flow IDs. - Implements the `create_spa_application` function to handle the API call for creating the SPA with necessary configurations. - Logs success or error messages based on the API response.
…rement Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
…aven config script for OAUTHBEARER support Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request transitions the API server to an HTTPS-only configuration and implements SMTP XOAUTH2 authentication by passing through the Bearer token from the request. Key changes include adding support for multiple recipients in the /notify endpoint, removing the smtp_password requirement, and introducing a Helm chart for OpenDKIM along with bootstrap scripts for the Thunder service. Feedback identifies a high-severity issue where global template_data overrides recipient-specific context, preventing the use of per-recipient variables in custom templates. Additionally, it is recommended to use the provided smtp_username as the XOAUTH2 identity instead of the sender email to improve compatibility with different SMTP providers.
| templateData := any(recipient) | ||
| if len(req.TemplateData) > 0 { | ||
| templateData = req.TemplateData | ||
| } |
There was a problem hiding this comment.
When TemplateData is provided in the request, it completely overrides the per-recipient context (recipient) for the template execution. This means that in a multi-recipient notification, custom templates cannot access recipient-specific fields like {{.Name}} if global template_data is also present. Consider merging the recipient information into the template data or wrapping them in a common structure.
| func NewMailer(host string, port int, _ string, sender, accessToken string) Mailer { | ||
| dialer := mail.NewDialer(host, port, "", "") | ||
| dialer.Auth = &xoauth2Auth{ | ||
| username: sender, | ||
| token: accessToken, | ||
| } |
There was a problem hiding this comment.
The username parameter is currently ignored (marked as _), and the sender (email address) is used as the identity for the XOAUTH2 SASL exchange. While many providers use the email as the username, some SMTP servers might require the specific smtp_username provided in the API request for authentication. Since smtp_username is a required field in the API validation, it should be utilized here.
| func NewMailer(host string, port int, _ string, sender, accessToken string) Mailer { | |
| dialer := mail.NewDialer(host, port, "", "") | |
| dialer.Auth = &xoauth2Auth{ | |
| username: sender, | |
| token: accessToken, | |
| } | |
| func NewMailer(host string, port int, username, sender, accessToken string) Mailer { | |
| dialer := mail.NewDialer(host, port, "", "") | |
| dialer.Auth = &xoauth2Auth{ | |
| username: username, | |
| token: accessToken, | |
| } |
… values for OpenShift compatibility
…hift compatibility
Description
Adds a Helm chart that runs the
silver-dkim(OpenDKIM) milter on Kubernetes — the K8s counterpart of theopendkim-serverservice indocker-compose.yml. The chart generatesopendkim.conf/KeyTable/SigningTable/TrustedHosts/silver.yamldeterministically from adomainslist, persists DKIM private keys on a PVC, and exposes the Milter protocol onClusterIP :8891so Postfix can reach it asinet:opendkim-server:8891.Type of Change
Changes Made
silver-opendkimatmail-infra/helm/opendkim-server/(Chart + values + templates + README).templates/configmap.yamlrenders all OpenDKIM config files (opendkim.conf,KeyTable,SigningTable,TrustedHosts,silver.yaml) from.Values.domains— replaces the host-sidegen-opendkim-conf.shflow used by docker-compose.templates/deployment.yamlrunsghcr.io/lsflk/silver-dkim:mainwithrunAsUser/Group: 999,fsGroup: 999,drop: [ALL],allowPrivilegeEscalation: false(mirrors the docker-composecap_drop: all+no-new-privileges:true). Pod rolls automatically on config change viachecksum/configannotation. Pinned toreplicas: 1withstrategy: Recreate(DKIM is singleton + PVC is RWO).templates/service.yamlexposesClusterIP :8891;fullnameOverride: opendkim-serverkeeps the Service DNS name compatible with the existing Postfixmaster.cf(inet:opendkim-server:8891).templates/pvc.yamlpersists/etc/dkimkeyssoopendkim-genkeyonly generates each domain's key once.persistence.existingClaimprovided as an escape hatch for users who'd rather mount a Secret-backed CSI volume.domainsis intentionally empty invalues.yaml; chartfails loudly if it isn't provided via-f/--setat install time.Testing
helm lint mail-infra/helm/opendkim-server --set 'domains[0].domain=example.com'→ passes.helm template ... --set 'domains[0].domain=example.com' --set 'domains[1].domain=another.example.com'→ renders oneKeyTable/SigningTableentry per domain, auto-appends<domain>+*.<domain>toTrustedHosts, and emits a validsilver.yaml.helm templatewith nodomainsfails fast with a clear message.persistence.existingClaim=byo-claimcorrectly skips PVC creation and mounts the supplied claim.helm upgrade --install opendkim-server ./mail-infra/helm/opendkim-server -n pingmailer --create-namespace -f my-domains.yamlkubectl -n pingmailer logs deploy/opendkim-servershowsopendkim-genkeycreating per-domain keys, then OpenDKIM listening on:8891.kubectl -n pingmailer exec deploy/opendkim-server -- sh -c 'cat /etc/dkimkeys/*/*.txt'returns the DNS TXT records to publish.Checklist
Related Issues
Fixes #