dovecot - Oct 2019 - Password issue

One of my accounts was having login failures when trying to send mail, but was
able to check mail.

I tried everything I could think of to see what the issue might be, but
eventually went in and reset the password in the sql database (I knew the
password, so I reset it to the same password).

{SHA256-CRYPT}$5$VuS? 
{SHA256-CRYPT}$5$VI7?

So the password was updated properly.

Clients can still login to check mail, but are failing to send mail, so the
password was not the issue.

First, logins in to check mail and succeeds
> Oct 09 16:02:16 imap-login: Info: Login: user=<myuser at covisp.net>,
xx.xx.xx.xx, PLAIN, TLS
Sends device MUA info
> Oct 09 16:02:16 imap(myuser at
covisp.net)<84553><bP4acIGUJttJDqGg>: Info: ID sent: name=iPad Mail,
version=17A860, os=iOS, os-version=13.1.2 (17A860)
Fails to send mail
> Oct 09 16:02:50 imap-login: Info: Aborted login (auth failed, 5 attempts in
33 secs): user=<myuser at covisp.net>, xx.xx.xx.xx, PLAIN, TLS
Postfix logs "Client host rejected: Access denied? but as I said, other
accounts can submit and there?s nothing special in the submission service in
master.cf.

Passwords are all copied/pasted so identical in both IMAP (p993) and SMTP (p587)
settings. Settings for the SMTP server are identical to the other accounts using
the same server.

I don?t know how to login to IMAP via the openssl command line interface, but
this is what happens when I login to the submission port.

? % openssl s_client -connect mail.covisp.net:587 -starttls smtp 
? 
auth login
334 VXNlcm5hbWU6
base64(username)334 UGFzc3dvcmQ6
base64(pasword)DONE

(Same results without the terminating ?=?)

I?m sure I am missing something really obvious?



-- 
Lithium will no longer be available on credit

On Oct 9, 2019, at 5:23 PM, @lbutlr <kremels at kreme.com>
wrote:
> Postfix logs "Client host rejected: Access denied? but as I said,
other accounts can submit and there?s nothing special in the submission service
in master.cf.
submission inet  n       -       n       -       -       smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_sasl_type=dovecot
   -o smtpd_sasl_security_options=noanonymous
   -o smtpd_sasl_path=private/auth
   -o smtpd_milters   -o milter_connect_macros   -o
milter_macro_daemon_name=ORIGINATING
   -o syslog_name=postfix/submit
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o smtpd_data_restrictions   -o
smtpd_relay_restrictions=permit_sasl_authenticated,reject
   -o smtpd_helo_restrictions   -o
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

On 10/9/2019 6:58 PM, @lbutlr via dovecot wrote:
> On Oct 9, 2019, at 5:23 PM, @lbutlr <kremels at kreme.com> wrote:
>> Postfix logs "Client host rejected: Access denied? but as I said,
other accounts can submit and there?s nothing special in the submission service
in master.cf.
> 
> submission inet  n       -       n       -       -       smtpd
>     -o smtpd_tls_security_level=encrypt
>     -o smtpd_sasl_auth_enable=yes
>     -o smtpd_sasl_type=dovecot
>     -o smtpd_sasl_security_options=noanonymous
>     -o smtpd_sasl_path=private/auth
>     -o smtpd_milters>     -o milter_connect_macros>     -o
milter_macro_daemon_name=ORIGINATING
>     -o syslog_name=postfix/submit
>     -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>     -o smtpd_data_restrictions>     -o
smtpd_relay_restrictions=permit_sasl_authenticated,reject
>     -o smtpd_helo_restrictions>     -o
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
>     -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> 
> 
> 
I suggest you re-post this to the Postfix as this is a Postfix issue. 
However, before doing so, reference
	http://www.postfix.org/DEBUG_README.html

To begin with, I'd suggest adding a "-v" to the smtpd command
above,
followed by a Postfix reload, and test sending again. If that doesn't 
reveal your issue re-post to the Postfix list, and include the output of 
"postconf -n". BTW - I'm assuming the duplicate 
smtpd_recipient_restrictions line at the end is an email artificat.

--
Daniel

On Oct 9, 2019, at 5:23 PM, @lbutlr <kremels at kreme.com>
wrote:
> First, logins in to check mail and succeeds
> 
>> Oct 09 16:02:16 imap-login: Info: Login: user=<myuser at
covisp.net>, xx.xx.xx.xx, PLAIN, TLS
> 
> Sends device MUA info
> 
>> Oct 09 16:02:16 imap(myuser at
covisp.net)<84553><bP4acIGUJttJDqGg>: Info: ID sent: name=iPad Mail,
version=17A860, os=iOS, os-version=13.1.2 (17A860)
> 
> Fails to send mail
> 
>> Oct 09 16:02:50 imap-login: Info: Aborted login (auth failed, 5
attempts in 33 secs): user=<myuser at covisp.net>, xx.xx.xx.xx, PLAIN, TLS
This turns out to have been caused by the MUA attempting to connect to port 25
(despite clearly showing port 587 in the MUA settings). Thanks to Mac/iOS
account syncing, merely trying to change the port never seemed to work, but
removing the account entirely and recreating it got it to connect to port 587 as
configured.

Does dovecot log the ports if any of the various debug settings are enabled?




-- 
I NO LONGER WANT MY MTV Bart chalkboard Ep. 3G02

On Fri, 11 Oct 2019, @lbutlr wrote:
>>> Oct 09 16:02:50 imap-login: Info: Aborted login (auth failed, 5
attempts in 33 secs): user=<myuser at covisp.net>, xx.xx.xx.xx, PLAIN, TLS
>
> This turns out to have been caused by the MUA attempting to connect to
> port 25 (despite clearly showing port 587 in the MUA settings).  Thanks
> to Mac/iOS account syncing, merely trying to change the port never
> seemed to work, but removing the account entirely and recreating it got
> it to connect to port 587 as configured.
Yes, MacOSX Mail.app seems to bumble around, even ignoring your
port settings to find the "correct" configuration.  (This happens,
for example, when there is a transient network problem).  You need to
disable "Automatically manage connections" to stop these mail readers
from wandering around and strictly use your settings.

This behaviour can be exploited to grab credentials using a MITM attacks,
by convincing MacOSX clients that the target server does not support
SSL/TLS, then providing a cleartext listener or proxy.

Joseph Tam <jtam.home at gmail.com>