Ldap verification only for some domains

F

felipe

Well-Known Member
Oct 28, 2013
222
6
58
Hi,
i was reading the https://forum.proxmox.com/threads/h...-that-are-not-ldap-users-to-proxmox-mg.75916/ thread but it did not help me a lot.

First: Enabling Recievers did not change the behavior for me. I still get messages delivered and then the error Message Mail from the Exchange Server behind (and not from the proxmox gateway)

Second: i tried going the way with blocking the mails for non existing LADP Users. But this applies to ALL domains. But we have some domains which have other external Mailservers then the standard Exchange Cluster for the rest of the Domains. So LDAP will fail for this external Exchange Server.
How ist it possible to make checks only for certain Domains?
Also i was seeing that when i block a mail i get a standard error message which does not say that the email was not found. Of course now i can trigger a notification Email but then the sender will recive the error Message from its own Email Server and also one from Proxmox Mailgateway. Not good. so maybe it would also make sense to be able to add /config propper block rules (what is not possible at the monent)

I like the proxmox mailgateway a lot specually it gives a lot of features to tune everything. But before we where using mailcleaner and the aggregate all options to a domain. So all config is made inside a domain which makes a lot of sense (which incoming and outgoing servers used for the domain, which ldap verification etc.) this is one point that i am really missing at proxmox mail gateway.
 
Any idea how to do this? would be nice to have a solution which denies email directly with the correct message instead of sendig a error message which will lead to backscatter.

Also it is not possible to use the LDAP authentification if some external transport are also configured and they have no ldap (because they are somewhere else in the internet and not lan)
 
Receiver Verification works reliable, you just need to make sure that your internal email server is also configured as needed.

Post your logs/errors.
 
ladp itself it is working good. but as i wrote we have the main exchange cluster (our) in the same lan where we use it and it works. but some external transport servers (external exchange server on wan where they dont want to expose ldap!) so automatically the ldap verification is also made for this external domains and will fail as they are not on the local exchange cluster.
you would assume that all backend mail server would expose ldap which is not the case.

i came up with a solution now. i dont know if it reliable:
1) rule with prio 99 to reject all non ladap users (which is testet and works)
2) rule with prio 100 where we accept all mails for the exeternal domains (in a list created in the who objects)

as i understand first should all other rules match (quarantaine etc.) and finaly the accept rule for the external relay. i hope this way it will work. still a little bit compicate. but ok the advantage of pmg is that it is powerfull for handling every crazy idea.
 
to answer the receiver verification: should the pma directly generate a 5.7 with propiate error message or is it a bounce message?
 
Sep 21 22:45:15 mailgw02 postfix/cleanup[9439]: E7281A143E: message-id=<20200921204514.E7281A143E@mailgw02.exchange.at>
Sep 21 22:45:15 mailgw02 postfix/qmgr[9344]: E7281A143E: from=<double-bounce@mailgw02.exchange.at>, size=251, nrcpt=1 (queue active)
Sep 21 22:45:20 mailgw02 postfix/smtp[9359]: E7281A143E: to=<blahh@velartis.at>, relay=10.0.117.21[10.0.117.21]:25, delay=5.3, delays=0.12/0/0.11/5.1, dsn=2.1.5, status=deliverable (250 2.1.5 Recipient OK)
Sep 21 22:45:20 mailgw02 postfix/qmgr[9344]: E7281A143E: removed

this double-bounce messages are normal when the receivers check is on?
the backend is a exchange 2016. making ldap to this adress will fail as it does not exist... very strange
 
felipe said:
this double-bounce messages are normal when the receivers check is on?
Click to expand...
AFAIR this is the from-address postfix uses for recipient verification - so it should be related to the verification (you would need to examine the complete log to get a clearer picture)

however:
felipe said:
E7281A143E: to=<blahh@velartis.at>, relay=10.0.117.21[10.0.117.21]:25, delay=5.3, delays=0.12/0/0.11/5.1, dsn=2.1.5, status=deliverable (250 2.1.5 Recipient OK)
Click to expand...
here the status for blahh@ is reported as existing by 10.0.117.21 - so I guess that the configuration of that server is not correct/compatible with recipient verification (it needs to respond with a 5xx code on the RCPT TO command with a non-existing address)

I hope this helps!
 
i solved this problem. If you want, I can write something about what you can do ...

post filter >>who object>> create >> LDAP unknown user

and

add >>>>LDAP grubu>>>> Unknown LDAP adress and profile >>>Your Ldap
.
.
.
Post Filter >>>Rule>>>> add >>>>
Name: Not Users LDAP block (write )
Priority: 98
Direction: İN
Active : Tick

>>>>Ok
.
.
And
Select Not Users LDAP block >>>from the right section (Using Object) >>>> action object : Block and >>> who object : Ldap Unknown address

