glts/spamassassin-milter
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

no connection to backend spamd ? #3

New issue
Closed
opened 2020-06-12 16:19:35 +00:00 by pgnd · 11 comments
pgnd commented 2020-06-12 16:19:35 +00:00 (Migrated from gitlab.com)
Copy link

with

	spamd -V
		SpamAssassin Server version 3.4.4
		  running on Perl 5.26.1
		  with SSL support (IO::Socket::SSL 2.067)
		  with zlib support (Compress::Zlib 2.093)

	spamc -V
		SpamAssassin Client version 3.4.4
		  compiled with SSL support (OpenSSL 1.1.1g  21 Apr 2020)

	cargo -V
		cargo 1.43.0
	rustc -V
		rustc 1.43.0

building

	cd spamassassin-milter
	git log -n1
	      1 commit 8fc2ea535f0af7d7e3368e04800b4b9210661525 (HEAD -> master, tag: 0.1.2, origin/master, origin/HEAD)
	      2 Author: David Bürgin <dbuergin@gluet.ch>
	      3 Date:   Sun Jun 7 08:52:43 2020 +0200
	      4
	      5     SpamAssassin Milter 0.1.2

	cat << EOF > milter.pc
	prefix=/usr
	libdir=/usr/lib64

	Name: milter
	Description: Sendmail Mail Filter API (Milter)
	Version: 8.15.2
	Libs: -L/usr/lib64 -lmilter
	EOF

	PKG_CONFIG_PATH=. cargo build

succeeds

	...
	Compiling milter-callback v0.2.1
	Compiling milter v0.2.1
	Compiling spamassassin-milter v0.1.2 (/usr/local/src/spamassassin-milter)
	Finished dev [unoptimized + debuginfo] target(s) in 43.71s

	/bin/cp -af \
	 target/debug/spamassassin-milter \
	 /usr/local/sbin/

	spamassassin-milter -V
		SpamAssassin Milter 0.1.2

setup,

/etc/systemd/system/sa-milter.service

	[Unit]
	Description=SpamAssassin Milter
	Wants = spamd.service
	After = syslog.target local-fs.target network-online.target spamd.service
	Before = postfix.service
	Before=sa-milter.target

	[Service]
	Type=simple
	# socket perms -> 0660
	UMask = 0117
	User=sa-milter
	Group=postfix-milter
	PIDFile=/run/sa-milter/sa-milter.pid
	ExecStart=/usr/local/sbin/spamassassin-milter \
	 -v \
	 unix:/run/sa-milter/sa-milter.sock
	Restart=on-failure

	[Install]
	WantedBy=multi-user.target

launch

	systemctl enable  sa-milter
	systemctl restart sa-milter
	systemctl status  sa-milter -l

	systemctl status  sa-milter -ln0
		● sa-milter.service - SpamAssassin Milter
		   Loaded: loaded (/etc/systemd/system/sa-milter.service; enabled; vendor preset: disabled)
		   Active: active (running) since Wed 2020-06-10 13:04:19 PDT; 2min 9s ago
		 Main PID: 50282 (spamassassin-mi)
		    Tasks: 5
		   CGroup: /system.slice/sa-milter.service
		           └─50282 /usr/local/sbin/spamassassin-milter -v unix:/run/sa-milter/sa-milter.sock

socket's available

	ls -altR /run/sa-milter
		/run/sa-milter:
		total 0
		drwxrwx---  2 sa-milter postfix-milter   60 Jun 12 08:49 ./
		srw-rw----  1 sa-milter postfix-milter    0 Jun 12 08:49 sa-milter.sock=
		drwxr-xr-x 47 root      root           1.4K Jun 12 07:25 ../

spamc config,

	spamc.conf

		--socket=/run/spamd/spamd.sock
		--headers
		--log-to-stderr
		--no-safe-fallback
		--max-size=10000000

test

	spamc < sample-spam.txt

works as expected

	journalctl -f | grep spam

		Jun 12 08:55:49 mx spamd[53623]: spamd: got connection over /run/spamd/spamd.sock
		Jun 12 08:55:49 mx spamd[53623]: spamd: checking message <GTUBE1.1010101@example.net> for root:5128
		Jun 12 08:55:49 mx spamd[53623]: spamd: identified spam (1000.0/5.0) for root:5128 in 0.0 seconds, 799 bytes.
		Jun 12 08:55:49 mx spamd[53623]: spamd: result: Y 1000 - GTUBE,SHORTCIRCUIT scantime=0.0,size=799,user=root,uid=5128,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/run/spamd/spamd.sock,mid=<GTUBE1.1010101@example.net>,autolearn=disabled,shortcircuit=spam

