Use LDAP profiles for transport to the destination host

[northe]

We have just set up a POC and would like to use PX professionally. So far everything looks good only one point is still open:

We use an LDAP server on which all mail recipients from two locations are created for the recipient check.
Both locations have the same mail domain.
For each location there is an OU under which the corresponding recipients can be found. Now I can create a separate LDAP profile for each location, but I can't find a way to use this profile for the transport, because each location has its own mail server.

Is there a way to achieve this?

 

[hata_ph]

Just create a relay domain entry under Configuration -> Mail Proxy -> Transports with your full email address instead of @domain and the respective smtp relay/server, it should work.

 

[northe]

Hi hata_ph,
Thank you so much for your quick reply.
I've read your earlier request about your topic but unlike your problem I need a solution that either works with the LDAP profile or is alternatively controllable with an LDAP attribute/value (mailhost:ip-address). I could add such a pair for each user.
The ideal solution would be if the transport could be controlled via the LDAP profile.

 

[hata_ph]

Hi hata_ph,
Thank you so much for your quick reply.
I've read your earlier request about your topic but unlike your problem I need a solution that either works with the LDAP profile or is alternatively controllable with an LDAP attribute/value (mailhost:ip-address). I could add such a pair for each user.
The ideal solution would be if the transport could be controlled via the LDAP profile.

Dun think you can use ldap with transport via the GUI in PMG. But I believe you can manually create main.cf to use ldap transport map. Try it and let us know.

https://serverfault.com/questions/392532/postfix-relay-ldap-lookups-and-transport

 

[northe]

According to the posts in serverfault I need to install an configure the perdition proxy? Have you also went this way?

 

[hata_ph]

According to the posts in serverfault I need to install an configure the perdition proxy? Have you also went this way?

If you already have your dedicated email server at two location, you no need the perdition proxy.
Just create a ldap_transport to query your ldap profile for the attribute,

transport_maps = hash:/etc/postfix/transport ldap:/etc/postfix/ldap_transport

No, i just set the transpot in the GUI as I dun store that info in my ldap server.

 

[northe]

Okay, I nearly finised it.
I needed to install postfix-ldap package.
Right now, I can check my settings with
postmap -q user@domain.com ldap:/etc/postfix/ldap_transport.cf
with the correct result
relay:mailserver.local.domain.com

A quick check with "echo test | mail -s "Testing at 7:40" user@domain.com" is getting queued and postfix whats to deliver it to the host resolved by the domain name.
So I disabled MX lookups in the GUI and tried to disable DNS lookups too, by adding disable_dns_lookups=yes into main.cf manually.
But these settings do not survive changes made with the GUI. It always tries to connect to the mail server responsible for the domain.com.

 

[hata_ph]

Okay, I nearly finised it.
I needed to install postfix-ldap package.
Right now, I can check my settings with
postmap -q user@domain.com ldap:/etc/postfix/ldap_transport.cf
with the correct result
relay:mailserver.local.domain.com

A quick check with "echo test | mail -s "Testing at 7:40" user@domain.com" is getting queued and postfix whats to deliver it to the host resolved by the domain name.
So I disabled MX lookups in the GUI and tried to disable DNS lookups too, by adding disable_dns_lookups=yes into main.cf manually.
But these settings do not survive changes made with the GUI. It always tries to connect to the mail server responsible for the domain.com.

Copy /var/lib/pmg/templates/main.cf.in to /etc/pmg/templates/main.cf.in. Edit your custom postfix main.cf.in at /etc/pmg/templates/main.cf.in

https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_service_configuration_templates

 

[northe]

Now it works as expected
Thanks a lot.

 

[hata_ph]

pls show us your config so that others can benefit from your setup...

 

[northe]

Sure. At the end, it was only this simple setting.

# LDAP user, only relevant attributes / values:
mail = foo.bar@domain.com
mailHost = fqdn-of-foo.bar-home-mailserver

# /etc/pmg/templates/main.cf.in
transport_maps=ldap:/etc/postfix/ldap_transport.cf
disable_dns_lookups=yes

# /etc/postfix/ldap_transport.cf
server_host = ldaps://ldapserver.local.domain.com
version = 3
search_base = ou=users,dc=domain,dc=com
recursion_limit = 1000
# size limit = 1 to get only one result back from search
size_limit = 1
bind = yes
# bind = yes / sasl / no
bind_dn = < bind user >
bind_pw = < bind password >
scope = sub
query_filter = mail=%s
result_attribute = mailHost
result_filter = relay:%s

-----
One challenge is still open:
The mail gateway should not accept mails if the LDAP server cannot be reached! Otherwise the mail gateway does not know where to deliver the transmitted mail. It remains in the queue and does not get the missing information back - even if you restart the Postfix service or force the delivery with "flush".

 

[hata_ph]

You might want to use below setup, so that you still be able to add custom transport from the GUI.

transport_maps=hash:/etc/postfix/transport ldap:/etc/postfix/ldap_transport.cf

The mail gateway should not accept mails if the LDAP server cannot be reached! Otherwise the mail gateway does not know where to deliver the transmitted mail. It remains in the queue and does not get the missing information back - even if you restart the Postfix service or force the delivery with "flush".

You can to have a bounce back email or reject from PMG if the LDAP tranport lookup profile failed or your external location email server failed or unreacheable? Your PMG use for incoming and outgoing gateway?

 

[northe]

I will install ldap server on the mailgateway and will create a syncrepl to have the cn=users part locally. This is for me the most secure way to handle a LDAP server downtime.