rules per user?

Here in my MX cluster I have a setting in POSTFIX that allows me to enable filters per domain

EX:

domain A with RBL and GRAYLIST
domain B with RBL ONLY
C domain with GREYLIST only

Everything managed by Mysql

This feature would be extremely useful in PMG,
perhaps the lack of this will prevent me from abandoning my current cluster and migrating 100% to PMG
 
dcsapak said:
there are user black and whitelists (see https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_whitelist_overview) but you can also
create rules in the rulesystem that have a specific recipient as 'TO' object and a white/blacklist 'FROM' object
Click to expand...

Can you expand on use cases for the user white/black list (4.4.3. User White-/Blacklist) under administration user white/blacklist?

What specific users is this referring to? Assuming its referring to PMG users, I tried adding an email to the root account then setting up a blacklist to block to it from a particular address, with unsuccessful results (email came through).
 
das1996 said:
Can you expand on use cases for the user white/black list (4.4.3. User White-/Blacklist) under administration user white/blacklist?

What specific users is this referring to? Assuming its referring to PMG users, I tried adding an email to the root account then setting up a blacklist to block to it from a particular address, with unsuccessful results (email came through).
Click to expand...
a 'user' in this context is an internal recipient (so every mail address that gets mail to one of the relay domains)

is there anything else unclear?
 
Sorry, still unclear. Define internal recipient.

IE, PMG is configured to relay messages to an internal email server handling mail for "mydomain.com". I configure user1@mydomain.com as a black list entry in PMG under this context (administration user blacklist). Send an email from outside (hotmail/gmail/etc) to user1@mydomain.com. It comes through unblocked.

Maybe this context use case will be clearer if you can give an example?

Thank you
 
in this case 'user1@mydomain.com' would be such an internal recipient (any '*@mydomain.com' would be)