testing postfix receipt 1st with 'spamass-milter', the message is passed via spamc -> spamd, and rejected as expected

	tail -f /var/log/postfix/postfix.log

		Jun 12 08:35:54 mx postfix/cleanup[55741]: 49k4Z26r3Gzy7J: message-id=<89609249-581a-ed4d-dccb-880465332158@gmail.com>
		Jun 12 08:35:55 mx postfix/cleanup[55741]: 49k4Z26r3Gzy7J: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Service unavailable; Message Content blocked using Spamass-Milter; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com>
		Jun 12 08:35:55 mx postfix/postscreen-internal/smtpd[55734]: proxy-reject: END-OF-MESSAGE: 550 5.7.1 Service unavailable; Message Content blocked using Spamass-Milter; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com>

replacing spamass-milter ==> spamassassin-milter in postfix config

	master.cf

		-	-o smtpd_milters=...,unix:/run/spamass-milter/spamass-milter.sock
		+	-o smtpd_milters=...,unix:/run/sa-milter/sa-milter.sock

	systemctl restart postfix

re-testing, same message, the message is ACCEPTED, NOT rejected,

	tail -f /var/log/postfix/postfix.log

		Jun 12 09:05:00 mx postfix/postscreen-internal/smtpd[59771]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 Ok: queued as 49k5Cc2KHTzy7H; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com>

& I see only

	journalctl -f | grep spam

		Jun 12 09:05:01  mx spamassassin-milter[57646]: accepted local connection

with NO connection to backend spamd.

