Sender based transport map is ignored by alias

[robincle]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
• ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
• ... I have understood that answers are voluntary and community-driven, and not commercial support.
• ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

We've found a bug/malfunction in the actual (maybe also the prev.) version(s) of 2024-04. 

The sender based transport map is ignored, if the mail is getting forwarded due to an alias. 

For example:
A sender based transport map is set to send mails via mailout.itcompany.de for the whole domain customer.de. The emailaddress [email protected] is configured as an alias to forward all mails to [email protected]. If [email protected] is sending an email to [email protected], the email gets forwarded to [email protected]. But the email is forwarded by the mailcow host machine (f.e. mailcow.itcompany.de) and not by mailout.itcompany.de (as given in the sender based transport map). As a mailcow admin, i would expect, that every mail for the domain customer.de is send by the configured sender based transport map and not by the mailcow host itself.

The given example shows you that gmail.com will maybe reject the mail because the sending server is the mailcow.itcompany.de instead of mailout.itcompany.de (which is configured as spf record because it's the main sending system for customer.de domain).

Logs:

We've checked all the logs of the mailout systems and the forwarded mail couldn't found in the logs. We've found the log only in the mailcow host log which sent it directly to the alias recipient (gmail). You can find the original log (but anonymized) below. This is the log of the mailcow host and not of the server configured in the sender based transport map, because nothing is found on that. The details of the error, given by gmail, are irrelevant. It just brought it to our attention that the mail is sent by the mailcow host, which hasn't a correct ipv6 ptr record configured, because it isn't sending emails usually.


mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:33 9415ae0a0f71 postfix/smtpd[21616]: 1ADC62C07DF60: client=smtprelay02.ispgateway.de[80.67.31.29]
mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:33 9415ae0a0f71 postfix/cleanup[21384]: 1ADC62C07DF60: message-id=<[email protected]>
mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:33 9415ae0a0f71 postfix/qmgr[462]: 1ADC62C07DF60: from=<[email protected]>, size=1428, nrcpt=1 (queue active)
mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:34 9415ae0a0f71 postfix/smtp[21719]: 1ADC62C07DF60: to=<[email protected]>, orig_to=<[email protected]>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1a]:25, delay=1.9, delays=0.79/0.03/0.74/0.37, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1a] said: 550-5.7.1 [2a01:4f8:xxx:xxx::1] Gmail has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . For more information, go to 550 5.7.1  https://support.google.com/mail/?p=IPv6AuthError j9-20020adfff89000000b00349a91c850fsi111433wrr.682 - gsmtp (in reply to end of DATA command))
mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:34 9415ae0a0f71 postfix/bounce[21722]: 1ADC62C07DF60: sender non-delivery notification: E3A162C046DC2
mailcowdockerized-postfix-mailcow-1  | Apr 18 00:38:34 9415ae0a0f71 postfix/qmgr[462]: 1ADC62C07DF60: removed

Steps to reproduce:

as described above.

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Ubuntu 22.04 LTS

Server/VM specifications:

8 CPU, 32GB, 240 GB SSD

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

Docker version:

26.0.1

docker-compose version or docker compose version:

v2.26.1

mailcow version:

2024-04

Reverse proxy:

nginx

Logs of git diff:

-

Logs of iptables -L -vn:

-

Logs of ip6tables -L -vn:

-

Logs of iptables -L -vn -t nat:

-

Logs of ip6tables -L -vn -t nat:

-

DNS check:

-

[milkmaker]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[dragoangel]

You must not use aliases to deliver outside of mailcow. When you creating or editing aliases you have clearly this written in the description. You ignore this, that's why you think it's bug. You MUST create local mailbox with sieve forward rule to send emails outside of mailcow and use this local mailbox with alias. Then everything will work as should.

[hrw]

Thanks @dragoangel!

Your answer shown me light and I finally got email rewriting properly.

Instead of trying user@domain -> other@elsewhere by alias, now I did user@domain mail account with some random password, only smtp/sieve enabled. Then sieve prefilter to redirect to other@elsewhere (example code is enough).

[dragoangel]

Thanks @dragoangel!

Your answer shown me light and I finally got email rewriting properly.

Instead of trying user@domain -> other@elsewhere by alias, now I did user@domain mail account with some random password, only smtp/sieve enabled. Then sieve prefilter to redirect to other@elsewhere (example code is enough).

You also can do:

[email protected] (alias) => [email protected] (mailbox), [email protected] (mailbox), [email protected] (mailbox on mailcow), [email protected] (mailbox on mailcow with sieve fwd to [email protected]),
[email protected] (another alias)

So it will be very clear, main rule: alias can include another alias or local mailbox, and NOT external one, external delivery MUST be done with sieve forwarding via local mailbox.