On 2024-03-21 at 11:57:43 UTC-0400 (Thu, 21 Mar 2024 11:57:43 -0400)
Kris Deugau <kdeu...@vianet.ca>
is rumored to have said:
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?
Maybe you've misunderstood my question. The spamc/spamd system uses
whatever AWL or TxRep DB is configured in evaluating messages and does
the automated part of managing those. The spamassassin-run man page
refers to spamd in the description of -W, -R, and various
--{add,remove}_*list options, but I see no way that they are relevant to
spamd.
Would expect that to bite the spamassassin script too tho), because
this has been supported for a long time.
Great. Please enlighten me:
How do I feed spamc a message and tell it to add or remove all
addresses
in it to the global or user welcomelist or blocklist (using +/-
$bignum
in the AWL or TxRep list) or tell it to add or remove individual
addresses
from those lists?
There is no mechanism to do that which I have found in our documentation
or code. I have re-read the PROTOCOL document, which does not seem to
document any mechanism to manipulate the reputation DB.
The spamassassin script does these things, usually by directly accessing
file-based DBs in the local ~/.spamassassin. The strongest reason to use
spamc/spamd is to have spamd on a different machine, so you cannot
depend on the machine where spamc is running having a sane SA config or
even a fully working SA installation.
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.
On one machine, sure: you can just use the spamassassin script to work
with the same AWL or TxRep DB that spamd uses. That's not a relevant
case.
The solution I've used it is to have both the spamc and spamd machines
using the same configuration, with both having identical SA
installations and config and being able to access the same reputation
DB. That is sub-optimal.
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.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
