"cmdeploy test" fails after update [test_0_login.py::test_no_vrfy smtplib.SMTP OSError: Network is unreachable]

Hello there!

I’ve just updated my Chatmail Relay which went fine. No issues there.

But after the update, when I run “cmdeploy test”, it stops at this error:

[gw1] [ 97%] FAILED cmdeploy/src/cmdeploy/tests/online/test_0_login.py::test_no_vrfy

=================================== FAILURES ===================================_________________________________ test_no_vrfy _________________________________[gw1] linux – Python 3.13.5 /.../relay/venv/bin/python3

cmfactory = <cmdeploy.tests.plugin.ChatmailACFactory object at 0x7f42f4687380>chatmail_config = <chatmaild.config.Config object at 0x7f42f7402d50>maildomain = ‘###Maildomain removed for privacy###’

def test_no_vrfy(cmfactory, chatmail_config, maildomain):
ac = cmfactory.get_online_account()
addr = ac.get_config(“addr”)

s = smtplib.SMTP(maildomain)

    ^^^^^^^^^^^^^^^^^^^^^^^^

cmdeploy/src/cmdeploy/tests/online/test_0_login.py:96:

/usr/lib/python3.13/smtplib.py:255: in init(code, msg) = self.connect(host, port)^^^^^^^^^^^^^^^^^^^^^^^^/usr/lib/python3.13/smtplib.py:341: in connectself.sock = self._get_socket(host, port, self.timeout)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^/usr/lib/python3.13/smtplib.py:312: in _get_socketreturn socket.create_connection((host, port), timeout,/usr/lib/python3.13/socket.py:864: in create_connectionraise exceptions[0]

address = (‘###removed###’, 25), timeout = <object object at 0x7f42fd77d4e0>source_address = None

def create_connection(address, timeout=_GLOBAL_DEFAULT_TIMEOUT,
source_address=None, *, all_errors=False):
“”"Connect to address and return the socket object.

Convenience function.  Connect to *address* (a 2-tuple ``(host,
port)``) and return the socket object.  Passing the optional
*timeout* parameter will set the timeout on the socket instance
before attempting to connect.  If no *timeout* is supplied, the
global default timeout setting returned by :func:`getdefaulttimeout`
is used.  If *source_address* is set it must be a tuple of (host, port)
for the socket to bind as a source address before making the connection.
A host of '' or port 0 tells the OS to use the default. When a connection
cannot be created, raises the last error if *all_errors* is False,
and an ExceptionGroup of all errors if *all_errors* is True.
"""

host, port = address
exceptions = []
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
    af, socktype, proto, canonname, sa = res
    sock = None
    try:
        sock = socket(af, socktype, proto)
        if timeout is not _GLOBAL_DEFAULT_TIMEOUT:
            sock.settimeout(timeout)
        if source_address:
            sock.bind(source_address)

      sock.connect(sa)

E               OSError: [Errno 101] Network is unreachable

/usr/lib/python3.13/socket.py:849: OSError
============================= slowest 5 durations ==============================
135.64s call     src/cmdeploy/tests/online/test_0_login.py::test_no_vrfy
10.03s call     src/cmdeploy/tests/online/test_1_basic.py::test_reject_missing_dkim[fake@example.org]
10.02s call     src/cmdeploy/tests/online/test_1_basic.py::test_reject_missing_dkim[fake@testrun.org]
5.11s call     src/cmdeploy/tests/online/test_2_deltachat.py::TestMetadataTokens::test_set_get_metadata
5.05s call     src/cmdeploy/tests/online/test_0_login.py::test_login_basic_functioning[smtp]

The relay is working fine though. I’m just curious what causes this error.

Maybe you awesome people can give me a hint :slight_smile:

Greetings!

Hoiba

--

Sorry for the wall of text, I tried to upload a txt-file with the complete error messages but my account isn’t allowed to upload files yet :confused:

If I were to hazard a guess, the output seems to show you cannot connect to relay port 25 from the device running cmdeploy code. Maybe try a basic telnet / netcat port 25 to confirm or deny, if that’s not it well on to the next idea.

You’re right.

Netcat from my workstation fails to connect to port 25. .. port 143 is OK.

Netcat from the server to delta.maildomain.xx:25 works too.

I’ll give it another shot from a second workstation in 2 hours .. if this doesn’t work as well, I’ll contact the VPS hoster if port 25 is blocked (if this is a possible reason?)

I’ve no idea what possibly could have caused this issue. cmdeploy tests were fine until today.

thanks @punkero :slight_smile:

A little update:

I’m on my laptop at home now and

netcat cmserver 25

works just fine. There has to be something wrong with my laptop at work. I’ll check tomorrow and keep you updated :slight_smile:

Cheers o/

Hoiba

Ok.. an update just for the laughs … this issue is escalating quickly to something absolutely bonkers.

I did some extensive netcat tests:

  • Native IP: port 25 fails, port 143 connects
  • multiple VPN IPs all over the world: port 25 fails, port 143 connects
  • VPN to my home: port 25 connects, port 143 connects
  • routed via tor network (torsocks): port 25 connects, port 143 connects
  • VPN to a colleagues home: port 25 connects, port 143 connects

It’s ridiculous.

Cheers o/

Hoiba

--

oh btw. … with VPN to home “cmdeploy test” passed without any issue.

It is usual for most VPS providers to block 25. As you can see, such blocking may not always be perfect. Try to check their online control panel whether you have an option to lift this limitation. Otherwise, please file a support ticket about it. If they refuse to configure it for you, you may want to ask for a refund and subscribe at another provider.

My spidey sense now seems to think “have you checked IPv4 vs. IPv6 egress?” (or, well ingress depending on POV) - getting different behaviours tells us something about the routes are different. Casting an eye on if the full path of travel is 4 or 6 might shed some clues.

My home ISP uses a massive IPv6 CGNAT, so even if you’re on IPv4 internally it’s possible to reach a different route via IPv6 way upstream of your control. That’s where my mind is going, your points of failure seem to resolve around the home ISP network… maybe it can only egress one or the other? Or the egress acts differently? shrug just ideas :slight_smile:

Hey @ian @punkero

I think I’ve figured it out. In my case my (well.. my offices) ISP is to blame here.

But first:

Mullvad VPN is definitely blocking connections to this port (link - section “Are you blocking any ports?”). that’s why it didn’t work with this VPN active.

Then I did a “traceroute -T -p 143 hostname.cm” “traceroute -T -p 25 hostname.cm” with default internet connection. While 143 displayed the route via 12 hops the one to port 25 dropped just 1 hop out. So the ISP at work most likely filters traffic to port 25 too*.

Anyways.. I’ll just use a VPN to my home and then work with my private ISP which doesn’t block 25.

Thanks for you help!

Greetings
Hoiba

*well… they denied it when calling the support hotline.. .but the guy on the phone also thought port 25 was DNS .. so..

Oh yeah, you just know a corporate office is filtering the SMTP port, they have to - data exfiltration via email is low hanging fruit (but you always get caught), it would be remiss of a company to not monitor all egress. Back about, oh… 10? years ago the bad guys figure out how to smuggle data out with DNS traffic, so it’s common for DNS to also be filtered/monitored. (my company dropped “overly large” DNS packets as a matter of course).

I wrote a small widget which might help you monitor your situation since you have to keep a VPN up, it could help alert you to port availability downtime: punkero-org/cmrelaymon: Monitor a Chatmail relay's port availability - Codeberg.org

Great to hear you figured it out. I guess you could always configure DC to use 143 as it’s more secure that way anyway.