Re: Adding IP to report
So there is no solution to this? Is it possible to add the IP as an argument to a rule's Describe, using something like $1 for the detected regex value? If so, how would this be implemented? An actual exemple is FREEMAIL_ENVFROM_END_DIGIT which has a description such as [sfierds31(at)gmail.com]
Re: Adding IP to report
Thanks, Matus, but that does not work. I'm looking for something that will show in the spam body or subject so I do not have to view the headers.
Adding IP to report
When receiving a report in a spam the reported rules state reason and score but it would be useful if, either on one of those rules or a separate rule (or even in the Subject) there could be a report of the final Received IP. Depending on the IP and its country of origin I sometimes block the sending IP by some method.
Re: spamd: still running as root
> yes, although --create-prefs is useless when you use --nouser-config Thanks. I'll look at the docs.
Re: spamd: still running as root
Thanks, Vincent. I hadn't spotted that.
Re: spamd: still running as root
Thanks, Matus. So nice when these little changes creep up on you. :) I have merged the new OPTIONS with my old one... OPTIONS="--create-prefs --nouser-config -4 -i 127.0.0.1 --max-children=5 --helper-home-dir=/var/lib/spamassassin -u debian-spamd" I assume that's ok.
spamd: still running as root
I have just updated Debian to Bookworm in order to install SA 4. Very few problems so far but the postfix log is giving: "spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody" I am not sure where to specify an appropriate user (and possibly how and what). Help, please? In /etc/default/spamassassin I have... OPTIONS="--nouser-config -4 -i 127.0.0.1 --max-children=5 --helper-home-dir=/var/lib/spamassassin -u debian-spamd" PIDFILE="/run/spamd.pid" CRON=1
Re: Missing Mail::SpamAssassin::Plugin::WelcomeListSubject
Thanks, Matus, I'd just realized all that. :(
Re: Missing Mail::SpamAssassin::Plugin::WelcomeListSubject
On 26/10/2023 4:03 pm, Bill Cole wrote: Your SA installation is broken. Well, I'd guessed that. WelcomeListSubject is a new module in v4, replacing WhiteListSubject. This is 3.4, so it should be referencing the old whitelist module. If you have anything referencing it in a 3.4.6 installation, you have something very wrong. The easiest fix is likely to be to remove and re-install SA. I have reinstalled SA already with no change. Oct 26 14:38:53 bristolmail spamd[121772]: config: failed to parse line, skipping, in "/etc/spamassassin/w7_whitelist.cf": whitelist_subject Barstaple House Whatever that file is, it is NOT part of the SA distribution. Consult the author of 'w7_whitelist.cf' for support of whatever configuration it includes. I know. That's one of mine. I have found that v310.pre was modified 11 Oct and now defines welcomelist not whitelist. In retrospect I now recall rtying to update white to welcome to bring it into the official nomenclature (still a stupid change!) - and discovered I'd wasted considerable time over it because 3.4 couln't cope, despite continually getting operational warnings about white and welcome. Things should NOT be altered until updated modules become available! Surely every programmer knows that. :( Anyway, thank you for putting me on the right track, Bill. I am now considering an upgrade to Debian for no other reason than to accomodate SA v4. :(
Missing Mail::SpamAssassin::Plugin::WelcomeListSubject
I have just had reason to run --lint (first time in a week) and it failed drastically. This is on an well-established postfix mail server (but currently no real users) running 3.4.6 on Perl version 5.32.1 on Debian Bullseye. Result of --lint is... Oct 26 14:39:02.888 [121778] warn: plugin: failed to parse plugin (from @INC): Can't locate Mail/SpamAssassin/Plugin/WelcomeListSubject.pm in @INC (you may need to install the Mail::SpamAssassin::Plugin::WelcomeListSubject module) (@INC contains: /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 109) line 1. with two added comments due to plugin not found. Reload just perormed gives... Oct 26 14:29:16 bristolmail spamd[9968]: spamd: server killed by SIGTERM, shutting down Oct 26 14:29:16 bristolmail spamd[9968]: spamd: cannot send SIGINT to child process [9970]: No such process Oct 26 14:29:16 bristolmail spamd[9968]: spamd: cannot send SIGINT to child process [9969]: No such process Oct 26 14:29:20 bristolmail spamd[121434]: logger: removing stderr method Oct 26 14:29:20 bristolmail spamd[121438]: plugin: failed to parse plugin (from @INC): Can't locate Mail/SpamAssassin/Plugin/WelcomeListSubject.pm in @INC (you may need to install the Mail::SpamAssassin::Plugin::WelcomeListSubject module) (@INC contains: /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 31) line 1. Oct 26 14:29:22 bristolmail spamd[121438]: zoom: able to use 530/530 'body_0' compiled rules (100%) Oct 26 14:29:23 bristolmail spamd[121438]: spamd: server started on IO::Socket::IP [127.0.0.1]:783 (running version 3.4.6) Oct 26 14:29:23 bristolmail spamd[121438]: spamd: server pid: 121438 Oct 26 14:29:23 bristolmail spamd[121438]: spamd: server successfully spawned child process, pid 121439 Oct 26 14:29:23 bristolmail spamd[121438]: spamd: server successfully spawned child process, pid 121440 Oct 26 14:29:23 bristolmail spamd[121438]: prefork: child states: IS Oct 26 14:29:23 bristolmail spamd[121438]: prefork: child states: II Oct 26 14:29:24 bristolmail spamd[121438]: spamd: server killed by SIGTERM, shutting down Oct 26 14:29:24 bristolmail spamd[121470]: logger: removing stderr method Oct 26 14:29:24 bristolmail spamd[121475]: plugin: failed to parse plugin (from @INC): Can't locate Mail/SpamAssassin/Plugin/WelcomeListSubject.pm in @INC (you may need to install the Mail::SpamAssassin::Plugin::WelcomeListSubject module) (@INC contains: /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 31) line 1. Oct 26 14:29:25 bristolmail spamd[121475]: zoom: able to use 2/2 'body_500' compiled rules (100%) Oct 26 14:29:26 bristolmail spamd[121475]: spamd: server started on IO::Socket::IP [127.0.0.1]:783 (running version 3.4.6) Oct 26 14:29:26 bristolmail spamd[121475]: spamd: server pid: 121475 Oct 26 14:29:26 bristolmail spamd[121475]: spamd: server successfully spawned child process, pid 121476 Oct 26 14:29:26 bristolmail spamd[121475]: spamd: server successfully spawned child process, pid 121477 Oct 26 14:29:26 bristolmail spamd[121475]: prefork: child states: IS Oct 26 14:29:26 bristolmail spamd[121475]: prefork: child states: II Oct 26 14:38:52 bristolmail spamd[121475]: spamd: server hit by SIGHUP, restarting Oct 26 14:38:52 bristolmail spamd[121475]: spamd: child [121477] killed successfully: interrupted, signal 2 (0002) Oct 26 14:38:52 bristolmail spamd[121475]: spamd: child [121476] killed successfully: interrupted, signal 2 (0002) Oct 26 14:38:52 bristolmail spamd[121475]: spamd: server socket closed, type IO::Socket::IP Oct 26 14:38:52 bristolmail spamd[121475]: logger: removing stderr method Oct 26 14:38:53 bristolmail spamd[121772]: plugin: failed to parse plugin (from @INC): Can't locate Mail/SpamAssassin/Plugin/WelcomeListSubject.pm in @INC (you may need to install the Mail::SpamAssassin::Plugin::WelcomeListSubject module) (@INC contains: /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 31) line 1. Oct 26 14:38:53 bristolmail spamd[121772]: config: failed to parse line, skipping, in "/etc/spamassassin/w7_whitelist.cf": whitelist_subject Barstaple House Oct 26 14:38:53 bristolmail spamd[
Re: handle_user and connect to spamd failed
Brilliant! Thank you very much, David. No warnings, no errors now. -- Dave Stiles
Re: handle_user and connect to spamd failed
On 18/10/2021 11:20 am, Matus UHLAR - fantomas wrote: spamd by default tries to find recipients' home directories and user preferences in them. try passing following option to spamd: -x, --nouser-config, --user-config Thanks. Where would I actually add that? Which file / command? > -H directory, --helper-home-dir=directory Is that the literal 'directory'? I took that to mean an actual directory. > you don't seem yo use spamass-milter See my reply above to David. > instruct spamd to connect to 127.0.0.1 Sorry, I'm not sure where to do that. I've tried as noted in the OP; I can't find anywhere else (remembering I've dropped spamfilter.sh). -- Dave Stiles
Re: handle_user and connect to spamd failed
The problem with browsing online for an answer is that everyone seems to have a different solution. Obviously, I've managed to combine two solutions. Thanks for the pointer! I've tried both types independantly now and opted for the milter, since the other one does not use any of my own regex filters. -- Dave Stiles
handle_user and connect to spamd failed
I am setting up a new postfix/dovecot/spamassassin server to replace an
outdated one. It works correctly but I have two outstanding warnings in
the logs that I would like to eliminate if possible. I have trawled
through dozens of postings online but found no resolution for either
warning. The server is debian 10 buster.
1) "spamd: handle_user (userdir) unable to find user: 'dave'"
Postfix is using dovecot to resolve users but 'dave' is not a user. The
processing completes without it but I don't know what the process is
trying to do with the user that causes this message, nor how to resolve
it. I also have this on the old server and was advised to ignore it but
this seems ill-advised: if there is a message it's there for a purpose
or is in error.
2) "spamc: connect to spamd on ::1 failed, retrying (#1 of 3):
Connection refused"
This warning appears on receipt of a message. I do not have this message
on the old server. I believe spamc is trying to connect to spamd using
ipv6, which is turned off in postfix and, as far as I can determine, in
spamassassin as well.
The options in /etc/default/spamassassin are:
OPTIONS="--create-prefs -4 --max-children 5 --helper-home-dir
/var/lib/spamassassin -u debian-spamd"
I have tried adding options to make:
OPTIONS="--create-prefs -4 --ipv4-only --max-children 5
--helper-home-dir /var/lib/spamassassin -u debian-spamd -d 127.0.0.1"
This made no difference. I also have /etc/default/spamass-milter with
the options:
OPTIONS="-u spamass-milter -i 127.0.0.1 -4"
In postfix master.cf I have:
spamfilter unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamfilter.sh -oi -f ${sender}
${recipient}
with /usr/bin/spamfilter.sh containing:
SENDMAIL=/usr/sbin/sendmail
SPAMASSASSIN=/usr/bin/spamc
MAX_MESSAGE_SIZE="-s 800"
logger <<<"Spam filter piping to SpamAssassin, then to: $SENDMAIL $@"
${SPAMASSASSIN} ${MAX_MESSAGE_SIZE} | ${SENDMAIL} "$@"
exit $?
This has been copied from the old server.
I would appreciate advice on how to remove these two errors. What other
information do you require, please?
--
Dave Stiles
Re: Screwed-up scoring
I read the thread. I didn't comment because it was obvious the rationals would lose and the unnecessary changes would go ahead. From that discussion I took away the thought that I had a long-ish breathing space which would allow me to update my complete mail server - OS, Postfix and all - and get rid of the now-likely-to-break spamassassin. I did not expect it to break within a few days! I wonder how this fiasco will affect all those who do not audit this list - surely a large number? Or any who, due to the SPF failure yesterday, missed some of the list? This whole affair has been badly mis-managed. No engineer should have behaved in this cavalier fashion for such a spurious, mis-informed reason and with such a short change-over perdiod.
Re: Screwed-up scoring
Whether or not it's the ONLY one it should have been NONE. You claimed we would not have to change anything for at least a year - as I understodd it. Certainly you should not have broken existing installations! I am running 3.4.2, dictated by my OS. I am quite happy running that version - at least, I was before the speciously argued changed that broke it. What about all the other whitelist and blacklist nomenclature in the (pre-broken) version? I have altered scores for those below. Are they also broken? Or any other that I may have missed? priority USER_IN_WHITELIST priority USER_IN_DEF_WHITELIST priority USER_IN_ALL_SPAM_TO priority USER_IN_DKIM_WHITELIST priority USER_IN_DEF_DKIM_WL priority USER_IN_SPF_WHITELIST priority USER_IN_DEF_SPF_WL priority USER_IN_BLACKLIST priority USER_IN_BLACKLIST_TO shortcircuit USER_IN_WHITELIST shortcircuit USER_IN_DEF_WHITELIST shortcircuit USER_IN_ALL_SPAM_TO shortcircuit SUBJECT_IN_WHITELIST shortcircuit USER_IN_DKIM_WHITELIST shortcircuit USER_IN_DEF_DKIM_WL shortcircuit USER_IN_SPF_WHITELIST shortcircuit USER_IN_DEF_SPF_WL shortcircuit USER_IN_BLACKLIST shortcircuit USER_IN_BLACKLIST_TO shortcircuit SUBJECT_IN_BLACKLIST
Screwed-up scoring
Thanks to those responsible for screwing up the scoring of my spamassassin installation. It's been working well for years but now my changes to scoring have been cancelled due to renaming whitelist/blacklist to whatever. I noticed it purely by accident this morning: USER_IN_WHITELIST_TO no longer gave me the expected score because it has now been replaced by USER_IN_WELCOMELIST_TO. Great. I now have to dredge up some time from somewhere to change all the other scores that have been messed up, with only the vaguest clue as to what the names are likely to be. Can someone post a list of ALL the new names, with their originals, please?
Re: Failed MIME rules with new update
Of course I do! Thanks. :)
Failed MIME rules with new update
I have several rules relating to MIME headers but after the latest
spamassassin update yesterday two of them have failed to parse. The
rules are:
mimeheader PFSA_CONTENT_TYPE Content-Type =~
/[0-9]{8,}\.xls|.*\.js|\.cab|image/png:\sname.*\.zip/i
mimeheader PFSA_MACROENABLED Content-Type =~
/^application/msword$|macroEnabled/i
Running lint gives the following:
Jan 14 10:32:40.345 [52189] warn: config: SpamAssassin failed to parse
line, "PFSA_CONTENT_TYPE Content-Type =~
/[0-9]{8,}\.xls|.*\.js|\.cab|image/png: name.*\.zip/i" is not valid for
"mimeheader", skipping: mimeheader PFSA_CONTENT_TYPE Content-Type =~
/[0-9]{8,}\.xls|.*\.js|\.cab|image/png: name.*\.zip/i
Jan 14 10:32:40.348 [52189] warn: config: SpamAssassin failed to parse
line, "PFSA_MACROENABLED Content-Type =~
/^application/msword$|macroEnabled/i" is not valid for "mimeheader",
skipping: mimeheader PFSA_MACROENABLED Content-Type =~
/^application/msword$|macroEnabled/i
These two rules have been running for years. The point of them is that
they should DETECT invalid mimeheaders of just those constructs so I'm
not sure why the rules are invalid. Any ideas as to why they suddenly
fail, please?
Re: Getting spamass-milter to work with postfix
Thanks for that. I wasn't sure which config to add it to. I now have the following in /etc/default/spamass-milter... OPTIONS="-u spamass-milter -i 127.0.0.1 -- -s 800" ... which works.
Re: Getting spamass-milter to work with postfix
Belated thans again to all who helped me with this problem. It has been running reasonably well since my last posting. I now have only a couple of minor problems left, one of which (I think) more suited to the postfix forum. The other one is max-size. I had gradually uprated this to 800 in the content filter .sh file, called via master.cf. I have tried setting it in /etc/default/spamassassin as --max-size=800 (which accepts it but ignores it) and in spamass-milter which does not accept either the long or short version (which is expected from the docs). Where should I specify this and how, please?
Re: Getting spamass-milter to work with postfix
On 24/11/2019 18:23, Bill Cole wrote: setting "smtpd_delay_open_until_valid_rcpt = no" should make it available Just tried that in main.cf, but no difference. No queue ID until after the connect line, just before the SPF tests. I wonder if the confMILTER error mitigates against it. It also occurs to me that since a high proportion of connection attempts are spammy and are dropped almost immediately there could be a higher overhead?
Re: Getting spamass-milter to work with postfix
Thank you for the explanation. Appreciated. :)
Re: Getting spamass-milter to work with postfix
On 24/11/2019 15:57, Matus UHLAR - fantomas wrote: I have explained that this was caused by receiving mail for "admin" thus spamass-milter provider username admin. Since the admin doesn't exist locally (apparently alias or remote user), spamd falled back to nobody. Then how can I get it to use the correct user each time? Obviously there can be a lot of them. The solution to confMILTER is: ignore it. That particular feature was designed for sendmail and postfix cannot support it.
Re: Getting spamass-milter to work with postfix
Almost there now. I found a reference online that said to add "-u spamd" to the end of the OPTIONS line in /etc/defauls/spamassassin and that removed the log entry... spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody The posting also said that the line... spamd: handle_user (getpwnam) unable to find user: 'admin' ... was nothing to wory about. Only thing left now, I think, is finding out where to change something to remove the startup message... Could not retrieve sendmail macro "i"! Please add it to confMILTER_MACROS_ENVFROM Again, thanks for your help. :)
Re: Getting spamass-milter to work with postfix
On 24/11/2019 14:47, Matus UHLAR - fantomas wrote: > then you have your problem fixed. More or less. It works (although not sure what will happen on reboot - will it auto-run spamass-milter and spamd?) but I am trying to clean up the remaining log entries. comment any messages when you have removed them? Removed them from where? This list? I haven't done so. I was referring to my messages which you quoted in a previous email... > spamd: connection from ::1 [::1]:55492 to port 783, fd 5 > spamd: handle_user (getpwnam) unable to find user: 'admin' > spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody > spamd: processing message for admin:65534 I assume lines 1 and 4 are the usual "connecting" comment. I am concerned about lines 2 and 3. I understand WHAT to do about line 3 but not WHERE. Whether that would also remove line 2 I do not know. I have been looking online for handle_user and found a number of postings in forums (including this one) which offer advice, but the ones I've found so far say "do this" but not where to do it, even in the official documentation. Sorry if I appear to be ungrateful - I really do appreciate all the help you and others are giving me. I've been running linux and postfix for several years but am still easily confused by a few things.
Re: Getting spamass-milter to work with postfix
On 24/11/2019 14:00, Matus UHLAR - fantomas wrote: relative to the chroot value. I repeat, no chroot involved! Otherwise, the two values are the same... main.cf unix:/var/run/spamass/spamass.sock etc/default/spamass-milter /var/run/spamass/spamass.sock > set values of SOCKETOWNER and SOCKETMODE in default/spamass-milter That's already done anyway. > wants to process mail with settings of admin user Er, in what way? Spamassassin is processing and reporting as expected apart from the messages. Are they warnings or errors? Or just ignorable comments? (And if the latter, how can they be removed from the logs - assuming they should be.)
Re: Getting spamass-milter to work with postfix
As I understand it, altering those values in default/spamass-milter should be sufficient? Those have been changed for several days now. Following a lead from elsewhere I have altered the owner to spamass-milter:postfix and the socket permissions follow it in the file manager. However, the PID file is being created with spamass-milter:nogroup and I cannot find where to change it - and does it matter in this case? In System Monitor (task manager) I'm seeing (currently) 2 spamd processes, 2 spamd-child and a spamass-milter. Is that reasonable? I'm also seeing the following in the log for each email email... spamd: connection from ::1 [::1]:55492 to port 783, fd 5 spamd: handle_user (getpwnam) unable to find user: 'admin' spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody spamd: processing message for admin:65534 ... where admin changes according to the target email address (eg james, ebay etc) - I do not understand why line 2 is seeking user: admin. Line 1 is using ipv6 - how can I force ipv4? line 3 running as root - according to default/spamassassin it seems -u is optional for spamd.pid and I'm not even sure that's what it is referring to. > communicates with spamd by localhost:783 How do I force that? What I keep looking for (and fail to find) is a list of all actions I need in order to set up spamass-milter - permissions, options, where and what etc for ubuntu. Which is why I began this thread in the first place. And why do all the other milters I'm using not have this difficulty. :(
Re: Getting spamass-milter to work with postfix
On 18/11/2019 10:46, Edda wrote:
You did not start/restart spamass-milter?
I found no mention of such a thing, although I did look and concluded
there was no such thing. This has been my problem all along: lots of
Howto Install but always missing vital bits. :(
Searching now, I found how to start the milter - it didn't work until I
ran "adduser spamass-milter:spamd". That led me to a few other things
but still not working properly, although something is working:
spamassassin runs and gives an expected output and the sequence is now:
SPF, DKIM, DMARC, SPAMD.
Then I had to find...
postconf milter_connect_macros="i j {daemon_name} v {if_name} _"
...and add that into main.cf.
However, I'm still getting a warning...
Could not retrieve sendmail macro "i"!.
Please add it to confMILTER_MACROS_ENVFROM
Haven't yet found where that is.
lsof
Gives what you suggest, although not the same details, obviously.
That's the socket for your postfix configuration (main.cf)
smtpd_milters = unix:/var/run/spamass/spamass.sock [...]
Which is what I have in main.cf
Thanks for your input. Appreciated.
Re: Getting spamass-milter to work with postfix
Thanks for the response. >> I looked into replacing unix:/var/run/spamass/spamass.sock with >> inet:localhost:783 in main.cf (which I'm pretty sure is wrong!) >> and it logged errors and refused mail. > glibc have ipv6 prefered over ipv4, so if spamd only listen on ipv4 ? > change localhost with [127.0.0.1] solves it Reason I thought it was wrong is: I thought I was actually assigning spamd when I should be assigning spamass sock. Am I wrong in that assumption? If I am I'll try it ASAP - it's a live server so I need to pick a quiet time. > ls -l drwxrwxr-x 2 postfixpostfix 40 Nov 5 19:45 spamass (nothing in folder) -- Dave Stiles
Re: Getting spamass-milter to work with postfix
Thank you for your responses. Sorry it's taken a while to reply. Bearing in mind your comments - and those of the other contributors - I now have the following setup / observations but I still can't get it to work. /etc/default/spamassassin ENABLED=1 OPTIONS="--create-prefs --maxchildren 5 -- helper-home-dir" PIDFILE="/var/run/spamass/spamd.pid" /etc/default/spamass-milter OPTIONS="-u spamass-milter -i 127.0.0.1" SOCKET="/var/run/spamass/spamass.sock" SOCKETOWNER="postfix:postfix" SOCKETMODE="0660" As I understand it, the above values over-ride those in the init.d files of relevant name, but I have in any case put the same values at the top of those files. Before the ENABLED line in /etc/default/spamassassin is a recommendation to run the command... systemctl enable spamassassin.service This results in the following... Synchronizing state of spamassassin.service with SysV init with /lib/systemd/systemd-sysv-install... Executing /lib/systemd/systemd-sysv-install enable spamassassin insserv: fopen(.depend.stop): Permission denied insserv: fopen(.depend.stop): Permission denied Failed to execute operation: Access denied ...and a perpetual failure to authenticate. I looked into replacing unix:/var/run/spamass/spamass.sock with inet:localhost:783 in main.cf (which I'm pretty sure is wrong!) and it logged errors and refused mail. By using unix:/var/run/spamass/spamass.sock in main.cf I have the warning in the log: No such file or directory.
Re: Getting spamass-milter to work with postfix
On 11/11/2019 19:23, Benny Pedersen wrote: i am confused from your first post where you show spamPd and spamD config files I posted all I could find relating to spamassassin. I missed chroot, which never occurred to me might be relevant since I've never applied it. spamPd is a smtp proxy that does not require spamD to run at all I find it confusing trying to determine what part of spamassassin IS relevant to my requirement. I was rather hoping someone could supply a basic setup that would allow spamass-milter to run with postfix, which is why I originally posted so much information. spamass-milter does not use spamPd but only spamc So how would I specify that, please? netstat -natpu Thanks for the hint. Still does not resolve my confusion concerning what else to set up, though. -- Dave Stiles
Re: Getting spamass-milter to work with postfix
> "with postfix, you may need to set up milter wocket within its chroot" Ok, but since I do NOT use chroot which should I set up, bearing in mind the other milters all run successfully? My original posting gives my setup AS FAR AS I CAN DISCOVER IT. Presumably something in it is incorrect or I have a wrong permission.
Re: Getting spamass-milter to work with postfix
On 11/11/2019 19:15, Reindl Harald wrote: because it's common sense Sorry, but that is NOT an explanation. when postfix is configured to a unix socket which is a path it needs to live within the chroot postfix is using I am not using chroot then why did you respond at all to something talking about postfix with the chroot column in master.cf not explicit disabled - default is *enabled* even when you don't now it I have not posted anything from master.cf at all. If I had it would have shown that the chroot column has "n" in it. It always has.
Re: Getting spamass-milter to work with postfix
On 10/11/2019 20:15, Benny Pedersen wrote: then use milter in postfix to inet:[127.0.0.1]:spamass-milter-port How do I find the spamass port? Is it the spamd DESTPORT? I assume I then have to add the LISTENPORT into master.cf?
Re: Getting spamass-milter to work with postfix
> with postfix, you need to set up milter wocket within its chroot. > on debian/ubuntu consult /etc/default/spamass-milter Elsewhere I've read the opposite. It does not sound reasonable anyway: clam, opendkim etc work without chroot. -- Dave Stiles
Re: Getting spamass-milter to work with postfix
I've tried altering things but the best I can get is the message: "warning: connect to Milter service unix:/var/run/spamass/spamass.sock: No such file or directory" The folder exists with the permissions postfix:postfix 0660. I have also tried spamass-milter:postfix. On restarting spamassassin, whether as a content filter or a milter, I get: "spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783" In the three spamxxx files in /etc/default I now have socket and pid as... /etc/default/spamassassin PIDFILE="/var/run/spamass/spamd.pid" /etc/default/spamass-milter OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/run/spamass/spamd.sock" SOCKET="/var/run/spamass/spamass.sock" SOCKETOWNER="postfix:postfix" SOCKETMODE="0660" /etc/default/spampd PIDFILE=/var/run/spamass/spamd.pid No matter how I start postfix and spamassassin, /var/run/spamass remains empty but spamassassin.pid is rewritten to /var/run. I am restarting using: sudo service postfix restart sudo service spamassassin restart I suspect is not spass-milter is not being started? -- Dave Stiles
Getting spamass-milter to work with postfix
I have run spamassassin as a postfix content filter (master.cf) for several years on Linux Mint (Ubuntu 16.04) but I now need to run spamass-milter instead. I have spent several hours trying to find the correct setup but those I've found are somewhat conflicting and I cannot determine which files I should modify and how. I would appreciate some help in setting up the milter. Spamassassin version: 3.4.2 Postfix version: 3.1.0 I have the following spamassassin folders/files files with the contents shown: /etc/spampd.conf (all is commented out) /etc/default/spamassassin ENABLED=0 OPTIONS="--create-prefs --maxchildren 5 -- helper-home-dir" /etc/default/spamass-milter OPTIONS="-u spamass-milter -i 127.0.0.1" /etc/default/spampd STARTSPAMPD=1 PIDFILE=/var/run/spampd.pid LISTENHOST=127.0.0.1 LISTENPORT=10025 DESTHOST=127.0.0.1 DESTPORT=10026 CHILDREN=3 USERID=spampd GRPID=spampd TAGALL=1 AUTOWHITELIST=0 LOCALONLY=1 LOGINET=0 ADDOPTS="" (do I need to include the listen/dest values or does it not matter?) (headers only given for the following three) /etc/init.d/spamassassin PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/sbin/spamd NAME=spamd SNAME=spamassassin DESC="SpamAssassin Mail Filter Daemon" PIDFILE="/var/run/$NAME.pid" export TMPDIR=/tmp ENABLED=0 OPTIONS="" NICE= . /lib/lsb/init-functions test -f /etc/default/spamassassin && . /etc/default/spamassassin DOPTIONS="-d --pidfile=$PIDFILE" (I'm confused by the line: . /lib etc - is this valid? and see below also) /etc/init.d/spamass-milter PATH=/sbin:/bin:/usr/sbin:/usr/bin NAME=spamass-milter DAEMON=/usr/sbin/spamass-milter SOCKET=/var/run/spamass/spamass.sock PIDFILE=/var/run/spamass/spamass.pid DESC="Sendmail milter plugin for SpamAssassin" DEFAULT=/etc/default/spamass-milter OPTIONS="" RUNAS="spamass-milter" CHUID="" SOCKETMODE="0600" SOCKETOWNER="postfix:postfix" /etc/init.d/spampd PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin DESC='spam checking proxy daemon' NAME='spampd' PROGRAM=/usr/sbin/spampd EXECUTABLE=/usr/bin/perl PIDFILE=/var/run/spampd.pid . /lib/lsb/init-functions USERID=spampd GRPID=spampd /etc/spamassassin/ (containing local.cf and local rules files) /usr/share/spamassassin/ (global rules files) The last one I understand I do not need to worry about and in the one before local.cf has nothing relevant to the problem. The only file that has a SOCK defined is /etc/init.d/spamass-milter. Should spamd also have a socket? Various online postings give conflicting advice. My postfix master.cf has no enabled spamassassin content. Postfix main.cf has: policy-spf_time_limit = 3600s milter_default_action = accept milter_protocol = 6 smtpd_milters = unix:/var/run/opendkim/opendkim.sock, unix:/var/run/opendmarc/opendmarc.sock, unix:/var/run/spamass/spamass.sock, unix:/var/run/clamav/clamav-milter.ctl non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock The .pid files are as below; so far, no .sock files. /var/run/spamassassin.pid (created during a postfix restart early today) /var/run/spampd.pid (created during last m/c reboot) /var/run/spamass/ (contains nothing) (permissions spamass-milter create/delete files, postfix ditto, others access only) There is a folder at /var/spool/postfix/spamass/ with the same permissions as above but also empty. All help appreciated!
