Crikeys, I'll have to double check with the other admin that she didn't do something without telling me, or we have a different serious problem.
That looks to have solved the AUTH issue, though. Thank you for the quick and excellent help, Eric. I only wish I had the knowledge level to be this helpful to the rest of the group. On Fri, Sep 6, 2019 at 4:37 PM Eric Broch <ebr...@whitehorsetc.com> wrote: > It looks like you did do an upgrade from the testing repo, not sure how. > > qmail-1.03-3.1.1 was just put out yesterday > > replace > > export REQUIRE_AUTH=1 > > with > > export SMTPAUTH="!+cram" > > stop and start qmail > > > > On 9/6/2019 3:31 PM, Charles Hockenbarger wrote: > > I did not do an upgrade, no. I don't have automatic yum updates > configured for the server. > > Sorry, should have thought to include this right off the bat. > > [root@mail ~]# rpm -qa | grep qmail > qmailmrtg-4.2-3.qt.el7.x86_64 > qmail-1.03-3.1.1.qt.el7.x86_64 > qmailadmin-1.2.16-2.qt.el7.x86_64 > [root@mail ~]# > > #!/bin/sh > QMAILDUID=`id -u vpopmail` > NOFILESGID=`id -g vpopmail` > MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` > SMTPD="/var/qmail/bin/qmail-smtpd" > TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" > HOSTNAME=`hostname` > VCHKPW="/home/vpopmail/bin/vchkpw" > export REQUIRE_AUTH=1 > > exec /usr/bin/softlimit -m 128000000 \ > /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ > -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ > $SMTPD $VCHKPW /bin/true 2>&1 > > > On Fri, Sep 6, 2019 at 4:25 PM Eric Broch <ebr...@whitehorsetc.com> wrote: > >> What version of qmail are you running? >> >> # rpm -qa | grep qmail >> >> # cat /var/qmail/supervise/submission/run >> >> Send results >> >> On 9/6/2019 3:17 PM, Eric Broch wrote: >> > Have you upgraded? >> > >> > On 9/6/2019 2:26 PM, Charles Hockenbarger wrote: >> >> I am hoping someone has had a similar situation or a place to point >> >> me as I'm at my wits end and have users unable to send emails. >> >> >> >> I've had a toaster running for several years. This particular system >> >> has been running without issues for roughly 12 months after migrating >> >> from CentOS 6 to CentOS 7. >> >> >> >> I didn't make any changes yesterday, and email was flowing perfectly. >> >> This morning, we aren't able to authenticate, with Outlook reporting >> >> 'None of the authentication methods supported by this client are >> >> supported by your server'. Multiple Android clients are reporting >> >> similar errors. The firewall in front of the server and iptables have >> >> 587 open (again, no changes intentionally made in the environment). >> >> I can connect with openssl s_client -starttls smtp -crlf -connect >> >> <server>:587. What is missing is the AUTH line and if I try to >> >> execute an AUTH, I get 503 auth not available (#5.5.3). Selinux is >> >> disabled. >> >> >> >> My /var/log/maillog stops reporting any vchkpw-submission activity >> >> around 0600 this morning. I've searched and not seen where vchkpw >> >> just stops doing anything. >> >> >> >> I'm investigating whether the server has been compromised, but >> >> nothing is showing so far, and this is a very odd behavior to execute >> >> if it were. >> >> >> >> Any thoughts? >> >> >> >> My users have been down since this morning, and I'm flummoxed. >> >> >> >> Thank you! >> >> >> >> Chas >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> > For additional commands, e-mail: >> qmailtoaster-list-h...@qmailtoaster.com >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >>
