About #1:

*) sender domain is easy to forge, so you may receive spams from forged sender domain which is whitelisted for greylisting service.
*) How about whitelist sender IP address directly? (Concern: you will get more and more IP addresses in sql table.)
*) Or, submit sender domain to SQL table `iredapd.greylisting_whitelist_domains`, the cron job '/opt/iredapd/tools/spf_to_greylist_whitelists.py' will query SPF DNS record of this domain, and whitelist the IP addresses/networks in SPF record. (Concern: you will get more and more IP addresses in sql table, and the DNS query time by spf_to_greylist_whitelists.py will be longer - you'd better have a local DNS server on localhost or LAN.)

I forgot to introduce the new plugin in upcoming iRedAPD release: whitelist_outbound_recipient. It automatically whitelists recipient or recipient domain (configureable) for greylisting service. For example, if your user sent an email to user@gmail.com, this plugin will either whitelist 'user@gmail.com' directly (this is default setting, and it's per-user whitelists), or submit domain 'gmail.com' to SQL table 'iredapd.greylisting_whitelist_domains' and wait for the cron job 'spf_to_greylist_whitelists.py' to dump its IP addresses/networks as whitelists (again, for greylisting service, and server-wide whitelists).

How about this:

- With default greylisting behaviour, if one sender passed the greylisting service, iRedAPD stores a tracking record in sql table `greylisting_tracking` with sender, recipient, client_address, and column `passed=1` to indicate the sender from this ip address passed greylisting service.

- The idea is, how about use the IP address in this (passed) tracking record as a whitelist directly? If this sender server bypassed once, it's supposed to always pass because it will try to re-deliver email.

- If tracking record expired, another mail delivery attempt will be made by sender server, this will cause some delay as usual, but once it's bypassed, it's whitelisted again.

This way should be more effective.

Do you mean you want to whitelist the 'outside.com' directly without querying SPF record?

Default action is submitting the domain 'outside.com' to `greylisting_whitelist_domains`, then wait for `spf_to_greylist_whitelists.py`.

Already implemented before you replied:
https://bitbucket.org/zhb/iredapd/commi … 604cd57ccc

Done. In upcoming iRedAPD release with plugin 'whitelist_outbound_recipient', 3 new options available for this purpose:

# Whitelist sender directly (no SPF query).
# Requires options `WL_RCPT_LOCAL_ACCOUNT` and `WL_RCPT_RCPT` listed below.
WL_RCPT_WITHOUT_SPF = False

# Whitelist recipient directly (no SPF query) for local account:
#   - user: for the sender (per-user whitelist)
#   - domain: for the sender domain (per-domain whitelist)
#   - global: for global whitelist
WL_RCPT_LOCAL_ACCOUNT = 'user'

# Whitelist which recipient for local account
#   - user: the recipient (single email address)
#   - domain: the recipient domain
WL_RCPT_RCPT = 'user'

If possible, vacation auto-responses should not trigger a whitelist entry. However, I'm not sure how you would differentiate between auto-replies versus actual user-originated email.