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@covisp.net, xx.xx.xx.xx, PLAIN, TLS
Sends device MUA info
Oct 09 16:02:16 imap(myuser@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@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@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@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@kreme.com wrote:
First, logins in to check mail and succeeds
Oct 09 16:02:16 imap-login: Info: Login: user=myuser@covisp.net, xx.xx.xx.xx, PLAIN, TLS
Sends device MUA info
Oct 09 16:02:16 imap(myuser@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@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@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@gmail.com
On Oct 11, 2019, at 2:00 PM, Joseph Tam jtam.home@gmail.com 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=myuser@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.
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.
On Oct 11, 2019, at 7:26 PM, @lbutlr via dovecot dovecot@dovecot.org 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
On Oct 11, 2019, at 8:28 PM, Amir Caspi cepheid@3phase.com 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.
Le 12 oct. 2019 à 03:26, @lbutlr via dovecot dovecot@dovecot.org a écrit :
On Oct 11, 2019, at 2:00 PM, Joseph Tam jtam.home@gmail.com 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=myuser@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.
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).
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 jtam.home@gmail.com 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=myuser@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.
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.
On Oct 12, 2019, at 8:10 AM, johntulp@tulpex.com 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
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, johntulp@tulpex.com 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).
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, johntulp@tulpex.com 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).
participants (6)
-
＠lbutlr
-
Amir Caspi
-
Daniel Miller
-
Jean-Daniel
-
John Tulp
-
Joseph Tam