Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Postgrey - Old insecure Greylisting Whitelists #869

Open
shoulders opened this issue Jul 27, 2024 · 12 comments
Open

Postgrey - Old insecure Greylisting Whitelists #869

shoulders opened this issue Jul 27, 2024 · 12 comments

Comments

@shoulders
Copy link

SYSTEM INFORMATION
OS type and version Ubuntu Linux 22.04.4
Webmin version 2.111
Usermin version 2.010
Virtualmin version 7.20.2  
Theme version 21.10
Package updates All installed packages are up to date

This is an issue with the package and not directly with Virtualmin

the background

  • Postgrey is an old greylisting software which has not been updated in a while, although it works.
  • it comes with some prefilled lists, Whitelisted clients and Whitelisted recipients.
  • Whitelisted clients is filled with lots and lots on unwanted domains to be whitelisited
  • Whitelisted recipients has postmaster@ and abuse@ white listed

image

image

the issue

  • The whitelists have unwanted entires in them which i suspect spammers would know and might utilise.
  • These whitelists should be and are expected to be empty when you start a fresh server

proposed solution

On new Virtualmin installs, these lists should be purged of all entries

additional

  • Postgrey could potentially be swapped with milter as I think this is part of Virtualmin for mail rate limiting and has greylisiting capabilities milter-greylist but this is just of the top of my head.
@jcameron
Copy link
Collaborator

I'm not sure we would want to purge those lists by default, as presumably they are based on hard-won knowledge of what domains can handle greylisting and which cannot ?

@shoulders
Copy link
Author

I think one is Alibaba, they old and knackered. I can post this list here for you to have a quick scan at. They are awful.

Also the list should be empty as they are not my whitelist choices.

There are all irrelevant and the emails that are whitelisted, should not be as these are legacy emails none uses because of spam.

@shoulders
Copy link
Author

shoulders commented Jul 27, 2024

The client/domains list

https://github.com/schweikert/postgrey/blob/master/postgrey_whitelist_clients

a couple of examples, look at the dates.

# 2004-05-20: Linux kernel mailing-list (unique sender with letters)
vger.kernel.org
# 2004-06-02: karger.ch, no retry
karger.ch
# 2004-06-02: lilys.ch, (slow: 4 hours)
server-x001.hostpoint.ch

@jcameron
Copy link
Collaborator

This feels like something the owners of the postgrey package should fix!

@shoulders
Copy link
Author

I understand, but I don't think it is maintained that much. One small patch 5 months ago. Even if it was updated, the upstream package should not be adding their own list, it is like DNS poisoning and is a clear security issue.

I will add to my notes (not every one reads though) to purge this list, but I 100% feel these lists should be empty at the point of use whether this is done upstream or by Virtualmin.

It was mentioned that you guys were looking at the spam handling system at somepoint in the future, maybe to remove spamassassain it favour of something like Rspamd, maybe at this point replace postgrey. There is also milter-greylisting (i think).

@jcameron
Copy link
Collaborator

Long-term we do plan to switch to milter-greylist which hopefully had a more up-to-date list of exceptions...

@chris001
Copy link

Confirmed - there's recently been a big increase in phishing emails addressed to abuse@ and postmaster@ because the phishers know that those addresses are whitelisted so postfix will deliver them immediately, bypassing the time consuming greylist delay.

@jcameron
Copy link
Collaborator

Oh that does seem like something we should remove - exceptions for specific domains are fine, but email addresses in all domains seems risky!

@shoulders
Copy link
Author

@jcameron can I just get you to also relook at the domain list, it is completely bonkers and is also a straight security risk apart from that both these lists should be unpopulated.

But is is your call, I have added into my instructions to delete these as the should never of been added 😀

Just included 2 blank templates that either overwrite the ones there or remove the default config file copy command and place the blanks there instead.

If any of those domains do not have SPF or dkim setup I can bypass grey filtering with a simple email spoof.

Anyway I will now get off my soapbox. 😀

@jcameron
Copy link
Collaborator

jcameron commented Aug 1, 2024

I suppose we could add an option when greylisting is being setup initially to clear that list. Unless there are some domains for which entries are legitimately needed?

@shoulders
Copy link
Author

I suppose we could add an option when greylisting is being setup initially to clear that list.

if this requires the user to select the option to clear, I am not for that.

The reason is, a new admin might not understand why he has to do that so won't bother and secondly there should not nbe anything in the list

If you know that the list needs purging you can use select all and then hit purge 😄

Unless there are some domains for which entries are legitimately needed?

As far as I am concerned, there are no valid options here. I whitelisted non of them 😄

@chris001
Copy link

chris001 commented Aug 3, 2024

As far as I know, the whitelist is for well known mail domains that do not retry 30 min later after getting the greylist "busy now, try again later" response intended to frustrate bulk spam senders. Because they're not running a standard mail sender e.g. Postfix, Exim, etc. Some universities, airlines, open source mailing lists, who DIY their own SMTP mail sender.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants