Greylisting - how to "permanent" add a "trusted" sender as known?

Questions
1

Your question

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?

2

Here are direct answers to both questions:

1. Bypassing greylisting for a trusted IP (e.g., your Proxmox MailGateway)

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).

2. What does the greylist duration (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.

3

should I perhaps log a feature request?

4

I’d love to see this feature as well. In particular, the ability to whitelist gmail and other major senders would be great.

5

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.

6

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:

  1. Proxmox PMG to do the greylisting, and most obvious SPAM (the major SpamAssasin/DNSRBL/etc.) filtering and quarantining. It seems to handle quite a number already.
  2. Stalwart to use the classification from PMG to further refine/junk-folder etc. the emails that do come in (ie. aren’t the obvious SPAM) with the LLMs/etc.

Thus greylisting I’d like to turn off for the PMG relayhosts, but not the spamfiltering

7

Yes, leaving greylistFor unset disables greylisting entirely; it only runs when that value is set. It’s also skipped for authenticated sessions and for any IP on the allowed-IP list.

The allowed-IP list is the Allowed IPs section under Settings > Security in the web UI (the AllowedIp object). Adding an IP there makes it bypass greylisting and the other connecting-IP checks, so for your Proxmox front end you can either add the PMG relay IPs there, or just unset greylistFor if you’d rather PMG own greylisting entirely. Either way your spam filtering is unaffected: greylisting and spam scoring are separate, so turning greylisting off doesn’t turn off the filter. There’s still no per-sender trusted-sender allowlist for greylisting specifically, so whitelisting something like gmail by sender would need a custom RCPT-stage Sieve rule.

8

Thank you my case is the source IP I needed to bypass greylisting only.

@westfox35 is in need of the gmail senders, different issue from mine, thus the explanation for the differences between the IPs and where they are vs the From: field is really appreciated!
Thank you @stalwart