with ``` spamd -V SpamAssassin Server version 3.4.4 running on Perl 5.26.1 with SSL support (IO::Socket::SSL 2.067) with zlib support (Compress::Zlib 2.093) spamc -V SpamAssassin Client version 3.4.4 compiled with SSL support (OpenSSL 1.1.1g 21 Apr 2020) cargo -V cargo 1.43.0 rustc -V rustc 1.43.0 ``` building ``` cd spamassassin-milter git log -n1 1 commit 8fc2ea535f0af7d7e3368e04800b4b9210661525 (HEAD -> master, tag: 0.1.2, origin/master, origin/HEAD) 2 Author: David Bürgin <dbuergin@gluet.ch> 3 Date: Sun Jun 7 08:52:43 2020 +0200 4 5 SpamAssassin Milter 0.1.2 cat << EOF > milter.pc prefix=/usr libdir=/usr/lib64 Name: milter Description: Sendmail Mail Filter API (Milter) Version: 8.15.2 Libs: -L/usr/lib64 -lmilter EOF PKG_CONFIG_PATH=. cargo build ``` succeeds ``` ... Compiling milter-callback v0.2.1 Compiling milter v0.2.1 Compiling spamassassin-milter v0.1.2 (/usr/local/src/spamassassin-milter) Finished dev [unoptimized + debuginfo] target(s) in 43.71s /bin/cp -af \ target/debug/spamassassin-milter \ /usr/local/sbin/ spamassassin-milter -V SpamAssassin Milter 0.1.2 ``` setup, ``` /etc/systemd/system/sa-milter.service [Unit] Description=SpamAssassin Milter Wants = spamd.service After = syslog.target local-fs.target network-online.target spamd.service Before = postfix.service Before=sa-milter.target [Service] Type=simple # socket perms -> 0660 UMask = 0117 User=sa-milter Group=postfix-milter PIDFile=/run/sa-milter/sa-milter.pid ExecStart=/usr/local/sbin/spamassassin-milter \ -v \ unix:/run/sa-milter/sa-milter.sock Restart=on-failure [Install] WantedBy=multi-user.target ``` launch ``` systemctl enable sa-milter systemctl restart sa-milter systemctl status sa-milter -l systemctl status sa-milter -ln0 ● sa-milter.service - SpamAssassin Milter Loaded: loaded (/etc/systemd/system/sa-milter.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-06-10 13:04:19 PDT; 2min 9s ago Main PID: 50282 (spamassassin-mi) Tasks: 5 CGroup: /system.slice/sa-milter.service └─50282 /usr/local/sbin/spamassassin-milter -v unix:/run/sa-milter/sa-milter.sock ``` socket's available ``` ls -altR /run/sa-milter /run/sa-milter: total 0 drwxrwx--- 2 sa-milter postfix-milter 60 Jun 12 08:49 ./ srw-rw---- 1 sa-milter postfix-milter 0 Jun 12 08:49 sa-milter.sock= drwxr-xr-x 47 root root 1.4K Jun 12 07:25 ../ ``` spamc config, ``` spamc.conf --socket=/run/spamd/spamd.sock --headers --log-to-stderr --no-safe-fallback --max-size=10000000 ``` test ``` spamc < sample-spam.txt ``` works as expected ``` journalctl -f | grep spam Jun 12 08:55:49 mx spamd[53623]: spamd: got connection over /run/spamd/spamd.sock Jun 12 08:55:49 mx spamd[53623]: spamd: checking message <GTUBE1.1010101@example.net> for root:5128 Jun 12 08:55:49 mx spamd[53623]: spamd: identified spam (1000.0/5.0) for root:5128 in 0.0 seconds, 799 bytes. Jun 12 08:55:49 mx spamd[53623]: spamd: result: Y 1000 - GTUBE,SHORTCIRCUIT scantime=0.0,size=799,user=root,uid=5128,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/run/spamd/spamd.sock,mid=<GTUBE1.1010101@example.net>,autolearn=disabled,shortcircuit=spam ``` testing postfix receipt 1st with 'spamass-milter', the message is passed via spamc -> spamd, and rejected as expected ``` tail -f /var/log/postfix/postfix.log Jun 12 08:35:54 mx postfix/cleanup[55741]: 49k4Z26r3Gzy7J: message-id=<89609249-581a-ed4d-dccb-880465332158@gmail.com> Jun 12 08:35:55 mx postfix/cleanup[55741]: 49k4Z26r3Gzy7J: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Service unavailable; Message Content blocked using Spamass-Milter; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com> Jun 12 08:35:55 mx postfix/postscreen-internal/smtpd[55734]: proxy-reject: END-OF-MESSAGE: 550 5.7.1 Service unavailable; Message Content blocked using Spamass-Milter; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com> ``` replacing spamass-milter ==> spamassassin-milter in postfix config ``` master.cf - -o smtpd_milters=...,unix:/run/spamass-milter/spamass-milter.sock + -o smtpd_milters=...,unix:/run/sa-milter/sa-milter.sock systemctl restart postfix ``` re-testing, same message, the message is ACCEPTED, *NOT* rejected, ``` tail -f /var/log/postfix/postfix.log Jun 12 09:05:00 mx postfix/postscreen-internal/smtpd[59771]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 Ok: queued as 49k5Cc2KHTzy7H; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com> ``` & I see _only_ ``` journalctl -f | grep spam Jun 12 09:05:01 mx spamassassin-milter[57646]: accepted local connection ``` with NO connection to backend spamd.
glts commented 2020-06-12 18:27:14 +00:00 (Migrated from gitlab.com)
Copy link

Yes, the milters differ in their default handling of local connections. SpamAssassin Milter by default does not scan messages that arrive locally, such as when you use the sendmail command or similar. From the man page:

-t, --trusted-networks NETS
  … If this option is not used, all connections from loopback addresses are trusted.

You can disable this by trusting no networks (-t with empty string argument):

-t ''
Yes, the milters differ in their default handling of local connections. SpamAssassin Milter by default does not scan messages that arrive locally, such as when you use the `sendmail` command or similar. From the man page: ``` -t, --trusted-networks NETS … If this option is not used, all connections from loopback addresses are trusted. ``` You can disable this by trusting no networks (`-t` with empty string argument): ``` -t '' ```
glts commented 2020-06-12 18:34:19 +00:00 (Migrated from gitlab.com)
Copy link

I noticed in passing that you set a maximum message size in the spamc
config file, but not for spamassassin-milter. However, these should be
kept in sync. The man page says:

-s, --max-message-size BYTES
  … BYTES must be equal to or greater than the max size configured for
  spamc, else it is possible that the body of spam messages is truncated
  to the size configured for spamc.
I noticed in passing that you set a maximum message size in the spamc config file, but not for spamassassin-milter. However, these should be kept in sync. The man page says: ``` -s, --max-message-size BYTES … BYTES must be equal to or greater than the max size configured for spamc, else it is possible that the body of spam messages is truncated to the size configured for spamc. ```
pgnd commented 2020-06-12 19:44:39 +00:00 (Migrated from gitlab.com)
Copy link

