Error: impossible to establish a secure link with the outgoing server (SMTP) box.mydomain.com using STARTTLS because it doesn’t announce that mechanism. Deactivate STARTTLS for this server or contact your service provider.
I started having this issue in the afternoon after basically two years without problems with MiaB and Thunderbird. The problem seems to be related to network connection (ISP). When I use my home’s network, Thunderbird shows me that error when trying to send emails, but I can receive mails normally.
As soon as I share my phone’s data to my computer, the error disappears and the email is sent. Email can also be sent with my phone’s mail application using mobile data plan. I also connected my computer to a VPN and the email works without problems.
I then tried to check for fail to ban logs to see if the IP provided by the ISP for my home was blacklisted, but it was not on the MiaB logs. I also accessed the Web interface without problems and sent an email.
Finally I though that my ISP blocked SMTP outgoing port 587, but I used linux telnet and nmap utility and found that the port is not blocked.
Can somebody please tell me other diagnostic that I can try to solve this problem?
That’s a very interesting problem. It would be unusual for an ISP to be filtering port 587, but I guess anything is possible. You might get some more information using this:
$ openssl s_client -connect box.mydomain.com:587 -starttls smtp
CONNECTED(00000005)
Didn't find STARTTLS in server response, trying anyway...
140115224162752:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 252 bytes and written 351 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
With VPN
$ openssl s_client -connect box.mydomain.com:587 -starttls smtp
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = box.mydomain.com
verify return:1
---
Certificate chain
0 s:CN = box.mydomain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
XXXXXXXXXXXXXXXXXXXX
-----END CERTIFICATE-----
subject=CN = box.mydomain.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3296 bytes and written 431 bytes
Verification: OK
Output cut but can provide further details if needed.
It is important to mention that I use a Raspberry Pi with dnsmasq to handle my network DHCP server and DNS server. I currently handle myhomename.lan domain inside my home network.
I deactivated the DHCP server from the router and only use it as a gateway.
My router also handles DHCPv6 but I deactivated because it was conflicting with DHCPv4 handled by the dnsmasq.
If the DNS is sending you to a different server, yes. Otherwise, no. But you probably already checked that the domain resolves to the same IP address both ways, right? Would be good to double check both IPv4 and IPv6 just in case. Or repeat the openssl test with an IP address instead of a hostname.
To confirm what’s going on, it might be interesting to see the raw telnet output as well, i.e.:
Then if you wouldn’t mind pasting the whole telnet session through the response after that point.
If you can isolate this to your ISP (try a different computer, make sure it’s not being routed through anything on your network), I would recommend talking to your ISP. This is what an active downgrade attack would look like.
Actually, if you definitely can isolate the problem to your ISP, since this would be a major security issue, I would actually recommend first that you send me a private message with the details and I would consult some expert friends about what to do.
Yestarday at night I received an email from avisos@bbva.com that was clearly phishing (BBVA is a known Spanish Bank) with an attachment, I have not opened it. What struck me was that the email sender was correct, however when I checked the raw email it was comming from a blacklisted IP from Russia.
Is placing your computer directly on the public IP address an option for you? That would eliminate issues that might be related to a compromised or otherwise-configured network gateway.
Since that would go through MiaB, where is MiaB being served from? If the sending IP address is blacklisted, it has to get through two lines of defense: postfix and spamassassin. They are configured for different purposes, but will usually weed out the garbage one way or the other.
The MiaB instance is in DO with a public IP. When I connect to the VPN I use a router gateway with a Public IP. My residential plan does not offer public IP and I probably share this IP with my neighborhood, this IP is also dynamic.
If it were me, I would hunt down the network gateway and figure out what is going on there. You may have something going on with the gateway, and it may only interfere with certain types of traffic. Maybe a VPN will be robustly configured, so interference would be more likely to draw attention. But maybe a lot of mail server connections can be tricked? Just guessing here.
I just want to add that @byque has sent me the telnet output. (I didn’t mean for that part to necessarily be sent privately — I just meant the hostname since we normally don’t make folks reveal their hostnames publicly if they don’t want to.)
And indeed the telnet output is nearly identical except that when routing through the ISP the 250-STARTTLS response is missing (as is PIPELINING, and the SIZE response is different) which seems to indicate that the connection is being proxied.
Today I talked with my ISP and in fact it had a CNAC (Closed Network Access Control) implemented in place for my neighborhood area. ISP did some changes on its side and I can send emails again using my MiaB instance. I don’t know what the ISP did, as the operator barely said CNAC during the support call. Hope this helps someone with a similar scenario.