# "cmdeploy test" fails after update \[test\_0\_login.py::test\_no\_vrfy smtplib.SMTP OSError: Network is unreachable\] **URL:** \ **Category:** Chatmail Relays\ **Tags:** censorship\ **Created:** [July 16, 2026, 10:21am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548 "2026-07-16T10:21:54Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![hoiba](https://forum.delta.chat/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@hoiba](https://forum.delta.chat/u/hoiba)\ **Post date:** [July 16, 2026, 10:21am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/1 "2026-07-16T10:21:55Z")
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: ```auto [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 = chatmail_config = 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 = 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 🙂 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 😕 ---
**Author:** ![punkero](https://forum.delta.chat/user_avatar/forum.delta.chat/punkero/32/3455_2.png) [@punkero](https://forum.delta.chat/u/punkero)\ **Post date:** [July 16, 2026, 12:23pm UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/2 "2026-07-16T12:23:21Z")
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. ---
**Author:** ![hoiba](https://forum.delta.chat/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@hoiba](https://forum.delta.chat/u/hoiba)\ **Post date:** [July 16, 2026, 1:06pm UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/3 "2026-07-16T13:06:51Z")
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🙂 ---
**Author:** ![hoiba](https://forum.delta.chat/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@hoiba](https://forum.delta.chat/u/hoiba)\ **Post date:** [July 16, 2026, 2:41pm UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/4 "2026-07-16T14:41:16Z")
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 🙂 Cheers o/ Hoiba ---
**Author:** ![hoiba](https://forum.delta.chat/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@hoiba](https://forum.delta.chat/u/hoiba)\ **Post date:** [July 17, 2026, 7:07am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/5 "2026-07-17T07:07:00Z")
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. ---
**Author:** ![ian](https://forum.delta.chat/user_avatar/forum.delta.chat/ian/32/3164_2.png) [@ian](https://forum.delta.chat/u/ian)\ **Post date:** [July 17, 2026, 9:30am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/6 "2026-07-17T09:30:40Z")
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. ---
**Author:** ![punkero](https://forum.delta.chat/user_avatar/forum.delta.chat/punkero/32/3455_2.png) [@punkero](https://forum.delta.chat/u/punkero)\ **Post date:** [July 17, 2026, 11:54am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/7 "2026-07-17T11:54:20Z")
> [@hoiba](#): > > I did some extensive netcat tests 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 🙂 ---
**Author:** ![hoiba](https://forum.delta.chat/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@hoiba](https://forum.delta.chat/u/hoiba)\ **Post date:** [July 20, 2026, 11:24am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/8 "2026-07-20T11:24:28Z")
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](https://mullvad.net/en/help/tag/connectivity) - 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.. ---
**Author:** ![punkero](https://forum.delta.chat/user_avatar/forum.delta.chat/punkero/32/3455_2.png) [@punkero](https://forum.delta.chat/u/punkero)\ **Post date:** [July 20, 2026, 11:45am UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/9 "2026-07-20T11:45:17Z")
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](https://codeberg.org/punkero-org/cmrelaymon) ---
**Author:** ![ian](https://forum.delta.chat/user_avatar/forum.delta.chat/ian/32/3164_2.png) [@ian](https://forum.delta.chat/u/ian)\ **Post date:** [July 20, 2026, 1:44pm UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/10 "2026-07-20T13:44:52Z")
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. ---
**Author:** ![r10s](https://forum.delta.chat/user_avatar/forum.delta.chat/r10s/32/1513_2.png) [@r10s](https://forum.delta.chat/u/r10s)\ **Post date:** [October 6, 2026, 3:41pm UTC](https://forum.delta.chat/t/cmdeploy-test-fails-after-update-test-0-login-py-test-no-vrfy-smtplib-smtp-oserror-network-is-unreachable/5548/11 "2026-10-06T15:41:06Z")