adding

	-t ''

does the trick. in logs,

Jun 12 12:08:33 mx spamd[55721]: spamd: got connection over /run/spamd/spamd.sock
Jun 12 12:08:33 mx spamd[55721]: spamd: checking message <76c...@gmail.com> for sa-milter:5128
Jun 12 12:08:33 mx spamd[55721]: spamd: identified spam (1000.0/5.0) for sa-milter:5128 in 0.1 seconds, 4723 bytes.
Jun 12 12:08:33 mx spamd[55721]: spamd: result: Y 1000 - GTUBE,SHORTCIRCUIT scantime=0.1,size=4723,user=sa-milter,uid=5128,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/run/spamd/spamd.sock,mid=<76c...@gmail.com>,autolearn=disabled,shortcircuit=spam
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Checker-Version"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Scanned"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Flag"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Status"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-ShortCircuit"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Level"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Languages"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relay-Countries"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relays-Untrusted"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relays-Trusted"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Prev-Subject"
Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: replace header "Subject"

and received msg headers

X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on edge.example.com
X-Spam-Scanned: spamassassin at spamd.mx.example.com
X-Spam-Flag: YES
X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,SHORTCIRCUIT
	autolearn=disabled version=3.4.4
X-Spam-ShortCircuit: shortcircuit=spam status=GTUBE (spam) trigger_rule=GTUBE
X-Spam-Level: **************************************************
X-Spam-Languages: en
X-Spam-Relay-Countries: US US
X-Spam-Relays-Untrusted: [ ip=209.85.216.65 rdns=mail-pj1-f65.google.com
	helo=mail-pj1-f65.google.com by=mx.example.com ident= envfrom=
	intl=0 id= auth= msa=0 ] [ ip=1.2.3.4
	rdns=1-2-3-4.l....net. helo=mua.localhost
	by=smtp.gmail.com ident= envfrom= intl=0
	id=q1s...4 auth=ESMTPSA msa=0 ]
X-Spam-Relays-Trusted: [ ip=127.0.0.1 rdns=localhost
	helo=mx.example.com by=mx.example.com ident=
	envfrom=...@gmail.com intl=1 id=4c478z3De14f8K auth= msa=0 ]
X-Spam-Prev-Subject: test

great. thx!

I noticed in passing that you set a maximum message size in the spamc config file, but not for spamassassin-milter. However, these should be kept in sync. The man page says:

sure. for the test message, not an issue.

ideally, for me, the max-size(spamassassin-milter) == max-size(spamc)

a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf.

also, couple of add'l usage comments

(1)

the option to set the milter reject message is fairly important. e.g, in spamass,

 -C 5.7.1 \
 -R 'Service unavailable; Message Content blocked by Spamass-Milter'

(2)

the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10"

 -r 10 \

rather than just reject all or none, is useful

adding ``` -t '' ``` does the trick. in logs, ``` Jun 12 12:08:33 mx spamd[55721]: spamd: got connection over /run/spamd/spamd.sock Jun 12 12:08:33 mx spamd[55721]: spamd: checking message <76c...@gmail.com> for sa-milter:5128 Jun 12 12:08:33 mx spamd[55721]: spamd: identified spam (1000.0/5.0) for sa-milter:5128 in 0.1 seconds, 4723 bytes. Jun 12 12:08:33 mx spamd[55721]: spamd: result: Y 1000 - GTUBE,SHORTCIRCUIT scantime=0.1,size=4723,user=sa-milter,uid=5128,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/run/spamd/spamd.sock,mid=<76c...@gmail.com>,autolearn=disabled,shortcircuit=spam Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Checker-Version" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Scanned" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Flag" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Status" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-ShortCircuit" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Level" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Languages" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relay-Countries" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relays-Untrusted" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Relays-Trusted" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: add header "X-Spam-Prev-Subject" Jun 12 12:08:33 mx spamassassin-milter[55394]: 4c478z3De14f8K: rewriting header: replace header "Subject" ``` and received msg headers ``` X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on edge.example.com X-Spam-Scanned: spamassassin at spamd.mx.example.com X-Spam-Flag: YES X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,SHORTCIRCUIT autolearn=disabled version=3.4.4 X-Spam-ShortCircuit: shortcircuit=spam status=GTUBE (spam) trigger_rule=GTUBE X-Spam-Level: ************************************************** X-Spam-Languages: en X-Spam-Relay-Countries: US US X-Spam-Relays-Untrusted: [ ip=209.85.216.65 rdns=mail-pj1-f65.google.com helo=mail-pj1-f65.google.com by=mx.example.com ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=1.2.3.4 rdns=1-2-3-4.l....net. helo=mua.localhost by=smtp.gmail.com ident= envfrom= intl=0 id=q1s...4 auth=ESMTPSA msa=0 ] X-Spam-Relays-Trusted: [ ip=127.0.0.1 rdns=localhost helo=mx.example.com by=mx.example.com ident= envfrom=...@gmail.com intl=1 id=4c478z3De14f8K auth= msa=0 ] X-Spam-Prev-Subject: test ``` great. thx! > I noticed in passing that you set a maximum message size in the spamc config file, but not for spamassassin-milter. However, these should be kept in sync. The man page says: sure. for the test message, not an issue. ideally, for me, the max-size(spamassassin-milter) == max-size(spamc) a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf. also, couple of add'l usage comments (1) the option to set the milter reject message is fairly important. e.g, in spamass, ``` -C 5.7.1 \ -R 'Service unavailable; Message Content blocked by Spamass-Milter' ``` (2) the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10" ``` -r 10 \ ``` rather than just reject all or none, is useful
glts commented 2020-06-12 20:37:49 +00:00 (Migrated from gitlab.com)
Copy link

