Password issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Password issue

Dovecot mailing list
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=<[hidden email]>, xx.xx.xx.xx, PLAIN, TLS

Sends device MUA info

> Oct 09 16:02:16 imap([hidden email])<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=<[hidden email]>, 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

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On Oct 9, 2019, at 5:23 PM, @lbutlr <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On 10/9/2019 6:58 PM, @lbutlr via dovecot wrote:

> On Oct 9, 2019, at 5:23 PM, @lbutlr <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
In reply to this post by Dovecot mailing list
On Oct 9, 2019, at 5:23 PM, @lbutlr <[hidden email]> wrote:

> First, logins in to check mail and succeeds
>
>> Oct 09 16:02:16 imap-login: Info: Login: user=<[hidden email]>, xx.xx.xx.xx, PLAIN, TLS
>
> Sends device MUA info
>
>> Oct 09 16:02:16 imap([hidden email])<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=<[hidden email]>, 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

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
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=<[hidden email]>, 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On Oct 11, 2019, at 2:00 PM, Joseph Tam <[hidden email]> wrote:

> 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=<[hidden email]>, 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.

There is no such setting in iOS or iPadOS though, and setting the explicit port for SMTP and.or IMAP advanced settings didn’t change the port it actually tried connecting go until I removed the account and re-added it.

No problems on iOS 12 or macOS 10.14 so far.

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

I have filed a suggestion to have a setting for never connecting to a mail server without security, but nothing so far. Perhaps I should refile it as a critical security flaw?


--
We could grind our enemies into talcum powder with a sledgehammer,
but gosh, we did that last night.

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On Oct 11, 2019, at 7:26 PM, @lbutlr via dovecot <[hidden email]> wrote:

setting the explicit port for SMTP and.or IMAP advanced settings didn’t change the port it actually tried connecting go until I removed the account and re-added it.

I'm sure you tried this before deleting/re-adding, but just in case not: you do have to close out of the settings window (or switch to another account) to get the settings to save... it should ask you to save when you do that.  If you don't save -- for example, if you make the change and then try checking for mail while the Settings window is still open and unsaved -- then it will use the old settings.

But if it was still using the old settings even after a save... that seems like a bug.  Did you try quitting and restarting Mail, too, before deleting/re-adding the account?  Just curious, in case I ever run into such a bug.

Cheers.

--- Amir

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On Oct 11, 2019, at 8:28 PM, Amir Caspi <[hidden email]> wrote:
> I'm sure you tried this before deleting/re-adding, but just in case not: you do have to close out of the settings window (or switch to another account) to get the settings to save... it should ask you to save when you do that.  If you don't save -- for example, if you make the change and then try checking for mail while the Settings window is still open and unsaved -- then it will use the old settings.

Yes. Not only does it ask to save, but it first verifies the settings. This failure to verify is what finally clued me in that it was the MUA that was the issue (combined with it working fine over webmail).



--
This above all, to thine own self be true And it must follow, as the
night the day, Thou canst not then be false to any man.

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
In reply to this post by Dovecot mailing list


> Le 12 oct. 2019 à 03:26, @lbutlr via dovecot <[hidden email]> a écrit :
>
> On Oct 11, 2019, at 2:00 PM, Joseph Tam <[hidden email]> wrote:
>> 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=<[hidden email]>, 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.
>
> There is no such setting in iOS or iPadOS though, and setting the explicit port for SMTP and.or IMAP advanced settings didn’t change the port it actually tried connecting go until I removed the account and re-added it.
>
> No problems on iOS 12 or macOS 10.14 so far.

I encounter this issue on 10.14 this week, so it is present (with account using automatic server settings).

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
In reply to this post by Dovecot mailing list
See comment in context below:

On Fri, 2019-10-11 at 19:26 -0600, @lbutlr via dovecot wrote:

> On Oct 11, 2019, at 2:00 PM, Joseph Tam <[hidden email]> wrote:
> > 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=<[hidden email]>, 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.
>
> There is no such setting in iOS or iPadOS though, and setting the explicit port for SMTP and.or IMAP advanced settings didn’t change the port it actually tried connecting go until I removed the account and re-added it.
>
> No problems on iOS 12 or macOS 10.14 so far.
>
> > 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.
>
> I have filed a suggestion to have a setting for never connecting to a mail server without security, but nothing so far. Perhaps I should refile it as a critical security flaw?
>
>
I run my mail server with no security.  So-called security provides only
a false sense of security, as state-sponsored attacks are beyond the
ability of small organizations to prevent, since encryption to them is
easy to understand with thousands of employees working on it, where for
the lay person it's virtually impossible to understand well enough to
thwart state-sponsored attacks that compromise the encryption configured
on the lay person's machine.  Once encryption is compromised, the lay
person's machine would be at the mercy of the attacker.  In fact, I just
received an attack email this week which revealed that one of my
friend's address book was used, thus I knew his machine had been
compromised.  Of course he had no idea, had difficulty even believing
what I said was true, etc., but I digress.

