Forwarding to external addresses doesn't work (anymore?)

Hello dear community

I have (one/several) network servers with a stupid problem.

If email is received or accepted from external addresses for a local mailbox (or alias) and that mailbox or alias is set up to be forwarded to another external address, this will fail.

The email is (apparently) forwarded using the address of the original sender. This will of course be rejected by the receiving mail server.

Unfortunately, I can’t say whether this is a general behavior of the Nethserver because I haven’t had this scenario “extern-email > Nethserver > other-extern” before.

I run Nethserver with ProxmoxMailgateway upstream and like to use a specific “local” email address, let’s say “status@my-domain.tld”, for status messages and error messages from Nethserver services and other devices in the local network.

This “local” address is stored in the Nethserver as a forwarding address (without an account) to an external address, let’s say “status@other-domain.tld” - which is on a completely different server under a different external IP. Status emails that arrive at the network server for “status@my-domain.tld” have long been reliably forwarded to “status@other-domain.tld”. Since the senders of the status emails all work “locally” behind the external IP (permissible sender IP), I have not yet noticed that the above-mentioned forwarding only works in “local” cases.

External emails that reach the net server from “status@my-domain.tld” and are then supposed to be forwarded to the external email address “status@other-domain.tld” FAIL. It doesn’t matter whether “staus@my-domain.tld” is just an alias with forwarding to an external address or exists as a real mailbox on NEthserver and should be forwarded via mailbox forwarding or as a forwarding set up in SOGo.

The reason for this is clear (as described at the beginning) because the original address (and therefore domain) is used as the sender address in the forwarding.

But why does the Nethserver do this? Does this mean that any emails received externally cannot be sent to another external address? Wouldn’t it be more correct if the sender was replaced by the address (and therefore domain) of the net server?

Addendum:

The problem apparently does not affect all external incoming emails, because “noreply-dmarc-support@google.com”, for example, is forwarded correctly.

Hi

One possibility for your problem would be say a status from a printer using a domain like:

printer-status@local.lan

These would be denied by other mail servers as it’s an invalid domain…

My 2 cents
Andy

That probably (of course) wouldn’t work either. But I don’t know exactly in my case because the sender addresses in the local network are all set correctly.

It’s actually about the behavior of the net server, which does not replace the sender when forwarding.

Hi @yummiweb

In my opinion, that is the correct behavior. You are, after all, only asking the server to “forward” the mail…

If you want the sender changed correctly, you need to use a “local account”, and set mail-sieve rules to automatically “resend” these mails from that “local” account.

This can easily be set eg using Roundcube, which can set mail-sieve rulres via Web-Interface - these rules are respected by the server itself, even without roucdcube running, these are “server” mail-sieve rulers!

This could assure all mails are sent from a valid account / domain, also respected elsewhere (and not set as spam!). :slight_smile:

This wouls also give an option to check exactly what is sent, and using what credentials / domain, on the fly by using roundcube web to see incoming and also “resent” mail…

My 2 cents
Andy

Until now I had used the “Alias with external forwarding” variant. So E-Mail > Addresses > external E-Mail without a “real” user account.

After I noticed the behavior described, I created a user account instead and redirected to external in the same place. The problem was the same.

Then I set up a forwarding in SOGo (which also uses Sieve), but it was exactly the same there too.

I would have expected SOGo to redirect under the account address at the latest. But he doesn’t.

The problem occurs on 3 machines…