Yes, these changes are implemented. However, you probably won't get a valid certificate for 127.0.0.1, please specify the fqdn instead (or disable tls)

Is it possible to disable cert validation?

I understand it's the best to validate cert, but in testing server, we still need to test TLS/SSL support.

Currently, this is not possible. You may, however set up your own CA, add it to your root store and then sign a certificate for your endpoint with your CA.

There's no point in enabling TLS/SSL if you don't want the certificate to be verified. Read comments in related tickets.

@francis I don't agree that.

• We use port 25 for incoming emails, and 587 with TLS for submission. This is pretty normal.
• If i don't use 587+TLS, i have to set SOGoSMTPServer to something like "127.0.0.1", or "smtp://127.0.0.1". But sogo will connect to port 25 for sending and this obviously causes error because port 25 doesn't support smtp auth.

If ssl cert verification is enforced, sogo can not send email with SOGoSMTPServer set to "smtp://127.0.0.1/?tls=YES" or "127.0.0.1", or "smtp://127.0.0.1".
Connection from/to localhost is considered as secure, so ssl cert verification can be disabled in this case. It doesn't have to be a FQDN smtp server address with a valid ssl cert (sure i understand a cert is the best choice).

This commit mentions "specify fqdn requirement for SSL/TLS", but it doesn't solve the issue with IP address + TLS/SSL: https://github.com/inverse-inc/sogo/commit/a91a00e33cea3e365d8c43b4a9b15a9d55479afb
Note: just to make it clear, i clearly understand we need a valid cert if the request goes to a remote server, but my request is: we should have the option to disable ssl cert verification. Especially with "127.0.0.1" as smtp server address.

@zhb But the certificate is signed with some domain in the subject, right? For now, you could just set that particular domain in your /etc/hosts:

127.0.0.1 some.mail.domain

And then set smtps://some.mail.domain to your sogo configuration. some.mail.domain will always resolve to localhost and validation should succeed.

ok, let me ask in another way: Any plan to support disabling cert validation?

I started looking into this quickly on https://github.com/the-nic/sope/tree/optional-tls-validation, but havent really continued. Note that I am not associated with inverse in any way, I'm doing this in my free time, so dont expect any particular support. I have also shown multiple ways how you may fix your setup.

You can still help with the implementation, though ;-)

Dear @the_nic,

Thanks for your contribution. :)

I understand you already offered few suggestions, but disabling cert validation is quite common, not just in a quick testing environment, but also on production (connect to 127.0.0.1 instead of FQDN, of course we can argue this, but why disallow sysadmin to use 127.0.0.1?).

Dear @the_nic,

Are you still working on the optional ssl validation feature? :)

@zhb, I havent looked into it again, yet.

Why dont the other solutions work for you, by the way?

My free + open source project "iRedMail" installs and configure SOGo for users, at initial installation stage, the installer doesn't know whether the server has a valid ssl cert, so usually we use "127.0.0.1" as IMAP/SMTP/Sieve server address, it's localhost and it's considered as secure, so we prefer to stick to "127.0.0.1" in the installer.

With default iRedMail configuration, port 25 is used to accept incoming emails, and 587 (TLS) is used for submission, in this case if SOGo supports TLS without verification ssl cert (again, cert for host "127.0.0.1" in our case) that would be the best for us, no additional (insecure) smtp port for SOGo without TLS/SSL.

If sysadmin gets a valid ssl cert, it's ok to replace 127.0.0.1 by the server hostname as server address. But this is not handled by iRedMail installer, so it's not an option for us.

So maybe an option like AllowInsecureLocalhost would be more appropiate. With that option given, we could disable peer verification forlocalhost, 127.0.0.1

I think a parameter in the URI might be better. For example:

smtp://127.0.0.1:587/?tls=YES&verify_cert=NO

• No new parameter in sogo.conf introduced.
• Standard DB URI format.

SOPE: https://github.com/inverse-inc/sope/pull/58
SOGo: https://github.com/inverse-inc/sogo/pull/286

This will allow you to disable TLS validation if the remote is a localhost (localhost, 127.0.0.1/8, ...) : smtp://127.0.0.1:587/?tls=YES&tlsVerifyMode=allowInsecureLocalhost

The value "allowInsecureLocalhost" is too weird.

• Does it mean that ssl cert verification can be disabled for only "localhost"-like addresses? How about a LAN IP like 192.168.1.1?
• Why not simply use "tlsVerify=NO" (or something else like "tlsVerifyCert=NO") to disable the verification? Why it's "allow insecure localhost"?

Forgot to say "THANK YOU" for the contribution. :)

Does it mean that ssl cert verification can be disabled for only "localhost"-like addresses?

Exactly that. It follows the same features like allow-insecure-localhost in chrome. So, you can use 127.0.0.1, localhost, and similar, including any other loopback address.

