Different users (email) of one domain to different destinations?

[Walhalla]

Hi,
following problem:
- two (or more) users under one domain: user1@domain.com and user2@domain.com
- emails to user1 should go to destination mailserver mail1.domain.com
- emails to user2 should go to destination mailserver mail2.domain.com (maybe offices in different locations)

Is there any solution to solve this problem with PMG?

Thanks for any idea / solution.

Cheers Walhalla

 

[Stoiko Ivanov]

Not out of the box - relaying with PMG is on a domain-level.

However you can manually adapt the postfix configuration to relay based on individual addressess within one domain.

Without trying it explicitly I think it would work to adapt the main.cf template - see:
https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine

and a second entry to transport_maps - see http://www.postfix.org/postconf.5.html#transport_maps and http://www.postfix.org/transport.5.html

(of course you would then need to maintain the transport map for the address-specific routing manually on the commandline)

I hope this helps!

 

[Walhalla]

Hi and thank you very much for your answer!

Following this example, I would do the following:

- Already have domain.com in the original transport like this:

domain.com smtp:[1.2.3.4]:25 (IP of mail1.domain.com)

- I will create a second table "transport_EX" (example) and put in the users/emails that should go to the second destination:

user2@domain.com smtp:[2.3.4.5]:25 (IP of mail2.domain.com)

- in the main.cf I put the second table in front of the original transport tabe:

transport_maps = hash:/etc/pmg/transport_EX, hash:/etc/pmg/transport

Result:
1. email to user1@domain.com: postfix will not find in transport_EX and will send it to mail1.domain.com

2. email to user2@domain.com: postfix will find in transport_EX (before searching / finding the "normal" transport) and will send to mail2.domain.com

It will work? Would have been rather simple but I thought that Postfix only accepts domains in the transport - tables (not email - addresses). Thought in using virtual - tables but relaying / forwarding to other email is accepted only (not smtp to other machines. If so: my fault - I c/should have known this

Last question: edit this tables manually wouldnt be a problem. But will PMG synchornize this table (transport_EX) or do I have to edit everytime manually on each machine(s) in a cluster (have a second "backup" machine for security reasons).

Thanks a lot for you hint (wakeup call that transport accepts email-addresses too

Cheers Walhalla

 

[Stoiko Ivanov]

It will work?

sounds like it could/should work - but have never done this myself - so could be overlooking something - but definitely worth a try

keep in mind to adapt the postfix config on pmg via the templateing system.

Please post if this works (guess eventually someone else will also want such a setup)

Thanks!

 

[Walhalla]

"sounds like it could/should work - but have never done this myself - so could be overlooking something - but definitely worth a try"

OK, will setup an empty testmachine on the weekend to try out. Will not make any "tests" in real life and maybe lose some emails!

"keep in mind to adapt the postfix config on pmg via the templateing system."
yes, sure. Thats no problem. Already have done this. But onece again: will the changes (adding / remnoving address in the second table) be synchronized to the other(s) machine(s) in the cluster?

"Please post if this works (guess eventually someone else will also want such a setup)"

I will post the results, yes! Wondering that I am the only / first one who has this "problem". Think today there are many companies with several branches, the times of POP3-poll should be over because nearly everybody has a mailserver in the office getting emails via SMTP?!

 

[Stoiko Ivanov]

I will post the results, yes! Wondering that I am the only / first one who has this "problem". Think today there are many companies with several branches, the times of POP3-poll should be over because nearly everybody has a mailserver in the office getting emails via SMTP?!

Guess that depends quite a bit on the company structure - quite a few setups I've heard of run one central mail-server (either at the headquarter or in a Datacenter) - and have a VPN-link from each branch office.

 

[Walhalla]

"Guess that depends quite a bit on the company structure - quite a few setups I've heard of run one central mail-server (either at the headquarter or in a Datacenter) - and have a VPN-link from each branch office."

OK, depends ...

 

[Walhalla]

"But onece again: will the changes (adding / remnoving address in the second table) be synchronized to the other(s) machine(s) in the cluster?"

Stoiko, you - as a staff member - can you confirm that the changes will be synchronized or do we have to do all the changes everytime on every machine manually? Think, would be interesting for others too?!

Thanks a lot for your answer!

 

[Stoiko Ivanov]

hm - if this is a clustered setup that won't quite work ...
cluster-sync keeps only a number of files in sync.
however most files from '/etc/pmg/master' are synced to the other nodes - you could put your transport_EX there.

2 Caveats:
* This is not really a supported/tested setup - thus we cannot promise that the sync will stay that way across updates - you'd need to verify that yourself after each upgrade
* '*.db' files are explicitly excluded from the sync - you need to test if postfix on the node automatically runs postmap on the file

Sine you need to edit the transport_EX file anyways an alternative solution might be to sync it manually (via a script) each time you change it, and also run postmap on all nodes in your cluster

I hope this helps

 

[Walhalla]

hm - if this is a clustered setup that won't quite work ...
cluster-sync keeps only a number of files in sync.
however most files from '/etc/pmg/master' are synced to the other nodes - you could put your transport_EX there.

2 Caveats:
* This is not really a supported/tested setup - thus we cannot promise that the sync will stay that way across updates - you'd need to verify that yourself after each upgrade
* '*.db' files are explicitly excluded from the sync - you need to test if postfix on the node automatically runs postmap on the file

Sine you need to edit the transport_EX file anyways an alternative solution might be to sync it manually (via a script) each time you change it, and also run postmap on all nodes in your cluster

I hope this helps

OK, thanks a lot! Atleast now I know what should/could work and what not will work. Should be simple to write a short "sync-script"!

 

[Walhalla]

OK, thanks a lot! Atleast now I know what should/could work and what not will work. Should be simple to write a short "sync-script"!

OK, I made a fast test:

- put a file "testEX" on the master in /ect/pmg/
- after sync I have /etc/pmg/master/testEX on the client

So far so good But it stays in the /master - directory and I have to copy manually to /etc/pmg/testEX and give a postmap, right?

So we could say that the sync ends with copying the changes to the "master-file" on the slave and we have to copy to the right place manually. Is it?

 

[Stoiko Ivanov]

should work - alternatively - keep it in /etc/postfix - and sync it manually (you need to call postmap anyways on all nodes ...)
additionally I'd call `postfix reload` after postmap (so that postfix opens the updated db file directly)

 

[Walhalla]

should work - alternatively - keep it in /etc/postfix - and sync it manually (you need to call postmap anyways on all nodes ...)
additionally I'd call `postfix reload` after postmap (so that postfix opens the updated db file directly)

Yes, postmap/reload is no problem. We already have some scripts from other machines where we have to change things manually sometimes. Just wanted to know if i understood this sync-mechanism correctly!

Finally, this poit is resolved. Looking forward if the second forward-table is working as expected.

Thank you and have a nice rest of the day / evening!