I notice that every time i get a email i have one error reporting in "/var/log/maillog":
Jun 22 13:53:51 jenkins spamc[2802]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
followed by next line:
Jun 22 13:53:51 jenkins spamd[20736]: spamd: connection from localhost.localdomain [127.0.0.1]:37294 to port 783, fd 5
It looks like spamassassin is working because i can see traces in email headers but this error start to be annoying so i try to figure out the solution:
Create the file "/etc/mail/spamassassin/spamc.conf" (this file is not present on Centos 7) and fill with:
-d 127.0.0.1
Before the fix:
Jul 12 13:59:16 jenkins spamc[2664]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection timed out
Jul 12 13:59:16 jenkins spamd[1242]: spamd: connection from localhost.localdomain [127.0.0.1]:33463 to port 783, fd 5
Jul 12 13:59:16 jenkins spamd[1242]: spamd: setuid to cunicellus succeeded
Jul 12 13:59:16 jenkins spamd[1242]: spamd: processing message <92b5f0bf-30fd-c457-c9de-1dde6a1cbdd4@gmail.com> for cunicellus:500
Jul 12 13:59:16 jenkins spamd[1242]: spamd: clean message (-0.1/5.0) for cunicellus:500 in 0.1 seconds, 3371 bytes.
Jul 12 13:59:16 jenkins spamd[1242]: spamd: result: . 0 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM scantime=0.1,size=3371,user=cunicellus,uid=500,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=33463,mid=<92b5f0bf-30fd-c457-c9de-1dde6a1cbdd4@gmail.com>,autolearn=ham autolearn_force=no
After i applied the fix:
Jul 12 14:12:53 jenkins spamd[3448]: spamd: connection from localhost.localdomain [127.0.0.1]:52115 to port 783, fd 5
Jul 12 14:12:53 jenkins spamd[3448]: spamd: setuid to cunicellus succeeded
Jul 12 14:12:53 jenkins spamd[3448]: spamd: processing message <8ab88152-03aa-c3b3-cb6b-3fd384f5c26c@gmail.com> for cunicellus:500
Jul 12 14:12:53 jenkins spamd[3448]: spamd: clean message (-0.1/5.0) for cunicellus:500 in 0.2 seconds, 3375 bytes.
Jul 12 14:12:53 jenkins spamd[3448]: spamd: result: . 0 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM scantime=0.2,size=3375,user=cunicellus,uid=500,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=52115,mid=<8ab88152-03aa-c3b3-cb6b-3fd384f5c26c@gmail.com>,autolearn=ham autolearn_force=no
For now it works and no more errors but i would like a confirmation from you guys. If i'm not mistaken ClamAV and spamassassin are pulled from Vmin repo and not sure if you changed spamassassin as you did with ClamAV.
(OpenVZ) Centos 7 / Vmin / Wmin / Umin ... all up to date.
Comments
Just to clarify in "Spam and Virus Scanning" i have selected:
Both are up and running regardless if the fix is applied or not.
Submitted by JamieCameron on Tue, 07/12/2016 - 08:41 Comment #3
Can you post the
/etc/hostsfile from your system? I suspect thatlocalhostis mapping to an IPv6 address only.127.0.0.1 localhost.localdomain localhost localhost4.localdomain4 localhost4# Auto-generated hostname. Please do not remove this comment.
xxx.xxx.xxx.xxx jenkins.xxxxxxxx.com jenkins
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
I'm pretty sure i disabled IPv6 from everywhere but looks like it stay in "/etc/hosts". Any suggestions?
Based on that error it could be that spamd is looking first at IPv6 and then proceed with IPv4? To be honest now i'm little confused.
Submitted by JamieCameron on Tue, 07/12/2016 - 09:24 Comment #6
Try commenting out the line :
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Didnt help, the error still show up with every incoming email. Based on this link http://man.he.net/man1/spamassassin-run:
--ipv4only, --ipv4-only, --ipv4Do not use IPv6 for DNS tests. Normally, SpamAssassin will try to
detect if IPv6 is available, using only IPv4 if it is not. Use if
the existing tests for IPv6 availability produce incorrect results
or crashes.
So i try to add in "/etc/sysconfig/spamassassin" --ipv4only, --ipv4-only, --ipv4 but with same result.
This bug started with 3.4.0 when spamassassin introduced native IPv6 support. So far only solution that works is one mentioned in my first post, the rest do nothing.
Submitted by andreychek on Tue, 07/12/2016 - 10:07 Comment #8
Re-reading your initial post -- just a heads up that SpamAssassin comes from CentOS:
http://mirror.centos.org/centos/7/os/x86_64/Packages/spamassassin-3.4.0-...
ClamAV we do indeed provide, though we grabbed that from EPEL, and provide it essentially as-is (I believe -- I've asked Joe for more input there).
I'll look into whether anyone else has filed bugs with CentOS about that, I'm curious if others are seeing that same problem.
I'll look into whether anyone else has filed bugs with CentOS about that,When i was looking for alternative solution i think i saw quite a lot people with same or similar problem so i'm sure someone filled bug report. For now i'm going back to my first solution but it would be nice if Joe can take a look and see if something else can be done.
Submitted by andreychek on Tue, 07/12/2016 - 10:31 Comment #10
I only asked Joe about ClamAV packaging details for CentOS. We hadn't run into the issue you're describing there with SpamAssassin, though I'll look deeper into that to see what we can figure out.
Submitted by andreychek on Tue, 07/12/2016 - 10:36 Comment #11
Out of curiosity, when not using the "-d" parameter you added, what does this command on your system show:
netstat -an | grep :783On our CentOS 7 system here, that shows the following:
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTENtcp6 0 0 ::1:783 :::* LISTEN
Also, what is the output of "iptables -L -n"?
With ClamAV there are two bugs with Centos 7
First problem can be fixed by starting manually (SSH) ClamAV and second can be fixed to go in "Bootup and Shutdown" and change settings for ClamAV daemon. But Joe said this should be fixed with next Vmin version.
This problem is entirely connected with SpamAssassin and only today i notice this error. Looking at old logs it was present all the time.
[root@jenkins ~]# netstat -an | grep :783tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN
Keep in mind that i applied my first solution so tcp6 will not show up.
[root@jenkins ~]# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
f2b-apache-livewhale all -- 0.0.0.0/0 0.0.0.0/0
f2b-wordpress all -- 0.0.0.0/0 0.0.0.0/0
f2b-postfix-sasl all -- 0.0.0.0/0 0.0.0.0/0
f2b-dovecot all -- 0.0.0.0/0 0.0.0.0/0
f2b-postfix-rbl all -- 0.0.0.0/0 0.0.0.0/0
f2b-postfix all -- 0.0.0.0/0 0.0.0.0/0
f2b-proftpd all -- 0.0.0.0/0 0.0.0.0/0
f2b-webmin-auth all -- 0.0.0.0/0 0.0.0.0/0
f2b-php-url-fopen all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-shellshock all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-fakegooglebot all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-botsearch all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-nohome all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-overflows all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-noscript all -- 0.0.0.0/0 0.0.0.0/0
f2b-apache-badbots all -- 0.0.0.0/0 0.0.0.0/0
f2b-sshd all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x10/0x10
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp XXXXXX
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 0 limit: avg 1/sec burst 1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 3 limit: avg 1/sec burst 1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 limit: avg 1/sec burst 1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 11 limit: avg 1/sec burst 1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 12 limit: avg 1/sec burst 1
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 1/sec burst 1
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp XXXXXX
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:113
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 25,587
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp XXXXXX
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 110,995
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp multiport dports 143,220,993
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp XXXXXX
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp XXXXXX
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain f2b-apache-badbots (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-botsearch (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-fakegooglebot (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-livewhale (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-nohome (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-noscript (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-overflows (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-apache-shellshock (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-dovecot (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-php-url-fopen (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-postfix (1 references)
target prot opt source destination
REJECT all -- xxx.xxx.xxx.xxx 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-postfix-rbl (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-postfix-sasl (1 references)
target prot opt source destination
REJECT all -- xxx.xxx.xxx.xxx 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- xxx.xxx.xxx.xxx 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- xxx.xxx.xxx.xxx 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-proftpd (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-sshd (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-webmin-auth (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain f2b-wordpress (1 references)
target prot opt source destination
REJECT all -- xxx.xxx.xxx.xxx 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
I replaced some data with X'es to cover sensitive ports or to mask banned IP's.
Submitted by andreychek on Tue, 07/12/2016 - 11:22 Comment #14
If you could temporarily undo your fix and re-run that netstat command, that'd be great... essentially, I just wanted to ensure it really was listening on that port on the IPv6 interface.
It could be a problem with the Perl dependencies for IPv6 -- if it's not listening on that interface when IPv6 support is enabled, that's what we'd need to look at.
Another possibility is that the firewall is blocking connections.
Regarding iptables, I think I goofed -- I suspect we should actually be looking at "ip6tables -L -n" rather than just "iptables".
However, what you could always try is to disable the firewall entirely... temporarily anyhow, and then see if that resolves the issue.
Regarding ClamAV -- we can certainly look into that, could you start a new request for that though? In there, we'll review which packages you have installed (I know Joe attempted to make some updates to handle that, but it's possible they aren't working properly).
If you could temporarily undo your fix and re-run that netstat command, that'd be great... essentially, I just wanted to ensure it really was listening on that port on the IPv6 interface.[root@jenkins ~]# netstat -an | grep :783tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN
Looks like this problem is more complicated than i originally thought. This is the result without my fix.
Regarding iptables, I think I goofed -- I suspect we should actually be looking at "ip6tables -L -n" rather than just "iptables".[root@jenkins ~]# ip6tables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
However, what you could always try is to disable the firewall entirely... temporarily anyhow, and then see if that resolves the issue.[root@jenkins ~]# systemctl status iptables* iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2016-07-12 18:32:49 CEST; 59s ago
Process: 12275 ExecStop=/usr/libexec/iptables/iptables.init stop (code=exited, status=0/SUCCESS)
Process: 110 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=0/SUCCESS)
Main PID: 110 (code=exited, status=0/SUCCESS)
[root@jenkins ~]# systemctl status ip6tables* ip6tables.service - IPv6 firewall with ip6tables
Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2016-07-12 18:32:53 CEST; 8s ago
Process: 12340 ExecStop=/usr/libexec/iptables/ip6tables.init stop (code=exited, status=0/SUCCESS)
Process: 111 ExecStart=/usr/libexec/iptables/ip6tables.init start (code=exited, status=0/SUCCESS)
Main PID: 111 (code=exited, status=0/SUCCESS)
Disabling iptables and ip6tables didnt help:
Jul 12 18:34:23 jenkins spamc[12503]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refusedRegarding ClamAV -- we can certainly look into that, could you start a new request for that though? In there, we'll review which packages you have installed (I know Joe attempted to make some updates to handle that, but it's possible they aren't working properly).I did and you closed the report: https://www.virtualmin.com/node/41197
Submitted by andreychek on Tue, 07/12/2016 - 11:46 Comment #16
Joe mentioned that we may end up needing to do a new Virtualmin release to fix some of the ClamAV issues... but yeah if you could start up a new thread for that, that'd be fantastic. Then we can review what all you''re seeing, and make sure the fixes he has planned will indeed resolve that.
Submitted by andreychek on Tue, 07/12/2016 - 11:48 Comment #17
Oops my apologies I just saw the last sentence of your comment above. Okay I'll take a look at that.
Ok, i will now bring back both iptables as i hate to have unsecure server. I hope Joe can find something from all the data i posted in this bug report.
For ClamAV i will start new bug report, not now but you can expect in next few hours.
Submitted by andreychek on Tue, 07/12/2016 - 12:40 Comment #19
Regarding SpamAssassin, it looks like there may be two problems.
So long as "ip6tables -L -n" shows that all policies are set to DROP by default with no "ACCEPT" lines, that should prevent any attempt to connect to any IPv6 service. So that could be a problem in the future.
However, the more immediate problem is that it also looks like SpamAssassin isn't listening on an IPv6 interface.
We can ensure that two of the IPv6 Perl modules are installed and working -- to do that, what is the output of these commands:
perl -e 'use IO::Socket::INET6'perl -e 'use Socket6'
Also, just to verify -- what is the output of this command:
/sbin/ifconfigRegarding ClamAV, reviewing your other thread that you posted, we really were getting a lot of similar ClamAV issues back then. Some of the issues were dependency related -- some necessary ClamAV packages weren't being pulled in. Joe released an updated virtualmin-base package that should have helped, and we also tweaked the install.sh script to ensure they were being brought in on newer systems.
However, Joe still thinks there's some config issues that will be resolved with a new release. He's saying we'll be pushing one out soon.
Can you let us know if that works better for you on the new release?
Edit: tweaked some wording and whatnot above
perl -e 'use IO::Socket::INET6'perl -e 'use Socket6'
No output from this two lines.
So long as "ip6tables -L -n" shows that all policies are set to DROP by default with no "ACCEPT" lines, that should prevent any attempt to connect to any IPv6 service. So that could be a problem in the future.That was intentionally because i wanted to block IPv6 on this server. I didnt limit only ip6tables, i disabled IPv6 in any service what was configured by default to use it, e.g. like Named, SSH, Postfix, etc..., but i didnt touch SpamAssassin until today when i saw that problem in mail log. The reason is clear and lets be honest, right now IPv6 is big pile of crap and mostly used by people who buy cheap garbage of VPS and they get 1 or few IPv6 for "free". We know for what are used this kind of servers so i dont have any wish to enable IPv6. Honestly just disabling IPv6 i eliminated quite large number of port scaning, postfix/dovecot brute force, flood on named trying to exploit recursion for DDoS amplification and so on.
Until big ISP dont fully support IPv6 we are not going anywhere and based on the current situation this will not happen for at least 3-5 years and i'm generous here.
[root@jenkins ~]# /sbin/ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 3678 bytes 587297 (573.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3678 bytes 587297 (573.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 127.0.0.1 netmask 255.255.255.255 broadcast 0.0.0.0 destination 127.0.0.1
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 26182 bytes 3177208 (3.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31305 bytes 19764729 (18.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet IP4.xxx.xxx.xxx netmask 255.255.255.255 broadcast IP4.xxx.xxx.xxx destination IP4.xxx.xxx.xxx
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
The point is i dont want to use IPv6. I have IPv6 enabled from my host but i disabled them in SolusVM so my OS and Vmin dont see them and i did this before Centos 7 and Vmin installation.
Submitted by andreychek on Wed, 07/13/2016 - 12:03 Comment #21
I do hear you about IPv6, I don't use that on my personal servers either.
Jamie and I have been digging into the issue you're seeing.
You do have an IPv6 address setup on the "lo" interface.
Under normal circumstances, SpamAssassin should listen on both the IPv4 and IPv6 addresses, if both are present.
Jamie and I have both reviewed your output above, along with the SpamAssassin documentation regarding how it's supposed to work, and we're both puzzled as to why it's not listening on the IPv6 address you have there, except for one possible case --
I don't imagine that the "-4" flag is being passed into the spamd daemon when it's starting? That should be the only thing that would cause it not to listen on both interfaces.
It might be worth double-checking that.
Other than that, we unfortunately haven't been able to reproduce a case where that would occur.
And the two Perl commands you ran above, that didn't produce any output -- that's good, that indicates that you have the correct Perl dependencies for running SpamAssassin on an IPv6 interface, and that they aren't throwing an error when being run.
Other than that, the only other thing I can offer would be to review /var/log/maillog when the spamd service is starting, just to verify that it's not throwing an error or warning of some sort.
I don't imagine that the "-4" flag is being passed into the spamd daemon when it's starting? That should be the only thing that would cause it not to listen on both interfaces.I try that and few other similar solution but it doesnt work. Looks like whatever i do it will not change the outcome and only thing that works is the solution from my first post, e.g. to create "/etc/mail/spamassassin/spamc.conf" and fill with "-d 127.0.0.1".
Well i made a little mistake thinking you guys changed SpamAssassin in the same way you did with ClamAV (i think Joe was talking about this in some topic).
I check the logs many times and there is nothing what would indicate any problem during SA restart, actually even with SA failing for IPv6 it still checks the emal. At least the logs show that and there is few SA lines in email headers. Looking again at the log files it looks like SA is always trying to first connect by IPv6 and when it fails switch to IPv4. For now i will keep my solution, maybe next SA update will solve this problem.
Submitted by andreychek on Wed, 07/13/2016 - 15:34 Comment #23
Yeah it's good to ask, as if it were a package we maintained, or we were seeing a lot of that, we might be able to help out.
Jamie and I went back and forth on this a bit, trying to sort out what the issue might be, but ultimately we're stumped.
It does seem like something outside of our realm is going on.
Your suggestion seems like a good one -- that your current fix is doing the trick, but maybe the next SpamAssassin version will resolve it entirely.
Regarding your earlier mention of ClamAV -- Joe is aware of those issues, and is looking into fixes for that in the next release.
Submitted by gstlouis on Tue, 06/05/2018 - 13:35 Comment #24
I found this thread and have fallen into the same problem. My environment is that I moved all my virtualmin hosts to another cloud server and this problem started. Not that this maybe caused the problem but some weird things have happened when I install virtualmin on the new machine and moved every client virtual instance from my old machine using Backup and Restore > backup virtual servers one big problem was related to this: https://www.virtualmin.com/node/25539 reply #12 was my fix
anyways
virtualmin .sh script was different from my old one to my new one both spamassassin are the same version on both VM's both centos7 are identical saying: centos-release-7-5.1804.el7.centos.2.x86_64
I have used Diabolico solution that did work for me as well. So thanks! I did fiddle with the network and compared stuff from my old and new since I have access to my old until end of billing. I haven't gotten anywhere and nothing important to write about.
If there is any headway on this I would be interested to know. I found that receiving mail does hang a bit when it disconnects from mailer its getting the mail from ie. (postfix/smtpd[27707]: disconnect from mail-io0-f176.google.com[209.85.223.176]) and the first spamd, but they both kind of hang time with the error spamc[27742]: connect to spamd on ::1 failed or without (using Diabolico's fix) spamd[27542]: spamd: connection from localhost
Submitted by JamieCameron on Tue, 06/05/2018 - 19:32 Comment #25
One possible work-around would be to comment out the line starting with
::1in/etc/hosts, to force connections tolocalhostto be IPv4.Submitted by gstlouis on Wed, 06/06/2018 - 08:15 Comment #26
thanks for the update. Unfortunately that does not work. I did try it and restarted networking, removed the spamc.conf and restart spamassassin to see but that error in the logs is still there.