Whitelist not working?

[Miktash]

I have added an IP subnet in "Configuration->Mail Proxy->Whitelist->IP Network (Sender)" but noticed that one of the emails, sent from an IP in this subnet, is quarantained.

How can I prevent this from happening?

 

[fluxX04]

Hi,

this section only disables e. g. Greylisting, SPF, RBL.
More info in the admin guide, 4.5.8:
https://www.proxmox.com/images/download/pmg/docs/pmg-admin-guide.pdf

You should add the subnet under Mail Filter -> Who Objects -> Whitelist - to disable mail checking.

Greetz

 

[Miktash]

Ok so I need to list them under mail filter->who objects->whitelist only?
Or do I need to leave it under configuration->mailproxy->whitelist->ip network(sender) too?

 

[fluxX04]

Hi,

a entrie under whitelist should be enough if the mail get's not blocked with spf, rbl, etc.
Just test it yourself.

Greetz

 

[zimny]

Hi,

I have whitelisted under configuration->mailproxy->whitelist and also in mail filter->who objects emails are still blocked by rbl.
Looks like this futures like white or black lists don't work at all.
This is my RBL lists: "relays.dnsbl.sorbs.net,web.dnsbl.sorbs.net,recent.spam.dnsbl.sorbs.net,escalations.dnsbl.sorbs.net,zombie.dnsbl.sorbs.net,rhsbl.sorbs.net"
I simply trying allow one email address from google and I can't at all.
I'm forwarding directly port from my firewall to PMG so really no clue why this is not working.
Any ideas?

 

[dcsapak]

I simply trying allow one email address from google and I can't at all.

in the postscreen check (which uses the rbl lists), does not have access to any information but the sender ip and helo domain so it is not possible
to have a sender email whitelisted here... if the server is not blacklisted though your config should work

 

[zimny]

Hi thank you for reply,

In PMG docs whitelist from configuration->mailproxy->whitelist is described "All SMTP checks are disabled for those entries (e. g. Greylisting, SPF, RBL, …)" which looks is incorrect.
If RBL is enabled then PMG is not honoring admin setup at all.
I think this is misconception or bug which should be addressed.

 

[dcsapak]

is described "All SMTP checks are disabled for those entries (e. g. Greylisting, SPF, RBL, …)" which looks is incorrect.

it is partially correct since the rbl checks are disabled, but only for ip entries (not sender email entries)

it is not possible at that stage to reject by email sender because this information does not exist on our side yet

would you open a bug report so that we can adapt the documentation https://bugzilla.proxmox.com ?

 

[zimny]

Hi

So do you mean then when I'm using RBL all meaning of white/black list in PMG don't have any sense?
RBL is an industry standard and effective solution, all modern email gateways can support it side by side whit white/black list functionality which is for admins who like to tune up RBL included policies.
Already give up PMG on the sending gateway functionality because is not compatible with DKIM, another example of modern email systems.

For this threat looks like I need to give up all PMG because when I'm using RBL I don't have to much to do with accepting or rejecting all incoming emails.

 

[dcsapak]

So do you mean then when I'm using RBL all meaning of white/black list in PMG don't have any sense?

no you misunderstood me

the smtp whitelist works at two stages:

1. sender server connects to pmg
2. pmg checks the ip of the sender server against the whitelist (which is the only reliable information available here), then the ip against the rbl (this is postscreen; does also some other sanity checks against spam, see man postscreen for more details)
3. if allowed, the sender sends the email
4. now the smtpd checks against the whitelist again, this time with all information available (sender/receiver, domain, etc.) also spf checks and such happen here

i hope now it is more understandable which checks happen at which stage

 

[zimny]

Hi Dominik,

Thank you for this clarification. Now I can see all process and where is the problem. It's still the problem!
How PMG admin can maintain SMTP IP senders list :-O Providers like google etc periodically changing all network range for their outgoing traffic.
Why other solutions are not affected like PMG is?
It's simple and reliable solution where one IT dep manage all company emails but not to outside world
Gmail simple sample.
Hoe I can use RBL and still getting some gmail emails???

