Bill Cole wrote:
I'm not sure how I've not noticed before, but unless I'm missing
something, there is no way to replicate the [block,welcome]list
functionalities of the spamassassin script when using the spamc/spamd
interface.
Does anyone see it hiding somewhere that I don't?
Does anyone have any rationale for this missing functionality?
I don't expect that it would be difficult to add. (Something I've
believed every time I've taken on a coding task...)
I'm pretty sure you're doing something wrong (maybe a missing/commented
loadplugin entry somewhere? Would expect that to bite the spamassassin
script too tho), because this has been supported for a long time. On a
single standalone system, IME you'd have to go to extra effort to get
spamc/spamd to use a different config than the spamassassin script - if
it works for one, it should work for the other.
I have file-based userprefs on my personal colo server with both[1] in
use and working just fine for a long time (since early SA 2.x at least,
IIRC), spamc called from promail on delivery. Wearing my work hat we
have all three of: local configuration in /etc, local rules channel
configuration, and SQL-based userprefs also using block|welcome entries
of several types, all working just fine[2] with spamc called on delivery
from a custom local delivery agent.
I've just rechecked with SA 4 trunk, and a temporary spamd instance was
quite happy to load an existing .cf containing a loooong list of local
welcomelist entries[3], and correctly hit USER_IN_DKIM_WELCOMELIST more
or less completely fresh out of the box.
The plugins are spread around a bit:
init.pre: SPF supports welcomelist_from_spf
v3.12.pre: DKIM supports welcomelist_from_dkim
v3.20.pre: WLBLEval supports welcomelist_from[_rcvd]
welcomlist_auth seems to be some internal voodoo layered on top of
welcomelist_from_dkim and welcomelist_from_spf, at a quick rummage it
seemed to be quite happy to function and hit with *either* the SPF or
DKIM plugins enabled, modulo having suitable thing for welcomelist_auth
to be looking at.
-kgd
[1] Well, legacy whitelist_*/blacklist_*, on account of having dragged
the config along for so long...
[2] Aside from testing mail well after the fact, where it was sent
through one or another bulk mail platform that sets a ridiculously short
DKIM expiry timestamp. Which isn't SA's fault, although it would be
nice to have a command flag somewhere to force DKIM processing to be "as
of Received: timestamp" or "as of between timestamps in DKIM header" so
as to better confirm if there's even a point in adding the welcomelist_*
entry.
[3] Also technically legacy whitelist_*, but the rule and config
aliasing also worked fine.
