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.