ideally, for me, the max-size(spamassassin-milter) == max-size(spamc)

a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf.

Absolutely. On the spamassassin-milter side, the purpose of the message
size limit is to be able to skip transmission of very large messages to
the spamd backend … I haven’t yet thought of a good way to keep these in
sync.

(1)

the option to set the milter reject message is fairly important.

Yes, the current reply code and message is defined here:
https://gitlab.com/glts/spamassassin-milter/-/blob/0.1.2/src/client.rs#L268-270

As noted in the comment, these choices are intentional, and follow the
RFC recommendations and style (for example, concealing the name
‘SpamAssassin’ in user-facing messages). I agree that it is easy and
perhaps sensible to make this (at least the message) customisable.

(2)

the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10"

This is a spamass-milter feature that I initially decided to leave out.
This may be useful and perhaps nice to have, but before we add this it
would be good to know more about the motivation.

Thank you for giving this a try!

> ideally, for me, the max-size(spamassassin-milter) == max-size(spamc) > > a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf. Absolutely. On the spamassassin-milter side, the purpose of the message size limit is to be able to skip transmission of very large messages to the spamd backend … I haven’t yet thought of a good way to keep these in sync. > (1) > > the option to set the milter reject message is fairly important. Yes, the current reply code and message is defined here: https://gitlab.com/glts/spamassassin-milter/-/blob/0.1.2/src/client.rs#L268-270 As noted in the comment, these choices are intentional, and follow the RFC recommendations and style (for example, concealing the name ‘SpamAssassin’ in user-facing messages). I agree that it is easy and perhaps sensible to make this (at least the message) customisable. > (2) > > the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10" This is a spamass-milter feature that I initially decided to leave out. This may be useful and perhaps nice to have, but before we add this it would be good to know more about the motivation. Thank you for giving this a try!
pgnd commented 2020-06-12 21:15:09 +00:00 (Migrated from gitlab.com)
Copy link

a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf.

Absolutely. On the spamassassin-milter side, the purpose of the message size limit is to be able to skip transmission of very large messages to the spamd backend … I haven’t yet thought of a good way to keep these in sync.

thinking 1st about 'usage'.

something like ...

as options to spamassassin-milter config

(1) -B
(2) -B /path/to/spamc.conf

if == , set spamassassin-milter value ==

if == /path/to/spamc.conf, parse the file

if "--max-size=######" exists in conf file, set spamassassin-milter value == #####
if "--max-size=" does NOT exist in conf file, or == (empty), set spamassassin-milter value == spamc default max size

the option to set the milter reject message is fairly important.

Yes, the current reply code and message is defined here:
https://gitlab.com/glts/spamassassin-milter/-/blob/0.1.2/src/client.rs#L268-270

I can certainly change it there b4 cargo build,

As noted in the comment, these choices are intentional, and follow the RFC recommendations and style (for example, concealing the name ‘SpamAssassin’ in user-facing messages). I agree that it is easy and perhaps sensible to make this (at least the message) customisable.

