postal should not ignore routing table when using smtp relays ?

[fredleger]

Describe the bug

We have setup postal version 3.3.4 in a kubernetes cluster, following the documentation. This cluster is hosted on a managed infrastructure operated by our cloud provide (scaleway, france).
As the mail providers are becoming more and more sensitive about who is sending e-mails to them we noticed that for delivery we are more or less obliged to send our emails trough a whitelisted relay server offered by our cloud provider (smtp.tem.scaleway.com).

The idea is to match the following pattern :

graph LR;
TO(contact-at-example.com) --> MX(MX postal-smtp) --> PW(postal process) --> smtp.tem.scaleway.com --> U(end-user other-at-acme.net)

Loading

So we created on a bare new postal installation :

• an organization example.com
• a mail server dedicated to this usage
• a domain example.com inside this mail server (and setup DNS is all green)
• an address endpoint for [email protected]
• a routing rule for [email protected] using the above address endpoint as main endpoint

What we were expecting was that postal will use the relay server in order to send the e-mail
What we are experiencing is that postal is relaying the email without considering the routing defined

We confirmed it by using mailhog project as a relay, so we could see all the e-mails headers and none of them was mentionning [email protected]

Below is the env vars we used (not using any config file, just vars) :

CLAMAV_ENABLED: 'false'
CLAMAV_HOST: ''
CLAMAV_PORT: '2000'
DNS_MX_RECORDS: postal.example.com
DNS_RETURN_PATH_DOMAIN: postal.example.com
DNS_ROUTE_DOMAIN: ''
DNS_SPF_INCLUDE: _spf.tem.scaleway.com
DNS_TRACK_DOMAIN: postal.example.com
LOGGING_ENABLED: 'true'
LOGGING_HIGHLIGHTING_ENABLED: 'false'
LOGGING_RAILS_LOG_ENABLED: 'false'
LOGGING_SENTRY_DSN: ''
MAIN_DB_DATABASE: postal
MAIN_DB_ENCODING: utf8mb4
MAIN_DB_HOST: postal-mariadb
MAIN_DB_POOL_SIZE: '5'
MAIN_DB_PORT: '3306'
MAIN_DB_USERNAME: postal
MESSAGE_DB_HOST: postal-mariadb
MESSAGE_DB_PORT: '3306'
MESSAGE_DB_USERNAME: postal
POSTAL_DEFAULT_MAXIMUM_DELIVERY_ATTEMPTS: '18'
POSTAL_DEFAULT_MAXIMUM_HOLD_EXPIRY_DAYS: '7'
POSTAL_DEFAULT_SPAM_FAILURE_THRESHOLD: '20'
POSTAL_DEFAULT_SPAM_THRESHOLD: '5'
POSTAL_DEFAULT_SUPPRESSION_LIST_AUTOMATIC_REMOVAL_DAYS: '30'
POSTAL_SMTP_HOSTNAME: postal.example.com
POSTAL_TRUSTED_PROXIES: ''
POSTAL_USE_IP_POOLS: 'false'
POSTAL_USE_LOCAL_NS_FOR_DOMAIN_VERIFICATION: 'false'
POSTAL_USE_RESENT_SENDER_HEADER: 'true'
POSTAL_WEB_HOSTNAME: postal.example.com
POSTAL_WEB_PROTOCOL: https
POSTAL_SMTP_RELAYS: smtp://mailhog:25
SMTP_SERVER_DEFAULT_HEALTH_SERVER_BIND_ADDRESS: 0.0.0.0
SMTP_SERVER_DEFAULT_HEALTH_SERVER_PORT: '9090'
SMTP_SERVER_DEFAULT_PORT: '25'
SMTP_SERVER_LOG_CONNECTIONS: 'false'
SMTP_SERVER_LOG_IP_ADDRESS_EXCLUSION_MATCHER: ''
SMTP_SERVER_MAX_MESSAGE_SIZE: '14'
SMTP_SERVER_PROXY_PROTOCOL: 'false'
SMTP_SERVER_TLS_CERTIFICATE_PATH: /config/certs/tls.crt
SMTP_SERVER_TLS_ENABLED: 'true'
SMTP_SERVER_TLS_PRIVATE_KEY_PATH: /config/certs/tls.key
SPAMD_ENABLED: 'false'
SPAMD_HOST: ''
SPAMD_PORT: '783'
WEB_SERVER_DEFAULT_BIND_ADDRESS: 0.0.0.0
WEB_SERVER_DEFAULT_PORT: '5000'
WEB_SERVER_MAX_THREADS: '5'
WORKER_DEFAULT_HEALTH_SERVER_BIND_ADDRESS: 0.0.0.0
WORKER_DEFAULT_HEALTH_SERVER_PORT: '9090'

To Reproduce

1. setup all as indicated above
2. send e-mail to postal-smtp service using swaks
3. go to mailhog
4. check the email received headers

Expected behaviour

We would expect that relaying is actually using routing table or thta there is an env var that allow to control this behavior (like RELAY_UNMODIFIED=false or something meaningful)

Screenshots

Environment details

• OS: linux
• kubernetes using env var in a configmap (deployed using this chart https://github.com/hoverkraft-tech/helm-chart-postal)

Additional information/context

If this is not an issue but rather a feature, can you point us to the right direction in order to achieve what we are trying to do ?
Feel free to ask any missing details