Feature to configure informative server alias name for mail origin analysis

[usrflo]

I am using dma inside multiple system containers/servers with /etc/mailname consistently set to provider.tld in all environments: this uniform mailname creates existing Return-Path mail addresses ...@provider.tld that pass anti-spam checks on receiving MTAs.

Therefore any Received headers contain the uniform mailname by provider.tld (DragonFly Mail Agent v0.11); that does not allow to analyse the origin system container/server.

I think about an additional, optional dma config value SERVERALIAS that defaults to the hostname() value. This server alias would be used to construct the Received header in mail.c, function 'readmail'.

Is this an appropriate solution or is there any better way for the besaid mail origin analysis?

[corecode]

how do other systems handle this?

On 29/04/2021 04:28, Florian Sager wrote:

I am using dma inside multiple system containers/servers with |/etc/mailname| consistently set to |provider.tld| in all environments: this uniform mailname creates existing Return-Path mail addresses @.***| that pass anti-spam checks on receiving MTAs.

Therefore any Received headers contain the uniform mailname |by provider.tld (DragonFly Mail Agent v0.11);| that does not allow to analyse the origin system container/server.

I think about an additional, optional dma config value SERVERALIAS that defaults to the hostname() value. This server alias would be used to construct the Received header in mail.c, function 'readmail'.

Is this an appropriate solution or is there any better way for the besaid mail origin analysis?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/corecode/dma/issues/98, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLOO4HZ2UCWAY4C6SYJA3TLERDFANCNFSM43ZQLOAQ.

[usrflo]

I guess the configuration of a uniform mailname is not commonly in use in the industry; I can't say how other systems handle the "origin-detection-problem" in such a setup.

The approach to use a uniform mailname to pass spam-checks on receiving systems is a workaround that saves working hours in comparison to a) the effort to configure each unique hostname on the mailserver environment plus MX DNS zone configuration (we use lots of container environments ...) b) the effort to configure a unique SMTP user per system to use with SMTP-Auth (compared to /etc/dma/auth.conf)

[corecode]

maybe we should include the actual host name in the comment?

On April 30, 2021 10:27:17 AM CDT, Florian Sager @.***> wrote:

I guess the configuration of a uniform mailname is not commonly in use in the industry; I can't say how other systems handle the "origin-detection-problem" in such a setup.

The approach to use a uniform mailname to pass spam-checks on receiving systems is a workaround that saves working hours in comparison to a) the effort to configure each unique hostname on the mailserver environment plus MX DNS zone configuration (we use lots of container environments ...) b) the effort to configure a unique SMTP user per system to use with SMTP-Auth (compared to /etc/dma/auth.conf)

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/corecode/dma/issues/98#issuecomment-830174183

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[usrflo]

maybe we should include the actual host name in the comment?

Yes, by provider.tld (DragonFly Mail Agent v0.11 on realhostname); would be helpful. I thought about an additional config value named SERVERALIAS to explicitly set this hostname value. But using gethostname() is well to me also.

[corecode]

merged, thanks!