Re: Password issue
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, johnt...@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). > >
Re: Password issue
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, johnt...@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). > >
Re: Password issue
On Oct 12, 2019, at 8:10 AM, johnt...@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
Re: Password issue
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
Re: Password issue
> Le 12 oct. 2019 à 03:26, @lbutlr via dovecot a écrit : > > 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. I encounter this issue on 10.14 this week, so it is present (with account using automatic server settings).
Re: Password issue
On Oct 11, 2019, at 8:28 PM, Amir Caspi 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.
Re: Password issue
On Oct 11, 2019, at 7:26 PM, @lbutlr via dovecot 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
Re: Password issue
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? -- We could grind our enemies into talcum powder with a sledgehammer, but gosh, we did that last night.
Re: Password issue
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. 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
Re: Password issue
On Oct 9, 2019, at 5:23 PM, @lbutlr wrote: > First, logins in to check mail and succeeds > >> Oct 09 16:02:16 imap-login: Info: Login: user=, >> xx.xx.xx.xx, PLAIN, TLS > > Sends device MUA info > >> Oct 09 16:02:16 imap(myu...@covisp.net)<84553>: 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=, 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
Re: Password issue
On 10/9/2019 6:58 PM, @lbutlr via dovecot wrote: On Oct 9, 2019, at 5:23 PM, @lbutlr 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
Re: Password issue
On Oct 9, 2019, at 5:23 PM, @lbutlr 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
