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 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=, 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