Thank you for your support,
Marcin

 

[dcsapak]

How PMG admin can maintain SMTP IP senders list :-O Providers like google etc periodically changing all network range for their outgoing traffic.

i doubt that the ip addresses of big providers are on blacklists for extended periods on time...
did you encounter such a mail? if yes, some log would be very interesting

you can of course disable the rbl checks on for postscreen since spamassassin also checks some rbls later in the chain
but it will be much slower since then all mails from spammers have to be received before stopping them...
(you can also configure when/how the specific checks are done in postfix, but this involves manually writing the master/main.cf in our templates and is a rather advanced topic)

 

[zimny]

HI

Exactly, so no white/black list functionality when RBL is involved.
I give you good example already just try to send some test email from google to your PMG and use authority Like SORBS is.

I think this is a huge gap betwen PMG and other email gateways.

I use Proxmox PVE from years and for me there is no better competitor in OpenSource regard to virtualization.
So I give a go to PMG just to have all in the "house".

Almost every day I'm loosing the point to use it.
Fortunately in my envy when I got this filtering issues with PMG I was able to switch to another server/solution but I'm wondering how many admins and up in the phone calls like "We tried but can't send email to you -> is saying we are spammers", just because admin like to use RBL functionality in PMG.

If not workarounds maybe you can update if PMG will sort out this in future? If not then not worth to keep PMG server in the net.

Thank you

 

[Stoiko Ivanov]

Exactly, so no white/black list functionality when RBL is involved.