my personal preference is, e.g.,

	Jun 12 13:22:04 mx postfix/postscreen-internal/smtpd[61704]: proxy-reject: END-OF-MESSAGE: 554 5.7.1 [A/S]: REJECTED: (Message Content) - MSG NOT DELIVERED; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com>

that,

  • -- hides the SpamAssassin / Milter identity
  • -- provides me a quick, easy-to-read-in-logs identifier of which milter, and what the problem is
  • -- replies to the sender with something readable & understandable by "normal humans" (this is a far more common problem that you'd think ...)

rather than trying to guess at a unierally 'useful' default, it's just simpler to have the option to define the reply.

the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10"

This is a spamass-milter feature that I initially decided to leave out. This may be useful and perhaps nice to have, but before we add this it would be good to know more about the motivation.

I have split postfix instances. The 'frontend' instance handles ALL the filtering -- postscreen, milters, policy, etc.

ONLY what's passable -- fitting my policy choices -- gets sent to my 'backend' postfix instance, which then forwards locally to IMAP.

End-users subscribe to their IMAP stores, and drag mischararcerized spam in-to/out-of their Junk folders.
That action sends a forwarding message back to the front-end instance, which submits the recharacterized message to Spamassassin's Bayes learning.

Other than that user action, I want NO unneeded processing on the backend.

For all this^ to work I only 'forward' messages from front-end to back-end below a policy-defined spam-score of XX (for my 'tuned' SpamAssassin, it's = 10).

It's NOT the only way to do the learning, for sure ... but having the absolute cutoff as an option is, for my use case, a _really_useful_feature, if not an absolute requirement.

>> a 'nice to have' would be an option for spamassassin-milter to capture/use the value set in /path/to/spamc.conf. > Absolutely. On the spamassassin-milter side, the purpose of the message size limit is to be able to skip transmission of very large messages to the spamd backend … I haven’t yet thought of a good way to keep these in sync. thinking 1st about 'usage'. something like ... as options to spamassassin-milter config (1) -B <bytes> (2) -B /path/to/spamc.conf if == <bytes>, set spamassassin-milter value == <bytes> if == /path/to/spamc.conf, parse the file if "--max-size=######" exists in conf file, set spamassassin-milter value == ##### if "--max-size=" does NOT exist in conf file, or == (empty), set spamassassin-milter value == spamc default max size >> the option to set the milter reject message is fairly important. > Yes, the current reply code and message is defined here: > https://gitlab.com/glts/spamassassin-milter/-/blob/0.1.2/src/client.rs#L268-270 I can certainly change it there b4 cargo build, > As noted in the comment, these choices are intentional, and follow the RFC recommendations and style (for example, concealing the name ‘SpamAssassin’ in user-facing messages). I agree that it is easy and perhaps sensible to make this (at least the message) customisable. my personal preference is, e.g., ``` Jun 12 13:22:04 mx postfix/postscreen-internal/smtpd[61704]: proxy-reject: END-OF-MESSAGE: 554 5.7.1 [A/S]: REJECTED: (Message Content) - MSG NOT DELIVERED; from=<p...@gmail.com> to=<me@example.com> proto=ESMTP helo=<mail-pf1-f195.google.com> ``` that, - -- hides the SpamAssassin / Milter identity - -- provides me a quick, easy-to-read-in-logs identifier of which milter, and what the problem is - -- replies to the sender with something readable & understandable by "normal humans" (this is a far more common problem that you'd think ...) rather than trying to guess at a unierally 'useful' default, it's just simpler to have the option to define the reply. >> the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10" > This is a spamass-milter feature that I initially decided to leave out. This may be useful and perhaps nice to have, but before we add this it would be good to know more about the motivation. I have split postfix instances. The 'frontend' instance handles ALL the filtering -- postscreen, milters, policy, etc. ONLY what's passable -- fitting my policy choices -- gets sent to my 'backend' postfix instance, which then forwards locally to IMAP. End-users subscribe to their IMAP stores, and drag mischararcerized spam in-to/out-of their Junk folders. That action sends a forwarding message back to the front-end instance, which submits the recharacterized message to Spamassassin's Bayes learning. Other than that user action, I want NO unneeded processing on the backend. For all this^ to work I only 'forward' messages from front-end to back-end below a policy-defined spam-score of XX (for my 'tuned' SpamAssassin, it's = 10). It's NOT the only way to do the learning, for sure ... but having the absolute cutoff as an option is, for my use case, a _really_useful_feature, if not an absolute requirement.
glts commented 2020-06-14 06:34:36 +00:00 (Migrated from gitlab.com)
Copy link

All right, let’s look into customising the reply text first. Should be easy, I will push something later.

All right, let’s look into customising the reply text first. Should be easy, I will push something later.
pgnd commented 2020-06-14 16:14:19 +00:00 (Migrated from gitlab.com)
Copy link

let’s look into customising the reply text first.

great, thx!

looks like 3 params are useful:

  • reject code, e.g. "550"
  • reply code, e.g. "5.7.1"
  • response text, e.g. "looks like spam to me"

after taking a much closer look at building/installing/using other options

spamass-milter, spamc-milter, spampd, etc

i think more clearly understand why you've built this project.
there are some ... questionable choices, imo ... that've been made in the other proj's. &/or .... just really old re: tech & assumptions.

i've not used rust at all; other than to build this^.
taking a 1st look so as to be more helpful ...

> let’s look into customising the reply text first. great, thx! looks like 3 params are useful: - reject code, e.g. "550" - reply code, e.g. "5.7.1" - response text, e.g. "looks like spam to me" after taking a much closer look at building/installing/using other options spamass-milter, spamc-milter, spampd, etc i think more clearly understand _why_ you've built this project. there are some ... questionable choices, imo ... that've been made in the other proj's. &/or .... just really old re: tech & assumptions. i've not used rust at all; other than to build this^. taking a 1st look so as to be more helpful ...
glts commented 2020-06-16 09:35:00 +00:00 (Migrated from gitlab.com)
Copy link

Yeah, I’ve only used spamass-milter. It has a 20 years history or so
(and it shows) … Anyway, a pleasant surprise to see someone else try
this project, I appreciate the feedback.

Yeah, I’ve only used spamass-milter. It has a 20 years history or so (and it shows) … Anyway, a pleasant surprise to see someone else try this project, I appreciate the feedback.
pgnd commented 2020-06-18 20:10:36 +00:00 (Migrated from gitlab.com)
Copy link

the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10"

just a bit of 'measured data' ...

'tho the vast_majority of spam's dealt with before a queued message even touches spamassassin/milter, there's still a not-insignificant amount that sneaks past -- and SA deals with.

in ~ 5 days now of using this^, and (atm) not discarding with milter below a set threshhold, ~ 100-ish messages got tagged as spam > threshhold, and sent to the backend. ending up in User:Junk mail folder.

that's for just one account, atm.

most do not contain large attachments; some do. in any case, not a lot of traffic.

but it's unnecessary, and -- at scale -- will grow accordingly.

i.e., here, SA is still a necessary part of the clean-up, and "< thresshold" reject is a necessary feature.

> the option to immediately reject ONLY above a given spam threshhold, e.g. ">= 10" just a bit of 'measured data' ... 'tho the _vast_majority_ of spam's dealt with before a queued message even touches spamassassin/milter, there's still a not-insignificant amount that sneaks past -- and SA deals with. in ~ 5 days now of using this^, and (atm) _not_ discarding with milter below a set threshhold, ~ 100-ish messages got tagged as spam > threshhold, and sent to the backend. ending up in User:Junk mail folder. that's for just one account, atm. most do not contain large attachments; some do. in any case, not a _lot_ of traffic. but it's unnecessary, and -- at scale -- will grow accordingly. i.e., here, SA is still a necessary part of the clean-up, and "< thresshold" reject is a necessary feature.
glts commented 2020-06-21 07:21:33 +00:00 (Migrated from gitlab.com)
Copy link

mentioned in issue #4

mentioned in issue #4
glts commented 2020-08-11 06:18:43 +00:00 (Migrated from gitlab.com)
Copy link

The original question has been answered, and some of the issues discussed have been addressed in one way or another.

I’m closing this issue but feel free to open follow-up issues if necessary.

The original question has been answered, and some of the issues discussed have been addressed in one way or another. I’m closing this issue but feel free to open follow-up issues if necessary.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
synth-relay
0.4.0
0.3.2
0.3.1
0.3.0
0.2.1
0.2.0
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
Labels
Clear labels   
bug

   
enhancement

   
suggestion

   
support
No labels
bug
enhancement
suggestion
support
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: glts/spamassassin-milter#3
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?