Or at the CLI type...
# man qmail-smtpd
...
ENVIRONMENT VARIABLES READ
Environment variables may be defined globally in the qmail-smtpd
startup script and/or individually as part of the tcpserver's cdb
database. The environment variables may be
quoted ("variable", or 'variable') and in case of global
use, have to be exported. qmail-smtpd supports the following legacy
environment variables, typically provided by
tcpserver or sslserver or tcp-env: TCPREMOTEIP, TCPREMOTEHOST
TCPREMOTEINFO and TCPLOCALPORT as well as RELAYCLIENT.
qmail-smtpd may use the following environment variables for SMTP
authentication:
SMTPAUTH
is used to enable SMTP Authentication for the AUTH types
LOGIN and PLAIN. In case
SMTPAUTH='+cram'
is defined, qmail-smtpd honors LOGIN, PLAIN, and
additionally CRAM-MD5 authentication. Simply
SMTPAUTH='cram'
restricts authentication just to CRAM-MD5. If however
SMTPAUTH='!'
starts with an exclamation mark, AUTH is required. You can
enforce 'Submission' using this option and binding qmail-smtpd to the
SUBMISSION port ´587'. In particular,
SMTPAUTH='!cram'
may be useful. In opposite, if
SMTPAUTH='-'
starts with a dash, AUTH is disabled for particular
connections.
Note: The use of 'cram' requires a CRAM-MD5 enabled PAM.
.....
-Eric
On 9/6/2019 4:13 PM, Philip Nix Guru wrote:
The dev/testing versions got some new patches
regarding the auth you ll get all infos here :
* *SMTPAUTH* *Meaning*
"" Left blank to allow Authentication types "PLAIN" and "LOGIN"
"+cram" Add "CRAM-MD5" support
"cram" Just (secure) "CRAM-MD5" support, no other types offered
"!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN")
"!cram" Enforcing SMTP Auth of type "CRAM-MD5"
"!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5"
"-" Disabling SMTP Auth (for a particular connection)
The complete patch info is listed here :
https://www.fehcom.de/qmail/smtpauth.html
Regards
-P
On 9/6/19 11: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 <ebr...@whitehorsetc.com
<mailto: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 <mailto: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
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
> For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