If I do not rely on a third party to issue a certificate to permit me to
run my mail server, I can run my mail server according to my own policy.
If I need to get a cert from a third party, I am subject to their
policies.  If a nation-state wishes to prevent a person from running
their own web server, denying a digital cert would accomplish that if
the digital cert were required.  We've seen in the news frequently how
many large tech companies are quite willing to do the bidding of
governments.  Digital certs are nothing more than leading down the path
of total state censorship, as well as the very dangerous path of given
deep-pocketed actors the ability to fake/break certs and create false
transactions that for the innocent people involved become
non-repudiable.

How does one run a mail server without implementing security, that is -
how do I know that senders sending me email are who they say they are ?

Simple answer: I don't care who they are.  I simply use my firewall to
ban rogue IP's, even whole ranges of rogue IP's.  MY policy is to assign
RESPONSIBILITY to public IP addresses.  If an IP address does not behave
ethically towards my server, I simply DROP all packets between me and
them.  (Interestingly, every time I run my scripts and ban all the
current bad actors, the attacks in general slow way down - which proves
that the rogue IPs on not all acting independently).

This approach works extremely well, especially since SO MANY
datacenters, both in the US and in other countries simply laugh off
abuse reports.  Thus we can see that THEY are SUPPORTING rogue activity
on the internet.  Without this support, the rogue activity could not
continue.  Case in point: providers of mobile phone networks do not do
proper EGRESS filtering from THEIR cell phone networks, otherwise, they
would NOT ALLOW mobile phones on their network to pretend to be mail
servers (MTA) and send packets to DEST PORT 25, when they should be
using MAIL CLIENT ports.  Thus, mobile providers provide support for
hacking that they very easily could drop support for by doing proper
egress filtering.  Not to mention, if they see such activity, they could
NOTIFY their CUSTOMER that their phone was probably hacked !  What a
great service for their customers.  But, sadly, they simply do not do
egress filtering.  Of course, allowing submits at all on port 25 is the
root of the problem, but we'll be careful to not fix the real issue and
simply move mail relay to it's own port, so port 25 was exclusively
server-to-server send/receive to/from the "outside world".  If I want to
set up relays and they were all using the "relay port", the traffic
could be nicely differentiated in all firewalls, i.e., my California
datacenter mail relay and my New York datacenter mail relay could allow
traffic on the relay port ONLY between their two specific IP addresses,
and send/recv mail from the rest of the world on port25.  Simple.

All this talk of "concern" about security is faux concern by statists,
but for those truly concerned, they have been tricked by statists,
getting so absorbed in the details of implementing encryption/security
that they miss the "forest for the trees", and fail to see that they're
being duped into supporting policies that cleverly lead towards the
state control that, ironically, they so want to avoid.

Hint for better security: increasing complexity causes decreasing
security.  The more complex the configuration and functionality, the
more difficult it is to keep secure.  Today's mail client and server
software tends to be off-the-charts in terms of configuration
complexity.

Just one programmer's opinion, for what it's worth.


Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
On Oct 12, 2019, at 8:10 AM, [hidden email] wrote:
> I run my mail server with no security.

This is extremely foolish and your “reasons” are even more foolish. If you allow unauthenticated users to send mail from your server then you *will* be blacklisted, and rightly so.

(For example, it is trivial to get a free and automated certificate for your server that allows you to encrypt all of your connections).


--
I WILL NOT TRADE PANTS WITH OTHERS Bart chalkboard Ep. 7F05

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
I am the only user and I can only connect my mail client from 1 ip
address.


On Sat, 2019-10-12 at 18:43 -0600, @lbutlr via dovecot wrote:
> On Oct 12, 2019, at 8:10 AM, [hidden email] wrote:
> > I run my mail server with no security.
>
> This is extremely foolish and your “reasons” are even more foolish. If you allow unauthenticated users to send mail from your server then you *will* be blacklisted, and rightly so.
>
> (For example, it is trivial to get a free and automated certificate for your server that allows you to encrypt all of your connections).
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Password issue

Dovecot mailing list
In reply to this post by Dovecot mailing list
And what i meant to say by "no security" is no encryption on port 25,
sending and receiving from other MTA.

On Sat, 2019-10-12 at 18:43 -0600, @lbutlr via dovecot wrote:
> On Oct 12, 2019, at 8:10 AM, [hidden email] wrote:
> > I run my mail server with no security.
>
> This is extremely foolish and your “reasons” are even more foolish. If you allow unauthenticated users to send mail from your server then you *will* be blacklisted, and rightly so.
>
> (For example, it is trivial to get a free and automated certificate for your server that allows you to encrypt all of your connections).
>
>