in the user white/blaclist administration panel there is an 'email' field. with this you can select which blacklist to edit (e.g. if you put in user1@mydomain.com you edit user1's black/whitelist) after you selected that you can add/remove entries in this list
when spam checking the entries in the list get extra (or minus in case of whitelist) spam points
 
I must be doing something wrong then as its still letting messages through.

1690909714341.png

user1@domain.com is a mailbox on the local server sitting behind PMG. *@aol.com is what should be blocked.

Test message from an aol account gets accepted and delivered.
 
can you post the logs of such an email as well as your rule system?
 
Start with the last. Everything under mail filter/rules (at the top) is all turned off. I see something in there about default-accept, but mentioned, all rules are disabled. Only the admin/user blacklist is defined. Which brings back the original question; under what circumstances is the admin/white-black lists applied?

Log for the aol email;

pochta2 - PMG
pochta - mail server behind pmg
sender@aol.com - sending user, email generated at aol.com (should be blacklisted)
user1@domain.com - user with mailbox on pochta

Code: 
2023-07-31T12:37:04.580722-05:00 pochta2 postfix/smtpd[9104]: connect from sonic303-2.consmr.mail.bf2.yahoo.com[74.6.131.41]
2023-07-31T12:37:04.761595-05:00 pochta2 postfix/smtpd[9104]: Anonymous TLS connection established from sonic303-2.consmr.mail.bf2.yahoo.com[74.6.131.41]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
2023-07-31T12:37:05.219842-05:00 pochta2 postfix/smtpd[9104]: 35A6720920: client=sonic303-2.consmr.mail.bf2.yahoo.com[74.6.131.41]
2023-07-31T12:37:05.281199-05:00 pochta2 postfix/cleanup[9108]: 35A6720920: message-id=<92bf23a5-0532-186b-5b81-c07252ecf06e@aol.com>
2023-07-31T12:37:05.282345-05:00 pochta2 postfix/qmgr[4173]: 35A6720920: from=<sender@aol.com>, size=5155, nrcpt=1 (queue active)
2023-07-31T12:37:05.312803-05:00 pochta2 postfix/smtpd[9104]: disconnect from sonic303-2.consmr.mail.bf2.yahoo.com[74.6.131.41] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
2023-07-31T12:37:05.328299-05:00 pochta2 pmg-smtp-filter[8168]: 405F164C7F1414F49C: new mail message-id=<92bf23a5-0532-186b-5b81-c07252ecf06e@aol.com>#012
2023-07-31T12:37:05.346928-05:00 pochta2 postfix/smtpd[9113]: connect from localhost.localdomain[127.0.0.1]
2023-07-31T12:37:05.348161-05:00 pochta2 postfix/smtpd[9113]: 54FA620941: client=localhost.localdomain[127.0.0.1], orig_client=sonic303-2.consmr.mail.bf2.yahoo.com[74.6.131.41]
2023-07-31T12:37:05.392469-05:00 pochta2 postfix/cleanup[9108]: 54FA620941: message-id=<92bf23a5-0532-186b-5b81-c07252ecf06e@aol.com>
2023-07-31T12:37:05.394251-05:00 pochta2 postfix/qmgr[4173]: 54FA620941: from=<sender@aol.com>, size=5357, nrcpt=1 (queue active)
2023-07-31T12:37:05.394493-05:00 pochta2 pmg-smtp-filter[8168]: 405F164C7F1414F49C: accept mail to <user1@domain.com> (54FA620941) (rule: default-accept)
2023-07-31T12:37:05.394870-05:00 pochta2 postfix/smtpd[9113]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5
2023-07-31T12:37:05.395850-05:00 pochta2 pmg-smtp-filter[8168]: 405F164C7F1414F49C: processing time: 0.069 seconds (0, 0.017, 0)
2023-07-31T12:37:05.396126-05:00 pochta2 postfix/lmtp[9109]: 35A6720920: to=<user1@domain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.53, delays=0.42/0/0.04/0.07, dsn=2.5.0, status=sent (250 2.5.0 OK (405F164C7F1414F49C))
2023-07-31T12:37:05.396185-05:00 pochta2 postfix/qmgr[4173]: 35A6720920: removed
2023-07-31T12:37:05.399788-05:00 pochta2 postfix/smtp[9114]: Trusted TLS connection established to pochta.domain.com[10.10.55.10]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)
2023-07-31T12:37:05.511606-05:00 pochta2 postfix/smtp[9114]: 54FA620941: to=<user1@domain.com>, relay=localmailserver.com[10.10.55.10]:25, delay=0.16, delays=0.05/0/0.05/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 716381C45F)
2023-07-31T12:37:05.511858-05:00 pochta2 postfix/qmgr[4173]: 54FA620941: removed
 
Last edited:
das1996 said:
Start with the last. Everything under mail filter/rules (at the top) is all turned off. I see something in there about default-accept, but mentioned, all rules are disabled. Only the admin/user blacklist is defined. Which brings back the original question; under what circumstances is the admin/white-black lists applied?
Click to expand...
ok that explains it, the user black/whitelist only is used when there is at least some spam check rule (since it influences the spam score)
 
  • Like
Reactions: das1996
SUCCESS!

I understand now (more or less). I didn't realize that white/black list was tied to spam checking rules. I don't recall seeing it in the documentation either.

In testing, the messages are indeed blocked, but not rejected/bounced at smtp level. Can that be implemented? Similar to how spf fail messages are rejected entirely?
 
das1996 said:
I understand now (more or less). I didn't realize that white/black list was tied to spam checking rules. I don't recall seeing it in the documentation either.
Click to expand...
quotes from the docs (they can be improved ofc):
When a user adds a mail address to the whitelist, the result of the spam analysis will be discarded for that recipient.
Click to expand...
For mail addresses on a user’s blacklist, the spam score will be increased by 100.
Click to expand...

das1996 said:
In testing, the messages are indeed blocked, but not rejected/bounced at smtp level. Can that be implemented? Similar to how spf fail messages are rejected entirely?
Click to expand...
for that you would have to enable 'before queue' filtering so that the rulesystem is applied before postfix finishes the smtp dialog
normally the mail is first accepted (when postscreen checks go through) and only then the mail goes through the rule system. with before queue filtering, postfix stalls until that is done and can block at smtp level
 
You must log in or register to reply here.
Top Bottom