spamassin-milter + non-default-path spamc -- **runtime** spamc path specification ?

pgnd commented

2024-02-11 16:14:11 +00:00

(Migrated from gitlab.com)

i'm building spamassassin-milter from src, for a local rpm install

build's OK, and bin's good

cd /usr/local/mx/spamassassin-milter/bin/
./spamassassin-milter --version
	SpamAssassin Milter 0.4.0

my spamc is from a local spamassassin build, built in a self-contained perl local::lib env,

cd /usr/local/mx/spamassassin/perl5app/bin

./spamc --socket=/run/spamd/spamd.sock --version
	SpamAssassin Client version 4.0.0
./spamc --socket=/run/spamd/spamd.sock -K
	SPAMD/1.5 0

i.e., my spamc is not @ default path, /usr/bin/spamc.

i need to point spamassassin-milter at my spamc.

iiuc, build time config can do the trick

i modded my spamassassin-milter rpm build/install stages,

SPAMASSASSIN_MILTER_SPAMC='/usr/local/mx/spamassassin/perl5app/bin/spamc' \
PKG_CONFIG_PATH=. CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='%{build_rustflags}' cargo build -j${RPM_BUILD_NCPUS} -Z avoid-dev-deps

&

SPAMASSASSIN_MILTER_SPAMC='/usr/local/mx/spamassassin/perl5app/bin/spamc' PKG_CONFIG_PATH=. CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='%{build_rustflags}' cargo install --root ${RPM_BUILD_ROOT}//usr/local/mx/spamassassin-milter --locked -j${RPM_BUILD_NCPUS} -Z avoid-dev-deps --no-track --path .

respectively.

and then, systemd launch with, e.g.,

ExecStart=/usr/local/mx/spamassassin-milter/bin/spamassassin-milter --verbose \
 --trusted-networks '' \
 --max-message-size 100000000 \
 --reject-spam \
  --reply-code '550' \
  --reply-status-code '5.7.1' \
  --reply-text 'Service unavailable; REJECTED: Message Content - NOT DELIVERED' \
 unix:/run/spamassassin-milter/spamassassin-milter.sock \
--socket=/run/spamassassin-milter/spamassassin-milter.sock \
--headers \
--log-to-stderr \
--no-safe-fallback \
--max-size=10000000

unfortunately, received messages (on a postfix + spamassassin + spamassassin-milter setup) are REJECTed, failing @

Feb 11 10:10:22 devtest spamassassin-milter[1560]: 4TXrcZ5qH4z5w: failed to complete spamc communication: spamc exited with status code 74

which, according to

https://spamassassin.apache.org/full/4.0.x/doc/spamc.html

is a rather-generic

EX_IOERR        74  input/output error

and for which I haven't yet solved for.

