That "problem" was already introduced in january testing build
I ran into that issue, hopefully it was not on a production server :)
On 9/6/19 11:57 PM, Eric Broch wrote:
Interesting that another admin would upgrade the server from the
testing repo w/o mentioning it. Damn the torpedoes full speed ahead...LOL
I'm not sure why the run script was not updated though, I'll have to
look into that.
Thanks for helping debug, Charles!
On 9/6/2019 3:54 PM, Charles Hockenbarger wrote:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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:
[email protected]
<mailto:[email protected]>
> For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
<mailto:[email protected]>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