How about a LAN IP like 192.168.1.1?

This is really not intended for that. For that, you should really run a PKI. Please do not decrease security by default for your clients by disabling TLS validation. That is really bad behavior.

Also, according your description you'd need your clients to install a valid certificate for the smtp/imap servers anyways before your setup is going to work. Make them fill up the real host name in the SOGo config, too.

I understand the security concerns, but it's better giving sysadmins such option. For example, connecting to an IMAP server in DMZ or a fully trusted LAN network.

As a system administrator with root access you already have plenty of options to dilute the security of the system as needed.

OK, i don't want to go further and currently this option is enough for a standalone mail server when IMAP is running on same host.
But i still suggest you consider my suggestion. :) If you don't want to support this feature, it's fine.

Thank you very much for the help, and hope SOGo team will merge it soon. :)

Yes, it is even there (you'll find it in the code), I just want to leave it undocumented, as people tend to enable these options without understanding the consequences or fixing the issue properly.

Pull requests were merged. Thanks @the_nic!

Dear @the_nic,

tlsVerifyMode=allowInsecureLocalhost works fine if the server address is localhost, but not work with address 127.0.0.1 (didn't test IPv6 address [::1] yet). Could you help improve the code to support 127.0.0.1?

Hey @zhb, thanks for the feedback. Interestingly, I added a test for localhost ips: https://github.com/inverse-inc/sogo/blob/master/Tests/Unit/TestNGInternetSocketAddress.m#L35

IPv6 does not work, at all. SOPE does not support ipv6 addresses, unfortunately.

The problem is, "127.0.0.1" doesn't work. :(

@zhb i have just tried with imap, and it works. Can you tell me which one (SMTP/IMAP/sieve) does not work with 127.0.0.1 and paste the config lines, please?

Dear @the_nic,

Yes IMAP works, failed one is SMTP service. I didn't test managesieve yet, it was rush last time i test it. sorry.

@zhb As said before, please share your config. It really sounds like an error on your end, like not setting the SMTP port 587 explicitly.

Interesting, this time it works with either allowInsecureLocalhost or none.
I think we're fine now. :)

Hi @the_nic

It's very weird that sometimes it works but sometimes not.

sogo.conf:

SOGoSMTPServer = "smtp://127.0.0.1:587/?tls=YES&tlsVerifyMode=allowInsecureLocalhost";
SOGoMailingMechanism = smtp;
//SOGoSMTPAuthenticationType = PLAIN;

Postfix /etc/postfix/master.cf:

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  ...

• Tried to send email on SOGo web UI, failed with error message Cannot send message: all recipients are invalid..
• Postfix log:

Aug 18 23:16:41 mail postfix/submission/smtpd[41420]: NOQUEUE: reject: RCPT from myhostname[127.0.0.1]: 554 5.7.1 <myhostname[127.0.0.1]>: Client host rejected: Access denied; from=<my-email> to=<external-gmail-email> proto=ESMTP helo=<myhostname>

It says "Access denied", although it looks like an ACL issue, but we have permit_sasl_authenticated in Postfix submission, so if client performed TLS and SMTP SASL AUTH, it should be passed.

Tried using localhost as smtp server address in sogo.conf (SOGoSMTPServer = "smtp://localhost:587/?tls=YES&tlsVerifyMode=allowInsecureLocalhost";), failed with same error.

Forgot to mention OS and SOGo versions:

• OS: 18.04.5 LTS (Bionic Beaver)
• SOGo nightly build: 5.0.0.20200818-1
• SOPE: 4.9.r1664.20200815

Here's the debug log with ImapDebugEnabled = YES. Seems it didn't perform smtp sasl auth at all.

C: connect to <0x0x558d77821170[NGInternetSocketAddress]: host=localhost not-filled>
S: <SMTP-Reply: code=220 line='<myhostname> ESMTP Postfix'>
C: EHLO <myhostname>
S: <SMTP-Reply: code=250 line='SMTPUTF8'>
S: pipelining extension supported.
S: size extension supported.
S: starttls extension supported.
C: STARTTLS
2020-08-18 23:59:38.467 sogod[54712:54712] SMTP: STARTTLS successfully performed
C: EHLO <myhostname>
S: <SMTP-Reply: code=250 line='SMTPUTF8'>
C: MAIL FROM:<my-email>
C: RCPT TO:<external-gmail-email>
Aug 18 23:59:38 sogod [54712]: <0x0x558d778fe380[SOGoMailer]> error with recipient '<external-gmail-email>'
C: QUIT
S: <SMTP-Reply: code=221 line='2.0.0 Bye'>

why is SOGoSMTPAuthenticationType commented out?

That's the cause. I thought when SOGoMailingMechanism = smtp, the SOGoSMTPAuthenticationType = PLAIN is enabled by default.
Thanks @the_nic. :)

It's ok to close this now.