Dear community, I’ve just set up mailcow on a public server and it’s working fine. Only issue left is handling of (service) mails coming from my home lab (non-public-domain fritz.box). I have Nullmailer installed as MTA on internal hosts and they use a “systems” mailbox on mailcow to send mails to hostmaster@example.com . However, sending out an actual message does not work, the mail.log writes: nullmailer-send[663]: From: <root@host.fritz.box> to: <hostmaster@example.com> nullmailer-send[663]: Message-Id: <1636087318.835751.3479756.nullmailer@host.fritz.box> nullmailer-send[3479758]: smtp: Failed: 553 5.7.1 <root@host.fritz.box>: Sender address rejected: not owned by user systems@example.com if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } What’s “funny”, though is, that the automatically generated bounce message is accepted by mailcow for delivery: nullmailer-send[663]: From: <> to: <hostmaster@example.com> nullmailer-send[663]: Message-Id: <1636087322.532757.3479771.nullmailer@host.fritz.box> nullmailer-send[3479772]: smtp: Succeeded: 250 2.0.0 Ok: queued as EDB5E81291 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } How can I fix this, without turning mailcow into an open relay? Cheers, m0wlheld

How to handle (service) mails from non-public hosts?

m0wlheld

Dear community,

I’ve just set up mailcow on a public server and it’s working fine. Only issue left is handling of (service) mails coming from my home lab (non-public-domain fritz.box). I have Nullmailer installed as MTA on internal hosts and they use a “systems” mailbox on mailcow to send mails to hostmaster@example.com.

However, sending out an actual message does not work, the mail.log writes:

nullmailer-send[663]: From: <root@host.fritz.box> to: <hostmaster@example.com>
nullmailer-send[663]: Message-Id: <1636087318.835751.3479756.nullmailer@host.fritz.box>
nullmailer-send[3479758]: smtp: Failed: 553 5.7.1 <root@host.fritz.box>: Sender address rejected: not owned by user systems@example.com

What’s “funny”, though is, that the automatically generated bounce message is accepted by mailcow for delivery:

nullmailer-send[663]: From: <> to: <hostmaster@example.com>
nullmailer-send[663]: Message-Id: <1636087322.532757.3479771.nullmailer@host.fritz.box>
nullmailer-send[3479772]: smtp: Succeeded: 250 2.0.0 Ok: queued as EDB5E81291

How can I fix this, without turning mailcow into an open relay?

Cheers,

m0wlheld

hugalafutro

I was running to exact same issue, and to get mailcow to accept mails from local lan hosts i had to disable sender verification on the receiving mailbox which I presume presents a security vulnerability as it warns in red when I select that.

Anyone has any insight how to make mailcow to accept mail from local lan hosts without compromising security?
Thanks!

hugalafutro

Figured it out! Your post made me try nullmailer which is absolutely fantastic as the whole config is 1 line as opposed to postfix which I spent last 2 days reading about, which let me focus on the mailcow side of the thing.

say your local vm is vm.lan and mailcow runs on mailcow.lan locally:

in /etc/nullmailer/remotes on vm.lan:
mailcow.lan smtp --port=587 --starttls --insecure --user=foo@example.com --pass=pass

In Mailcow UI edit foo@example.com Mailbox and in field called External sender addresses:
type @vm.lan and any other local hosts delimited by space

Of note is you I use --insecure as my mailcow host uses self-signed cert behind reverse proxy. I also had to put lan into /etc/nullmailer/domain. YMMV

m0wlheld

After having posted my issue I went through the nullmailer man-pages again and found out, that you call create a file “/etc/allmailfrom” with the e-mail-address of the sending mailbox (system@example.com in my case). It will be used instead of the “computed” sender address (root@host.fritz.box) in my case.

That solved the issue without modifying mailcow’s configuration.