Page 1 of 1

451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 15 Aug 2019 01:32
by zane93
I woke up this morning to hundreds of these messages in /var/log/maillog with zero mail flow nothing is delivered either way to or from this server. Exchange is trying to send getting 451 4.7.1. I have no idea what has happened as its been running fine for months with no changes. Mail is just pileing up

Code: Select all

connect from mx251.a.outbound.createsend.com[203.55.21.251]
warning: connect to Milter service inet:127.0.0.1:8893: Connection refused
NOQUEUE: milter-reject: CONNECT from mx251.a.outbound.createsend.com[203.55.21.251]: 451 4.7.1 Service unavailable - try again later; proto=SMTP
NOQUEUE: milter-reject: EHLO from mx251.a.outbound.createsend.com[203.55.21.251]: 451 4.7.1 Service unavailable - try again later; proto=SMTP helo=<mx251.a.outbound.createsend.com>
NOQUEUE: milter-reject: MAIL from mx251.a.outbound.createsend.com[203.55.21.251]: 451 4.7.1 Service unavailable - try again later; from=<SchlitterbahnNewBraunfels-xltduyd1wldutdriy1d@cmail20.com> proto=ESMTP helo=<mx251.a.outbound.createsend.com>
disconnect from mx251.a.outbound.createsend.com[203.55.21.251] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 quit=1 commands=2/5
I believe the primary issue is with Milter but the service milter_relay is running fine and so if postfix.
warning: connect to Milter service inet:127.0.0.1:8893: Connection refused
Any ideas how I can further troubleshoot?
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/rootvg-rootlv 8125880 81388 7608680 2% /
devtmpfs 4070916 0 4070916 0% /dev
tmpfs 4082500 0 4082500 0% /dev/shm
tmpfs 4082500 9144 4073356 1% /run
tmpfs 4082500 0 4082500 0% /sys/fs/cgroup
/dev/mapper/rootvg-usrlv 10190100 1848272 7801156 20% /usr
/dev/mapper/rootvg-homelv 999320 2604 927904 1% /home
/dev/sda1 999320 102332 828176 11% /boot
/dev/mapper/rootvg-varlv 8125880 3014584 4675484 40% /var
/dev/mapper/rootvg-optlv 1998672 196660 1680772 11% /opt
/dev/mapper/rootvg-tmplv 1998672 6228 1871204 1% /tmp
none 4082500 208 4082292 1% /var/spool/MailScanner/incoming
tmpfs 816500 0 816500 0% /run/user/0
tmpfs 816500 0 816500 0% /run/user/1000

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 15 Aug 2019 02:30
by zane93
I found that the dmarc service is failing with
opendmarc.service: main process exited, code=killed, status=11/SEGV
I have never done any trouble shooting on dmarc service not sure where to start but disabling dmarc/dkim does not solve the problem with Milter refusing connection
warning: connect to Milter service inet:localhost:8891: Connection refused

Code: Select all

Redirecting to /bin/systemctl status opendmarc.service
● opendmarc.service - Domain-based Message Authentication, Reporting & Conformance (DMARC) Milter
   Loaded: loaded (/usr/lib/systemd/system/opendmarc.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Wed 2019-08-14 20:38:46 CDT; 4min 24s ago
     Docs: man:opendmarc(8)
           man:opendmarc.conf(5)
           man:opendmarc-import(8)
           man:opendmarc-reports(8)
           http://www.trusteddomain.org/opendmarc/
  Process: 18213 ExecStart=/usr/sbin/opendmarc $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 18214 (code=killed, signal=SEGV)

Aug 14 20:38:42 exchedge.o.com opendmarc[18214]: 4688HQ0bfTz30CL: SPF(mailfrom): 126-NHQ-240.0.2904.0.0.2716.9.2826554@em-sj-77.mktomail.com pass
Aug 14 20:38:42 exchedge.o.com opendmarc[18214]: 4688HQ0bfTz30CL: portworx.com none
Aug 14 20:38:42 exchedge.o.com opendmarc[18214]: 4688HQ0bfTz30CL: SPF(mailfrom): 126-NHQ-240.0.2904.0.0.2716.9.2826554@em-sj-77.mktomail.com pass
Aug 14 20:38:42 exchedge.o.com opendmarc[18214]: 4688HQ0bfTz30CL: portworx.com none
Aug 14 20:38:44 exchedge.o.com opendmarc[18214]: ignoring connection from localhost
Aug 14 20:38:44 exchedge.o.com opendmarc[18214]: ignoring connection from localhost
Aug 14 20:38:46 exchedge.o.com opendmarc[18214]: 4688HT5rtQz30Dr: SPF(mailfrom): bbmail+90025b9d7a1b7c53e0530100007f3c7e@1x1.bbsv2.net pass
Aug 14 20:38:46 exchedge.o.com systemd[1]: opendmarc.service: main process exited, code=killed, status=11/SEGV
Aug 14 20:38:46 exchedge.o.com systemd[1]: Unit opendmarc.service entered failed state.
Aug 14 20:38:46 exchedge.o.com systemd[1]: opendmarc.service failed.

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 15 Aug 2019 03:51
by zane93
I removed and re-added DKIM and DKIM service quit failing. Im still left with no mail delivery and the same 451 4.7.1 - Milter service message.
CPU, Memory, Dsk space are all good.

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 16 Aug 2019 07:11
by shawniverson
Is MSMilter actually running?

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 16 Aug 2019 18:11
by zane93
shawniverson wrote: 16 Aug 2019 07:11 Is MSMilter actually running?
Ye,s MSMilter was running. I was finally able to get things working after I disabled DNS Recursion. This server has been running smooth for quite a while. I'm going to try and re-enable dns recursion this weekend to see if the issue pops back up.
What log can I look at for DNS recursion?

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 23 Aug 2019 22:36
by henk
I had the same issue.

My eFa4 is only used for inbound mail.I use fetchmail to fetch mail from my different mailservers out there.
My internal mailserver is the only one that can send mail, I had no need for sqlgrey/dkim/dmarc on eFa so there where disabled.
I did a yum update today and this somehow resulted in the "Milter service inet:127.0.0.1:8893: Connection refused" messages

To solve the issue I did enable dkim /dmarc via the efa menu (option 16 I believe)
and did some temp fixes : viewtopic.php?f=19&t=3788
I do use DNS recusion and I just tested receiving mail. No issues.

About unbound dns config viewtopic.php?t=2567

Re: 451 4.7.1 - Milter service inet:127.0.0.1:8893: Connection refused

Posted: 23 Aug 2019 23:28
by zane93
No further issues after re-enabling dns recursion.