Skip to content

Postfix SMTP relay configurations are ignored when replying to aliases in self-hosted docker instance #428

Description

@doreks

Hi there,

I am running a self-hosted instance of addy.io using the official anonaddy/anonaddy:latest image deployed via Docker Compose.

Everything works flawlessly regarding inbound emails (forwarding to my recipient works perfectly). However, when trying to reply to an alias, the outgoing email is accepted locally but never forwarded to my configured SMTP relay (SMTP2GO). It seems Postfix completely ignores the configured SMTP relay variables and tries to deliver the mail directly (failing silent or dropping it due to residential IP blocks), or drops the mail routing entirely without any delivery attempt.

Configuration (docker-compose.yml):
Sensitive credentials, passwords, and custom keys have been redacted.

`version: '3'
services:
  anonaddy:
    image: anonaddy/anonaddy:latest
    container_name: AnonAddy
    restart: always
    pids_limit: 2048
    ports:
      - "8008:8000"
      - "25:25"
    environment:
      - TZ=Europe/Paris
      - APP_URL=https://alias.example.com
      - APP_NAME=AnonAddy
      - APP_ENV=production
      - APP_DEBUG=true
      - APP_LOG_LEVEL=debug
      - LOG_CHANNEL=stack
      - APP_FORCE_HTTPS=true
      - TRUSTED_PROXIES=*
      
      # Database & Redis (working perfectly)
      - DB_CONNECTION=mysql
      - DB_HOST=db
      - DB_PORT=3306
      - DB_DATABASE=anonaddy_database
      - DB_USERNAME=anonaddy
      - DB_PASSWORD=xxxxxxxxxxxxx
      - REDIS_CLIENT=phpredis
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      
      # SMTP Configuration for App Notifications (working)
      - MAIL_DRIVER=smtp
      - MAIL_FROM_NAME=AnonAddy Client
      - MAIL_FROM_ADDRESS=user@example.com
      - MAIL_HOST=mail-eu.smtp2go.com
      - MAIL_PORT=587
      - MAIL_ENCRYPTION=tls
      - MAIL_USERNAME=my-smtp-username
      - MAIL_PASSWORD=my-smtp-password
  
      # Postfix SMTP Relay Environment Variables (Seems ignored)
      - POSTFIX_RELAYHOST=mail-eu.smtp2go.com
      - POSTFIX_RELAYHOST_PORT=587
      - POSTFIX_RELAYHOST_AUTH_ENABLE=true
      - POSTFIX_RELAYHOST_USERNAME=my-smtp-username
      - POSTFIX_RELAYHOST_PASSWORD=my-smtp-password
      - POSTFIX_SMTP_TLS=encrypt
      
      # App Settings
      - ANONADDY_RETURN_PATH=support@example.com
      - ANONADDY_ADMIN_USERNAME=admin
      - ANONADDY_ENABLE_REGISTRATION=true
      - ANONADDY_DOMAIN=alias.example.com
      - ANONADDY_HOSTNAME=Anonaddy
      - ANONADDY_DNS_RESOLVER=1.1.1.1
      - ANONADDY_ALL_DOMAINS=sub1.example.com,sub2.example.com,sub3.example.com
      - ANONADDY_DKIM_SELECTOR=default
      
    volumes:
      - /opt/anonaddy/data:/data
    depends_on:
      - db
      - redis
    networks:
      - anonaddy_net

networks:
  anonaddy_net:
    driver: bridge`


Step-by-Step Flow & Container Logs:
An incoming reply email is sent from the verified recipient (user@example.com) to the reply-to address (test+alias=target.com@sub1.example.com).

Postfix successfully accepts the connection and queues the message.

The mail is passed through a pipe to the anonaddy service.

The application processes it successfully, resulting in: status=sent (delivered via anonaddy service).

The queue entry is removed.

The issue: There is absolutely no subsequent trace of Postfix establishing or attempting to establish a TLS connection to mail-eu.smtp2go.com on port 587.

Here are the active logs on a reply attempt:

postfix/postlog: starting the Postfix mail system Anonaddy postfix/master[1124]: daemon started -- version 3.10.9, configuration /etc/postfix 192.168.1.196 - - [17/Jul/2026:10:46:31 +0200] "GET /login HTTP/1.1" 200 5435 "-" "Uptime-Kuma/2.4.0" 127.0.0.1 - - [17/Jul/2026:10:46:33 +0200] "GET / HTTP/1.1" 302 366 "-" "curl/1.17.0" Anonaddy postfix/smtpd[1136]: connect from mail-106117.protonmail.ch[79.135.106.117] Anonaddy postfix/smtpd[1136]: 6334524627A: client=mail-106117.protonmail.ch[79.135.106.117] Anonaddy postfix/cleanup[1141]: 6334524627A: message-id=<_Osic4xFLQkk7ePsS14i1SzzB4BYDuXBOrpL_MLzJQhQ9hcUB90wc-rUp19D37MVuSKsM4A2ezf-JZXHhNYYBum5CXC33BE36XyvOPPeahY=@example.com> Anonaddy postfix/qmgr[1126]: 6334524627A: from=<user@example.com>, size=10472, nrcpt=1 (queue active) Anonaddy postfix/smtpd[1136]: disconnect from mail-106117.protonmail.ch[79.135.106.117] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Anonaddy postfix/pipe[1142]: 6334524627A: to=<test+alias=target.com@sub1.example.com>, relay=anonaddy, delay=0.66, delays=0.43/0/0/0.22, dsn=2.0.0, status=sent (delivered via anonaddy service) Anonaddy postfix/qmgr[1126]: 6334524627A: removed

Domain & DNS Security Architecture Context
To rule out any external validation drops, unintended spoofing blocks, or strict DMARC alignment failures, here is the verified DNS infrastructure configuration deployed on Cloudflare for the routing domain:

  1. SPF Alignment (Sender Policy Framework)
    Both the primary apex domain and all active routing subdomains have been updated to explicitly declare and delegate authority to the external authenticated relay.

Apex Domain SPF:
"v=spf1 include:_spf.protonmail.ch include:_spf.google.com include:spf.smtp2go.com mx ~all"

Subdomain SPF (e.g., routing sub-zone):
"v=spf1 include:_spf.protonmail.ch include:spf.smtp2go.com a mx ~all"

Takeaway: The outbound IP space utilized by the authenticated relay host (mail-eu.smtp2go.com) holds valid structural authorization to dispatch mail envelopes on behalf of both tiers of the domain hierarchy.

  1. DMARC Policy (Domain-based Message Authentication, Reporting, and Conformance)
    A monitoring policy is currently enforced across the domain layers to gather reporting while avoiding operational transport drops at the destination MTA during testing.

DMARC Record Configuration:
"v=DMARC1; p=none; rua=mailto:redacted@example.com; adkim=r; aspf=r"

Questions:
Is there a specific format required for the environment variables to properly map Postfix's client-side TLS and SASL authentication in this image version?

Is it possible that the entrypoint.sh configuration template fails to map POSTFIX_RELAYHOST and related variables to /etc/postfix/main.cf during container initialization?

Has anyone successfully routed outbound replies to an external authenticated SMTP relay with the official latest image?

Any help or guidance would be greatly appreciated!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions