Mail rate limiting not enforced

[arifaziz1122]

I’m having trouble getting Virtualmin’s Mail Rate Limiting to take effect and need your help diagnosing it.

Background

• Virtualmin: Mail Rate Limiting enabled.
• UI settings: Global message limit set to 5 emails every 1 hour (testing).
• Per-domain override: kiborehost1.com configured.

What I did

• Sent 20 messages from a web script (PHPMailer).
• Observed behavior: All 20 messages were queued by Postfix and delivered immediately; the 5/hour limit was not enforced.

What I’ve already checked

• Virtualmin UI settings are saved.
• Postfix smtpd_recipient_restrictions shows: permit_mynetworks permit_sasl_authenticated reject_unauth_destination (no check_policy_service present).
• PHPmailer is currently using the local send method (sendmail binary) in the test script.
• I attempted to locate a policy daemon (pypolicyd/postfwd) but I’m not sure which one Virtualmin expects or whether it’s active.

Logs and evidence

• 20 messages from the web script were accepted and sent from the queue without any rate-limit entries in /var/log/mail.log.
• I can provide full postconf -n output and relevant log snippets on request.

Questions

1. Does Virtualmin’s Mail Rate Limiting require a specific policy daemon (pypolicyd, postfwd, or another)? Which do you recommend for Virtualmin on Ubuntu/Debian?
2. Will rate limiting apply to messages submitted via the local sendmail binary by web scripts, or must web scripts use authenticated SMTP (submission/587) to trigger smtpd policy checks?
3. If a policy daemon is required, please provide exact steps: package name, config file locations, sample policy for a global 5/hour + per-domain override, and the precise postconf/master.cf changes to make Postfix call the policy service.
4. Are there Virtualmin settings or templates that could overwrite manual Postfix changes? If so, how do I make the configuration persistent through Virtualmin updates?
5. What exact log lines should I look for to confirm a rate-limit hit when I reproduce the test?

Additional info I can supply: OS version, full postconf -n output, PHPMailer config, and sample log excerpts.

Thanks for your help — I want to ensure outbound mail from scripts is rate-limited to avoid being flagged as spam.

[calport]

Hello @arifaziz1122 and welcome to the community.

You need to give us your system info when you start a new topic. We need to know your OS and version of Virtualmin + Webmin.

Click the clipboard icon on the top right of Virtualmin’s Dashboard to copy all the info and paste it into the message in the forum.

[shoulders]

@calport is right, your system info is very important.

This is an issue have seen a few times and might be a bug.

Mail Rate Limiting broken out of the box (Ubuntu 24.04)

I think I have it. (I have not fully tested because my 3-day-old test system has been through a bunch of things that did not work… including a postfwd install and some changes to the postfix configs, non of which seemed to have resulted in any change to mail delivery at all. So this will need to be tested on an actual out-of-the-box Virtualmin to confirm for sure.) If, in this file: /etc/milter-greylist/greylist.conf I add: noauth on a line by itself…I think that can go anywhere but for …

[arifaziz1122]

|Operating System|Ubuntu 24.04 blank (64-bit)|
|Disk Space|120 GB|
|Bandwidth|2.93 TB|
|Memory|6 GB|

[ID10T]

I’d think the interface would restart/reload Postfix but you might try to do that manually and see if it helps.

[Ron_E_James_D.O]

Add:

noauth

On a line by itself in:

/etc/milter-greylist/greylist.conf

And run:

sudo systemctl restart milter-greylist

And see if that helps.

(I am not really qualified to say whether that is a good idea or not, but I think that is what worked for me.)

Incidentally a spammer with a known password got right passed the milter (even though it was set to “noauth” as described). I think that this is because the milter must count your “from address”, not the actual authenticated account sending the mail, and once the spammer authenticated he sent mail as not@the-account-he-logged-in-as.com, so the milter was working as its supposed to, just not in the way that I’d hoped.

To combat this, I have changed:

racl whitelist default

to:

racl blacklist default

At the bottom of my:

/etc/milter-greylist/greylist.conf

On the assumption that that means “If this is not something I know about, don’t accept it”.

Mail is still working this way and the milter works, only time will tell if this helps with the next known-password spammer though.

(If adding noauth to greylist.conf and restarting the milter doesn’t work for you I left myself some more detailed instructions and changed a few other things along the way. I’m don’t specifically remember what I was fixing when I did so, so they’re probably irrelevant to your system but if noauth still fails, maybe they will help.)

Ron