Mailcow-dockerized: Weird forwarding behaviour

Created on 4 May 2017  路  13Comments  路  Source: mailcow/mailcow-dockerized

So I've set up a mail address as "catcher" for forwarded mails while I move a mail server from server A to server B.

Imagine it like this:
(old server) server A has addresses [email protected] - [email protected] - [email protected]
(new server) server B has address [email protected]

I set server A to forward all mails like this:

It looks like mails are correctly forwarded without problems, as long as serverA.com is not part of the mailbox server of serverB.com, so it works for external servers, but then I encountered a strange error.

When I try to send mails from [email protected] to [email protected] the mail is sent to [email protected] but not forwarded to [email protected] and I get the mail delivery error mail with: "host mail.serverB.com [some.ip.com]: 553 5.7.1 Sender address rejected: not logged in"

What should I do to make this work?

EDIT: Sending from [email protected] also doesn't work. So it doesn't work for all domains that run on the same mailcow server.

All 13 comments

Could it be that I should change the postfix/main.cf like this:

smtpd_sender_restrictions = permit_mynetworks, ...

?

EDIT: Nevermind, the main.cf contains this setting already.

Not sure if I understand your problem correctly. do you ultimately want to have a seemless delivery and access while moving from one server to the other?

if so, couldn't you just set up a sync job in mailcow UI for each email?

let's say I have my email [email protected], running on serverA, which is running mailcow 0.14

and I want to move that address to serverB which runs mailcow-dockerized

I would add mydomain.com to the domains in mailcow UI of mailcow-dockerized and add the mailbox [email protected] - then I logg into mailcow UI with the account [email protected] and create a sync job and tell it to pull all existing and future emails every 10 minutes into the newly created mailbox, without duplicates. of course i am using the current mx hostname of mydomain.com (as it was set up with mailcow 0.14)

so let's say the current mx hostname of mydomain.com is e.g. _mail.mydomain.com_ and the a record of mail is set to the ip of serverA. let's say the mx has a priority of 25
I would create a second mx hostname in my dns for mydomain.com called _mx.mydomain.com_ and set the a-recordof mxto the ip of serverB. i would set a lower priority than the 'old' mx mail.mydomain.com has (of course i do this before installing mailcow-dockerized on serverB).
so from then on, when emails are being sent to [email protected] the new mx will be used and mail ends up in [email protected] on serverB - while the dns changes are being propagated, some servers might still talk to the old mx mail.mydomain.com and the mail ends up on serverA - but the syncjob will pull those messages to the mailbox on serverB. at some point, all mail will go directly to [email protected] on serverB and serverA could be shut down.

i will at some point in the future do this and am testing it right now and it seems to do what I want (seemlessly move servers and switch from mailcow 0.14 to mailcow dockerized ( 馃樅馃挊)

i hope i understood your issue :-p

Your steps are already in place and work. This is not the issue.

The forwarding is meant as failsafe and I just want to know why mails sent from the server that mailcow runs on, are not allowed to be forwarded back to the server.

When you try to send as a user@server1, that also exists on server2, server2 will reject and say "this is not you, because I handle that mailbox". If you want to send as user@server1, you need to authenticate to server2 _or_ allow this scenario by changing data/conf/postfix/main.cf on server2:

smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, permit_mynetworks, reject_sender_login_mismatch, permit_sasl_authenticated, reject_unlisted_sender, reject_unknown_sender_domain

=> remove "reject_sender_login_mismatch" =>

smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, permit_mynetworks,  permit_sasl_authenticated, reject_unlisted_sender, reject_unknown_sender_domain

Thank you for clarifying @andryyy ! :)
Could this have negative repercussions? Isn't SPF/dkim used as a countermeasure for this on external Servers?

Some spammers send in behalf of your own mail address to yourself.

People can still send mail from their own servers faking your domain, but this is when SPF and DKIM (kind of) help out. :)

Well my question here is:
How can spammers send in behalf of my own mail address to myself, if the SPF/DKIM check should show, that they are indeed not from my own server?

It depends on how your own server handles it. mailcow does reject those mails with aboves Postfix restriction. But such a message would also DKIM/SPF fail and land in junk.

So for Mailcow, if I remove reject_sender_login_mismatch, DKIM/SPF would still work and correctly put that stuff into spam?

Yep.

Excellent!
Thanks for clarifying! 馃樃

Instead of modifying the sender restrictions, you could just add the other server to Postfix's mynetworks parameter. That exempts it from checks like the sender restrictions, without giving up the check for all other servers.

@mkuron server A in my case is a relayhost with a lot of users. I bet I would get a huge ton of spam if I did that ^^.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thannaske picture thannaske  路  3Comments

starcraft0429 picture starcraft0429  路  3Comments

constin picture constin  路  3Comments

Braintelligence picture Braintelligence  路  3Comments

K2rool picture K2rool  路  3Comments