No.
If you chose to configure RBL on the MailProxy - you need to white/black-list the IP-ranges as well in the default configuration.
If you do not want to keep IP ranges additionally you can, as Dominik already pointed out, modify the postfix config and replace the postscreen-tests, by checks in smtpd (see smtpd_recipient_restrictions (`man 5 postconf`, http://www.postfix.org/SMTPD_ACCESS_README.html and https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_service_configuration_templates (for the adaptation of the config in PMG))

I give you good example already just try to send some test email from google to your PMG and use authority Like SORBS is.

I probably would not rely (solely) on SORBS - see e.g. https://en.wikipedia.org/wiki/Spam_and_Open_Relay_Blocking_System#False_positives

As another workaround you can just not do rbl-checks on the postfix level - and rely on SpamAssassin's checks only - in that case you need to configure the black-/whitelist in the rulesystem ('Mail Filter' in the GUI)

Given that the current setup with postscreen seemingly works for most users, and since it gives quite an advantage in performance I don't see it as a priority to change it.

I hope this helps!

 

[zimny]

No.
If you chose to configure RBL on the MailProxy - you need to white/black-list the IP-ranges as well in the default configuration.
If you do not want to keep IP ranges additionally you can, as Dominik already pointed out, modify the postfix config and replace the postscreen-tests, by checks in smtpd (see smtpd_recipient_restrictions (`man 5 postconf`, http://www.postfix.org/SMTPD_ACCESS_README.html and https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_service_configuration_templates (for the adaptation of the config in PMG))


I probably would not rely (solely) on SORBS - see e.g. https://en.wikipedia.org/wiki/Spam_and_Open_Relay_Blocking_System#False_positives

As another workaround you can just not do rbl-checks on the postfix level - and rely on SpamAssassin's checks only - in that case you need to configure the black-/whitelist in the rulesystem ('Mail Filter' in the GUI)

Given that the current setup with postscreen seemingly works for most users, and since it gives quite an advantage in performance I don't see it as a priority to change it.

I hope this helps!

I'm shocked with your reply/advise.
I get the idea of white/black list after RBL just to allow emails which you like to be in control.
But I'm completely lost with your idea "white list IP of SMTP servers".
I give you an example Gmail
how you like to setup PMG to use RBL and in the same time receive some emails from gmail.

[SORBS]
You are concern about most authoritative organization in net?

 

[heutger]

I'm shocked with your reply/advise.
I get the idea of white/black list after RBL just to allow emails which you like to be in control.
But I'm completely lost with your idea "white list IP of SMTP servers".
I give you an example Gmail
how you like to setup PMG to use RBL and in the same time receive some emails from gmail.

[SORBS]
You are concern about most authoritative organization in net?

There are three stages of Antispam:

1. You can reject mails, which fail to comply with RFC requirements - that should only be used to kick away the most hard stupid spam, you should also negotiate here, how hard you want to be as there are too much lame administrators out there, which are not able to set up their servers reliable, so e.g. you should consider not to enable SPF (as this technique has many problems, is not widely adopted yet and because of that, many SPF records are outdated or worse updated as well as mailing lists, group lists etc. will fail too), you should not enable FCrDNS checks (so full client host check) in PMG as many operators of mail servers are not aware of how to set forward and reverse DNS pointers, ... - again, it's just to remove the hardest trash
2. RBL are for rejecting really well known spammers - there are different lists with different qualities, you can check my Advancing PMG Thread as well as my Blacklist Optimization thread, there are so much blacklists out there, you can't count them (sure, you can, but you will end up in a number with high 3 digits). You may check multirbl.valli.org therefor, you will see most of the lists there. You can then try out some IPs (e.g. of Google, Microsoft, Amazon, Mailchimp, Facebook, Linkedin etc.), you will find many of them on many blacklists, which just work with e.g. spam traps, so if any time any service will send a mail to this spam trap (and there are bad guys either on Google, Microsoft, Amazon (SES), Mailchimp, as well as Facebook and Linkedin just sent mail to potential profiles), this IPs are blacklisted. E.g. SORBS is the most unreliable anti spam filter ever. If you depend on this "most authoritative organization in net" (same for UCEPROTECT as well), you will get lost. You may use them (as they also really have very much spam on their lists too) for tagging lateron, but you may never ever use them as blacklists as long as you would like to be reachable by most users of the internet. SORBS still have this problems for years, so I only use one of their lists for blocking, which really does not contain any false positives. There recently was a really good website showing false positives against hits, but it's offline because of GDPR. However, this website is really very conservative, you can't trust the false positive numbers as they are much too low, but if they also have false positives listed for a list, you can be sure, it has really really much false positives: https://www.intra2net.com/de/support/antispam/
3. Content filtering is the most important step after removing the "well known" trash. Here you can use SORBS, here you can use additional schemes and you can optimize it with learning spam and ham to the bayes database.

For stage 2 and 3 you can handle different whitelists, stage 2 (as RBL is based on IP (usually, if you're adjusting PMG via shell, you can add(!) also domain check, but you won't remove IP check, if you want a valuable stage 2 filter)) is only IP based, stage 3 is also domain based. However, you may consider there are reasons why Gmail may change (wasn't aware off but makes sense) their IPs such often, as if the old IPs have been "burned" to be on too much backlists (and there are not only daily or hourly blacklists, there are also blacklists of spam last weeks, months, years, ..., so they don't "forget") their IP pool such often, as Gmail, Yahoo and Microsofts free mail services are the biggest spam sources ever as for sure most admins won't use any lists, which block their servers, so spam tagging need to be done on content level and that's much harder than just to reject a bad IP address.

 

[patefoniq]

Hi,
I experience the same problem with sorbs and Gmail. Both methods:

Configuration -> Mail Proxy -> Whitelist -> IP Network (Sender)

Mail Filter -> Who Objects -> Whitelist ->IP Network (Sender)

failed. I added all problematic Gmail IP networks to both whitelists and nothing had changed. E-mails are still blocked by RBL. It's a huge inconvenience for me due to my customers' complaints about undelivered emails from Gmail.

 

[Stoiko Ivanov]

I added all problematic Gmail IP networks to both whitelists and nothing had changed.

please open a new thread in such cases instead of replying to one which is more than one year old...

if you open a new thread please provide the mail.log which shows the behaviour