[Aravinda-HWK]

Description

Adds a Helm chart that runs the Postfix-based SMTP server (ghcr.io/lsflk/silver-smtp) on Kubernetes — the K8s counterpart of the smtp-server service in docker-compose.yml. The chart renders main.cf / master.cf / recipient_access from values, runs postmap in an init container so the lookup table is compiled before Postfix starts, wires Postfix to opendkim-server:8891 and raven-sasl:12345, and persists the mail queue on a PVC.

Type of Change

• New feature
• Bug fix
• Documentation update
• Code refactoring
• Other (please describe):

Changes Made

• New Helm chart silver-smtp at mail-infra/helm/smtp-server/ (Chart + values + templates + README).
• templates/configmap.yaml renders main.cf, master.cf, silver.yaml, and recipient_access from .Values.domain and .Values.postfix.* — replaces the host-side gen-postfix-conf.sh flow used by docker-compose. main.cf sets maillog_file = /dev/stdout so kubectl logs works.
• templates/deployment.yaml uses an init container that seeds an emptyDir with the image's stock /etc/postfix/ contents (postfix-script, postfix-files.d, dynamicmaps.cf.d), overlays the four rendered configs, and runs postmap recipient_access so the lookup table is compiled before Postfix starts. This moves the postmap step from the post-start docker exec in start-silver.sh into the pod lifecycle where it belongs.
• TLS Secret mount with key remap: tls.crt → fullchain.pem, tls.key → privkey.pem, mounted at /etc/letsencrypt/live/<domain>/ — exactly where main.cf expects them. Compatible with the silver-certificates chart's <dash-domain>-tls Secrets out of the box.
• templates/service.yaml exposes :25 (SMTP) and conditionally :587 (submission, STARTTLS-enforced) on ClusterIP (fullnameOverride: smtp-server keeps the Service DNS compatible with the existing docker-compose hostname).
• templates/pvc.yaml provisions persistence for /var/spool/postfix so in-flight mail survives pod restarts. Recreate strategy + replicaCount: 1 because the queue PVC is RWO and Postfix is intrinsically single-writer.
• checksum/config annotation triggers a pod restart whenever rendered configs change.
• domain is intentionally empty in values.yaml; chart fails with a clear message if missing. Also fails when postfix.submission.enabled=true but tlsSecret.name is empty (submission/587 enforces STARTTLS — running it without a cert would CrashLoop).
• Drops two things from docker-compose that don't translate to K8s:
  • /var/log named volume — replaced by stdout logging.
  • The /app/data/databases/shared.db warning path — the image entrypoint touches this best-effort but nothing actually shares it in docker-compose either (no cross-container volume mount), so the chart doesn't provision one.

Testing

• helm lint mail-infra/helm/smtp-server -f my-smtp-values.yaml → passes.
• helm template ... --set domain=example.com --set tlsSecret.name=example-com-tls → renders:
  • ConfigMap with correct myhostname=mail.example.com, mydomain=example.com, TLS cert paths under /etc/letsencrypt/live/example.com/, recipient_access with @example.com REJECT ….
  • Service exposing both :25 and :587.
  • Deployment with the init container running postmap and the main container mounting the prepared /etc/postfix emptyDir.
• Negative tests:
  • Missing domain → fails with "domain is required …".
  • postfix.submission.enabled=true (default) with empty tlsSecret.name → fails with "tlsSecret.name is required when postfix.submission.enabled=true …".
• postfix.submission.enabled=false correctly drops the :587 port from the Service and lifts the TLS-required guard.
• End-to-end install path (requires the other charts already installed):
  1. helm upgrade --install smtp-server ./mail-infra/helm/smtp-server -n pingmailer --create-namespace -f my-smtp-values.yaml
  2. kubectl -n pingmailer logs deploy/smtp-server → init container reports ✓ /etc/postfix prepared, recipient_access compiled., main container reports Postfix is running with PID ….
  3. kubectl -n pingmailer run -it --rm tmp --image=busybox --restart=Never -- nc -v smtp-server 25 → connection accepted, 220 mail.example.com ESMTP Postfix banner.
  4. With opendkim-server and raven-sasl deployed in the same namespace, both smtpd_milters=inet:opendkim-server:8891 and smtpd_sasl_path=inet:raven-sasl:12345 resolve cluster-internally with no edits.

Checklist

• My code follows the project's coding standards
• I have tested my changes
• I have updated the documentation (if needed)
• My changes don't introduce new warnings or errors

Related Issues

Fixes #

[gemini-code-assist]

Code Review

This pull request transitions the API server to mandatory HTTPS, replaces local OAuth2 token introspection with downstream XOAUTH2 authentication for SMTP, and introduces support for multiple recipients in email notifications. Additionally, it includes a new Helm chart for the SMTP server and infrastructure bootstrap scripts. Feedback suggests merging recipient identity fields with custom template data in the notification handler to ensure both are available within email templates.

[gemini-code-assist]

When a custom template is used with template_data, the recipient's information (Name, Email, APP) is completely replaced by the provided data. This makes it impossible to use both the recipient's identity and custom data in the same template unless the identity is manually duplicated in the request payload.

Consider merging the recipient information into the template data map to provide a richer context for custom templates.

templateData := map[string]any{
	"Name":  recipient.Name,
	"Email": recipient.Email,
	"APP":   recipient.APP,
}
if len(req.TemplateData) > 0 {
	for k, v := range req.TemplateData {
		templateData[k] = v
	}
}

[maneesha-xyz]

LGTM.