(1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary spamc instance?

(2) how/where do I get greater detail out of spammassin-milter + spamc re: the cause of that "status code 74" ?

i'm building spamassassin-milter from src, for a local rpm install build's OK, and bin's good ``` cd /usr/local/mx/spamassassin-milter/bin/ ./spamassassin-milter --version SpamAssassin Milter 0.4.0 ``` my `spamc` is from a local spamassassin build, built in a self-contained perl local::lib env, ``` cd /usr/local/mx/spamassassin/perl5app/bin ./spamc --socket=/run/spamd/spamd.sock --version SpamAssassin Client version 4.0.0 ./spamc --socket=/run/spamd/spamd.sock -K SPAMD/1.5 0 ``` i.e., my `spamc` is not @ default path, `/usr/bin/spamc`. i need to point spamassassin-milter at my spamc. iiuc, _build_ time config can do the trick i modded my spamassassin-milter rpm build/install stages, ``` SPAMASSASSIN_MILTER_SPAMC='/usr/local/mx/spamassassin/perl5app/bin/spamc' \ PKG_CONFIG_PATH=. CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='%{build_rustflags}' cargo build -j${RPM_BUILD_NCPUS} -Z avoid-dev-deps ``` & ``` SPAMASSASSIN_MILTER_SPAMC='/usr/local/mx/spamassassin/perl5app/bin/spamc' PKG_CONFIG_PATH=. CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='%{build_rustflags}' cargo install --root ${RPM_BUILD_ROOT}//usr/local/mx/spamassassin-milter --locked -j${RPM_BUILD_NCPUS} -Z avoid-dev-deps --no-track --path . ``` respectively. and then, systemd launch with, e.g., ``` ExecStart=/usr/local/mx/spamassassin-milter/bin/spamassassin-milter --verbose \ --trusted-networks '' \ --max-message-size 100000000 \ --reject-spam \ --reply-code '550' \ --reply-status-code '5.7.1' \ --reply-text 'Service unavailable; REJECTED: Message Content - NOT DELIVERED' \ unix:/run/spamassassin-milter/spamassassin-milter.sock \ --socket=/run/spamassassin-milter/spamassassin-milter.sock \ --headers \ --log-to-stderr \ --no-safe-fallback \ --max-size=10000000 ``` unfortunately, received messages (on a postfix + spamassassin + spamassassin-milter setup) are REJECTed, failing @ ``` Feb 11 10:10:22 devtest spamassassin-milter[1560]: 4TXrcZ5qH4z5w: failed to complete spamc communication: spamc exited with status code 74 ``` which, according to https://spamassassin.apache.org/full/4.0.x/doc/spamc.html is a rather-generic ``` EX_IOERR 74 input/output error ``` and for which I haven't yet solved for. (1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary `spamc` instance? (2) how/where do I get greater detail out of spammassin-milter + spamc re: the cause of that "status code 74" ?

pgnd commented

2024-02-11 17:33:50 +00:00

(Migrated from gitlab.com)

fwiw,

cd /usr/local/mx/spamassassin/perl5app/bin/
./spamc --socket=/run/spamd/spamd.sock -y \
< ./sample-spam.txt
	GTUBE,SHORTCIRCUIT

suggests that spamc is healthy enough to address directly, and that the issue lies between it & milter ...

fwiw, ``` cd /usr/local/mx/spamassassin/perl5app/bin/ ./spamc --socket=/run/spamd/spamd.sock -y \ < ./sample-spam.txt GTUBE,SHORTCIRCUIT ``` suggests that `spamc` is healthy enough to address directly, and that the issue lies between it & milter ...

pgnd commented

2024-02-11 17:46:55 +00:00

(Migrated from gitlab.com)

the 'error 74' was pebkac.

pointing at the wrong socket end ...

changing

     unix:/run/spamassassin-milter/spamassassin-milter.sock \
-    --socket=/run/spamassassin-milter/spamassassin-milter.sock \
+    --socket=/run/spamd/spamd.sock \

fixes that.

leaving,

"(1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary spamc instance?"

the 'error 74' was pebkac. pointing at the wrong socket end ... changing ``` unix:/run/spamassassin-milter/spamassassin-milter.sock \ - --socket=/run/spamassassin-milter/spamassassin-milter.sock \ + --socket=/run/spamd/spamd.sock \ ``` fixes that. leaving, "(1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary spamc instance?"

pgnd commented

2024-02-11 17:47:27 +00:00

(Migrated from gitlab.com)

changed title from spamassin-milter + non-default-path spamc {-failing with "status code 74"-} ? to spamassin-milter + non-default-path spamc {+-- runtime spamc path specification+} ?

changed title from **spamassin-milter + non-default-path spamc {-failing with "status code 74"-} ?** to **spamassin-milter + non-default-path spamc {+-- **runtime** spamc path specification+} ?**

glts commented

2024-02-12 07:59:05 +00:00

(Migrated from gitlab.com)

(1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary spamc instance?

There isn’t. I don’t remember if there is a specific reason for this (security?). One thing you could try is export SPAMASSASSIN_MILTER_SPAMC=spamc, then the milter will use the first spamc it finds in its execution environment (env variable PATH).

> (1) is there runtime, not @ build, config support in spamassin-milter for pointing at an arbitrary `spamc` instance? There isn’t. I don’t remember if there is a specific reason for this (security?). One thing you could try is export `SPAMASSASSIN_MILTER_SPAMC=spamc`, then the milter will use the first `spamc` it finds in its execution environment (env variable `PATH`).

pgnd commented

2024-02-12 13:45:48 +00:00

(Migrated from gitlab.com)

One thing you could try is export SPAMASSASSIN_MILTER_SPAMC=spamc, then the milter will use the first spamc it finds in its execution environment (env variable PATH).

i do see in CHANGELOG.md,

...
## 0.2.0 (2021-08-26)
...
* (defaults change) Invoke `spamc` using the absolute path `/usr/bin/spamc`
  (instead of any executable named `spamc` in the search path). To customise
  this, set the environment variable `SPAMASSASSIN_MILTER_SPAMC` to the desired
  path when building the application.

that it was the DEFAULT that changed

and, in src/client.rs,

...
impl Spamc {
    const SPAMC_PROGRAM: &'static str = match option_env!("SPAMASSASSIN_MILTER_SPAMC") {
        Some(p) => p,
        None => "/usr/bin/spamc",
    };
...

that the env var should still be used

but setting the runtime var in unit file,

Environment="SPAMASSASSIN_MILTER_SPAMC=spamc" "PATH=/path0/to/spamassassin/perl5app/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ExecStart=/path1/to/spamassassin-milter/bin/spamassassin-milter --verbose \
 --trusted-networks '' \
...

doesn't do the trick, failing with

Feb 12 08:40:40 devtest spamassassin-milter[56415]: 4TYQZc5NPxz5w: failed to start spamc: No such file or directory (os error 2)

whereas setting the buildtime var in spec file,

SPAMASSASSIN_MILTER_SPAMC='/path0/to/spamassassin/perl5app/bin/spamc' \
PKG_CONFIG_PATH=. CARGO_HOME=.cargo ... cargo build ...

does.

not clear, yet, why.
(mis)usage in unit file env ?

> One thing you could try is export SPAMASSASSIN_MILTER_SPAMC=spamc, then the milter will use the first spamc it finds in its execution environment (env variable PATH). i do see in `CHANGELOG.md`, ``` ... ## 0.2.0 (2021-08-26) ... * (defaults change) Invoke `spamc` using the absolute path `/usr/bin/spamc` (instead of any executable named `spamc` in the search path). To customise this, set the environment variable `SPAMASSASSIN_MILTER_SPAMC` to the desired path when building the application. ``` that it was the DEFAULT that changed and, in `src/client.rs`, ``` ... impl Spamc { const SPAMC_PROGRAM: &'static str = match option_env!("SPAMASSASSIN_MILTER_SPAMC") { Some(p) => p, None => "/usr/bin/spamc", }; ... ``` that the env var should still be used but setting the runtime var in unit file, ``` Environment="SPAMASSASSIN_MILTER_SPAMC=spamc" "PATH=/path0/to/spamassassin/perl5app/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ExecStart=/path1/to/spamassassin-milter/bin/spamassassin-milter --verbose \ --trusted-networks '' \ ... ``` doesn't do the trick, failing with ``` Feb 12 08:40:40 devtest spamassassin-milter[56415]: 4TYQZc5NPxz5w: failed to start spamc: No such file or directory (os error 2) ``` whereas setting the buildtime var in spec file, ``` SPAMASSASSIN_MILTER_SPAMC='/path0/to/spamassassin/perl5app/bin/spamc' \ PKG_CONFIG_PATH=. CARGO_HOME=.cargo ... cargo build ... ``` does. not clear, yet, why. (mis)usage in unit file env ?

glts commented

2024-02-12 16:41:32 +00:00

(Migrated from gitlab.com)

Hm, my suggestion was if you build with SPAMASSASSIN_MILTER_SPAMC=spamc, then at runtime you can put whatever spamc you want on the PATH. This works for me.

I vaguely remember that the current approach is deliberate, due to some security principle. I think the idea is that the milter should not be allowed to run arbitrary user-specified programs. Rather, it is the system administrator who may choose which SpamAssassin client program is used.

Is there a strong case for making this a command-line option? My inclination is not to pursue this for now.

Hm, my suggestion was if you *build* with `SPAMASSASSIN_MILTER_SPAMC=spamc`, then at runtime you can put whatever `spamc` you want on the `PATH`. This works for me. I vaguely remember that the current approach is deliberate, due to some security principle. I think the idea is that the milter should not be allowed to run arbitrary user-specified programs. Rather, it is the system administrator who may choose which SpamAssassin client program is used. Is there a strong case for making this a command-line option? My inclination is not to pursue this for now.

pgnd commented

2024-02-12 20:20:18 +00:00

(Migrated from gitlab.com)

my suggestion was if you build with SPAMASSASSIN_MILTER_SPAMC=spamc

ah, i understood

One thing you could try is export SPAMASSASSIN_MILTER_SPAMC=spamc

to export into env @ runtime.

if I (1) build w/

SPAMASSASSIN_MILTER_SPAMC=spamc

and then in unit file, (2)

Environment="PATH=/path0/to/spamassassin/perl5app/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

it, indeed, runs as intended

Is there a strong case for making this a command-line option? My inclination is not to pursue this for now.

the only issue was being able to communicate with a specific, non-system-path spamc instance WITHOUT hard-coding "another app's" bin path into the milter's rpm build .spec.

this, as above, does the trick well enough

> my suggestion was if you build with SPAMASSASSIN_MILTER_SPAMC=spamc ah, i understood One thing you could try is export SPAMASSASSIN_MILTER_SPAMC=spamc to export into env @ runtime. if I (1) build w/ SPAMASSASSIN_MILTER_SPAMC=spamc and then in unit file, (2) Environment="PATH=/path0/to/spamassassin/perl5app/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" it, indeed, runs as intended Is there a strong case for making this a command-line option? My inclination is not to pursue this for now. the only issue was being able to communicate with a specific, non-system-path spamc instance WITHOUT hard-coding "another app's" bin path into the milter's rpm build .spec. this, as above, does the trick well enough

spamassin-milter + non-default-path spamc -- **runtime** spamc path specification ? #7

spamassin-milter + non-default-path spamc -- runtime spamc path specification ? #7