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 < <>> 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


    export REQUIRE_AUTH=1


    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
    [root@mail ~]#

    QMAILDUID=`id -u vpopmail`
    NOFILESGID=`id -g vpopmail`
    MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
    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
    < <>> 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
        >> 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
        >> similar errors. The firewall in front of the server and
        iptables have
        >> 587 open (again, no changes intentionally made in the
        >> I can connect with openssl s_client -starttls smtp -crlf
        >> <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
        >> 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
        >> Thank you!
        >> Chas
        > To unsubscribe, e-mail:
        > For additional commands, e-mail:

        To unsubscribe, e-mail:
        For additional commands, e-mail:

Reply via email to