Difference between revisions of "Qpsmtpd:whitelist"
(Created page with "<span id="_top">Qpsmtpd#Plugins</span> = NAME = whitelist - whitelist override for other qpsmtpd plugins = DESCRIPTION = The '''whitelist''' plu...")
Latest revision as of 21:49, 13 April 2019
whitelist - whitelist override for other qpsmtpd plugins
The whitelist plugin allows selected hosts or senders or recipients to be whitelisted as exceptions to later plugin processing. It is a more conservative variant of Devin Carraway's 'whitelist' plugin.
To enable the plugin, add it to the qpsmtpd/config/plugins file as usual. It should precede any plugins you might wish to whitelist for.
Several configuration files are supported, corresponding to different parts of the SMTP conversation:
Any IP address (or start-anchored fragment thereof) listed in the whitelisthosts file is exempted from any further validation during 'connect', and can be selectively exempted at other stages by plugins testing for a 'whitelisthost' connection note.
Similarly, if the environment variable $WHITELISTCLIENT is set (which can be done by tcpserver), the connection will be exempt from further 'connect' validation, and the host can be selectively exempted by other plugins testing for a 'whitelistclient' connection note.
Any host that issues a HELO matching an entry in whitelisthelo will be exempted from further validation at the 'helo' stage. Subsequent plugins can test for a 'whitelisthelo' connection note. Note that this does not actually amount to an authentication in any meaningful sense.
If the envelope sender of a mail (that which is sent as the MAIL FROM) matches an entry in whitelistsenders, or if the hostname component matches, the mail will be exempted from any further validation within the 'mail' stage. Subsequent plugins can test for this exemption as a 'whitelistsender' transaction note.
If any recipient of a mail (that sent as the RCPT TO) matches an entry from whitelistrcpt, or if the hostname component matches, no further validation will be required for this recipient. Subsequent plugins can test for this exemption using a 'whitelistrcpt' transaction note, which holds the count of whitelisted recipients.
whitelist_soft also supports per-recipient whitelisting when using the per_user_config plugin. To enable the per-recipient behaviour (delaying all whitelisting until the rcpt part of the smtp conversation, and using per-recipient whitelist configs, if available), pass a true 'per_recipient' argument in the config/plugins invocation i.e.
whitelist_soft per_recipient 1
By default global and per-recipient whitelists are merged; to turn off the merge behaviour pass a false 'merge' argument in the config/plugins invocation i.e.
whitelist_soft per_recipient 1 merge 0
Whitelist lookups are all O(n) linear scans of configuration files, even though they're all associative lookups. Something should be done about this when CDB/DB/GDBM configs are supported.
Based on the 'whitelist' plugin by Devin Carraway <firstname.lastname@example.org>.
Modified by Gavin Carr <email@example.com> to not inherit whitelisting across hooks, but use per-hook whitelist notes instead. This is a more conservative approach e.g. whitelisting an IP will not automatically allow relaying from that IP.