from the right section ...you can ask where you hang out.
 
sametileli said:
i solved this problem. If you want, I can write something about what you can do ...

post filter >>who object>> create >> LDAP unknown user

and

add >>>>LDAP grubu>>>> Unknown LDAP adress and profile >>>Your Ldap
.
.
.
Post Filter >>>Rule>>>> add >>>>
Name: Not Users LDAP block (write )
Priority: 98
Direction: İN
Active : Tick

>>>>Ok
.
.
And
Select Not Users LDAP block >>>from the right section (Using Object) >>>> action object : Block and >>> who object : Ldap Unknown address

from the right section ...you can ask where you hang out.
Click to expand...

thanks. i did that allready. but this also blocks all emails forwarded to other server which do not have LDAP auth. (we have note only 1 exchane server behind it)
i am also experimenting with complicated rulsets to avoid this. first make all spam check going to this servers then mark them as accepted and then continue with LDAP checks and spam list checksfor the exchange cluster. i will se later if this works.

what i still dont like ist that i cant change the defaul block message (as a template or add a second one) but maybe thats the way postifx works. before we where using exim ...
 
  • Like
Reactions: sametileli
Stoiko Ivanov said:
AFAIR this is the from-address postfix uses for recipient verification - so it should be related to the verification (you would need to examine the complete log to get a clearer picture)

however:

here the status for blahh@ is reported as existing by 10.0.117.21 - so I guess that the configuration of that server is not correct/compatible with recipient verification (it needs to respond with a 5xx code on the RCPT TO command with a non-existing address)

I hope this helps!
Click to expand...

i was thinking about that. tomorrow my exchange colleague will check that.
 
  • Like
Reactions: sametileli
I made this setting only for incoming mails. I did not enter settings for outgoing mails. and this rule cuts all non-ldap users now
 
sametileli said:
I made this setting only for incoming mails. I did not enter settings for outgoing mails. and this rule cuts all non-ldap users now
Click to expand...

yes for us its also only "incomming" but we have differnet backend servers. one is our exchange cluster and others are on site mail servers....(configured in the transports tab)

INTERNET <-> PMG <----> EXCHANGE SERVER, OTHER MAILSERVER1, OTHER MAILSERVERX where only the exchange can do LDAP!
so OTHER MAILSERVER1, OTHER MAILSERVERX will fail in this setup because they have no ladap!
 
I think there is ldap on the exchange server. Do you have ldap on other servers as well? (server1 and server x)
 
HI,

ew changed the Exchange config and now recipient veryfication works, But it still sucks that the tracing center is then spamed with double-bounce messages. It should be possible to filter this messages away.

Also i got the LDAP way working. A little bit complicate the rules (as now we need all rules twice to bypass the non LDAP Doomains / Serves) but its working. But also here i dont like that the reject generates generic Error messages with "rejected for policy reasons" and i have to make an extra info mail to the sender. So he will get 2 mails thats not nice.
It should not be so difficult to add a bounce action which can change the text similar to the info messages or make a extra bounce action just for not existing emails.
 
We are having the same problem with multiple Mailservers running behind Proxmox and only some of them with LDAP Support. So some domains will need LDAP verification and others not.

Unfortunately, the other way with the option “Verify Receivers” does also not work. Because it can only be enabled globally and not for only some of our relay domains.

Because not all of the Mailservers behind Proxmox are under our control, LDAP with all Servers does not work and a correct “Verify Receivers” setup for all Mailservers is also not doable.

After reading many postings in the proxmox forum, we are testing now with the following Mail Filter configuration with LDAP but it seems not to work reliable:
1) User Management -> LDAP -> add a LDAP configuration 2) Mail Filter -> Who Object -> LDAP Group -> Match “Unknown LDAP address, any profile” 3) Mail Filter -> What Object -> Match Field -> Field: “to”, Value: “domain.com” 4) Mail Filter -> Add Rule -> Direction “In” -> Used Objects -> Action: Block, To: (see 2), What: (see 3)

Sometimes it works and mails are blocked and sometime not. Weird!

@felipe: How did you got it working?
A pmgdb dump with your rules would be nice!

Thanks!
 
@frank1

we just made a new who object: lets say "nonldap" and add all non ldap domains in this object.
after this we copied all rules we allready had IN FRONT of the existing rules (higher number) and added the who object "nonldap" to all of these rules.
finally the last "nonldap" rule BEFORE any other rule for ldap servers we add an accept rule so the mails are not treated any more and are sent to the mailservers. after this all not matching domains (ldap) will go on with there rules and get verified etc...

not very beautiful because of double rules.. but for us the only way to go...
 
You must log in or register to reply here.
Top Bottom