I’m using ProxMox MailGate as a front to receive/sent emails with Stalw.art behind it to handle the users.
Now the question: how can I setup/configute servers/IPs to be “known” and not be greylisted?
As an encore: the greylist duration: is that the period the greylisted server would be forced to wait for before accepting, or the time the greylisted server would be marked as “known” and thus not be forced to wait/re-submit?
Here are direct answers to both questions:
The built-in greylisting in Stalwart does not have a standalone “IP allowlist” field. The best approach is to use the enableSpamFilter expression on MtaStageData (Settings > Security > SMTP DATA stage in the WebUI). This expression controls whether the spam filter (including greylisting) runs at all for a given connection. By default it is:
{ "enableSpamFilter": {"else": "is_empty(authenticated_as)"} }
You can extend it to also skip processing for your trusted gateway IP:
{ "enableSpamFilter": {"else": "is_empty(authenticated_as) && remote_ip != '192.168.1.10'"} }
Replace 192.168.1.10 with your Proxmox MailGateway’s IP. This will skip the entire spam filter (including greylisting) for connections from that IP.
If you only want to skip greylisting but keep the rest of the spam filter, the docs note that greylisting is implemented as part of the spam filter pipeline. The cleanest documented path for a more surgical bypass would be a custom Sieve script at the RCPT stage - see the Greylisting Sieve example for a script-based greylisting implementation where you have full control over the logic (e.g., you can add an IP whitelist check at the top of the script).
greylistFor) mean?The greylistFor value is how long a triplet (sender IP + sender address + recipient address) is held/remembered in the greylist after a successful re-delivery. In other words: once a sender successfully retries and is accepted, that triplet is considered “known” for the duration you set. Setting it to "30d" means any triplet that has passed greylisting won’t be delayed again for 30 days.
It is not the delay imposed on the first attempt – that delay is just however long it takes the sending MTA to retry (which is up to them). The duration controls the known/trusted window after passing.
Refs:
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
should I perhaps log a feature request?
I’d love to see this feature as well. In particular, the ability to whitelist gmail and other major senders would be great.
greylistFor is how long a sender/recipient pair stays “known” after the first retry gets through; it isn’t a forced wait window (standard greylist: first attempt gets a temporary 452, the retry succeeds and the pair is remembered for that period). Because the key is the sender plus recipient (not the connecting IP), your Proxmox front relay’s IP doesn’t factor into it.
There’s no built-in trusted-sender allowlist for greylisting: it’s skipped only for authenticated sessions and for IPs on the allowed-IP list. To whitelist specific senders like gmail today, the option is a custom RCPT-stage Sieve script that gates greylisting by condition (docs at RCPT stage | Stalwart ), or you disable greylisting entirely by unsetting greylistFor.
So, by just “deleting” the greylistFor to be “Unset” will disable it?
You mention the allowed-IP list Where is that set?
So the flow I’d like is:
Thus greylisting I’d like to turn off for the PMG relayhosts, but not the spamfiltering