In the “Greenhouse Analysis” section, we understand a specific problem, Internet censorship news in real time and tell:
The material is supplemented
By mid-July 2026, the story of the Delta Chat failure in Russia no longer looks like an ordinary technical incident. It all started on June 5, when Chatmail relays simultaneously stopped working for messenger users in Russia. One of the users reported on the support forum that his own relay, deployed in Russia, stopped working on that very day: the status is “connecting”, messages are not delivered, the creation of a new profile freezes at 60% with a timeout error. Another developer confirmed in the same thread : the team is aware of the problem, there are many similar messages with the same symptoms. Already on this day, another user suggested blocking by TLS fingerprint, and user Gluek confirmed that the DPI pattern also affects non-chatmail servers.
The complaints were not limited to one topic on the forum. A few days later, a discussion appeared there about blocking IMAP access to external services in several regions at once, regardless of the first message. A separate technical analysis recorded the same timing: Delta Chat mail on the Beget and Timeweb servers stopped working on June 5th.
In 2020, Roskomnadzor demanded that developers have access to user data and encryption keys. At the same time, Roskomnadzor demanded that DeltaChat register in the register of information dissemination organizers (ORI). Delta Chat was denied by Roskomnadzor, citing the lack of access to user data due to the specific architecture of the service. In 2024, Roskomnadzor, at the request of the FSB, again demanded registration, received a second refusal, and in July drew up a protocol on failure to fulfill the duties of the ORI, imposing a fine of 100 thousand rubles.
At the end of May and beginning of June 2026, site owners on large Russian hosting sites began to complain about the unavailability of their resources. Hosting provider Beget reported in its official telegram channel that some resources are partially unavailable for some users. At the same time, according to Beget, the problem is of a “floating nature” and is associated with updating the TSPU settings by the RKN.
Another hosting provider, Timeweb, on their Telegram channel on June 4 named a change in the TSPU settings as the probable cause of the failure. According to the subjective perception of the author , who personally dealt with the problem on his infrastructure, the Timeweb support service denied the problem for two days in responses to individual user requests and recognized it only on June 7. This observation has not been independently verified by other sources and may reflect specific experiences with support rather than general company policy; The telegram channel of the service mentioned TSPU.
On June 6, engineer Pyotr Osetrov published a technical analysis with a reconstruction of the new restriction algorithm, based on a reproducible experiment: he raised several parallel Google Chrome profiles and showed under what conditions the connection freezes. In this post, Delta Chat is not mentioned at all; the analysis is devoted to the general filtering algorithm, which speaks more in favor of the protocol-agnostic nature of the blocking than in favor of the targeted version.
A few days after publication, one of the readers reported in a news article on Habré that the article had become unavailable with a characteristic hosting stub. In the comments to a later analysis, this situation was clarified more precisely: the article was not deleted, but was hidden specifically for Russian IP addresses with HTTP code 451 “Unavailable for legal reasons,” while it is fully accessible from any other countries.
This is consistent with the documented policy of the platform itself: having received an order to block material in a specific country, Habr imposes a geo-restriction with this code, determining the visitor’s country based on the regional address register. It is not established from available sources whether this was a direct order from the regulator or an initiative of the platform itself in the moderation process.
Osetrova's reconstruction describes the mechanism as sequentially checking three conditions when establishing a TLS connection:
If all three conditions are met, the connection is frozen for 120 seconds. Changing a client's fingerprint during a freeze added an additional 600 second ban penalty, regardless of the new fingerprint and SNI, although this additional penalty appears to have since been removed, according to the author's June 16 update.
Delta Chat did not have the goal of bypassing blocking: the normal TLS traffic of the mail client matched signal 2 (suspicious fingerprint) against the background of the fact that the server was located on a subnet already marked as suspicious by signal 1. This is the case that shows: the algorithm does not distinguish between proxies and legitimate traffic if a match for two or more signals is formally carried out.
Collateral damage. The June 5 wave simultaneously affected Delta Chat, hosting providers, and several VPN protocols. The logic of the alarm conditions (subnet, fingerprint, frequency of handshakes) does not contain anything specific to instant messengers or mail. Public rhetoric surrounding the incidentdescribes what is happening as a fight against modern protocols that masquerade as legitimate traffic, and not as an attack on specific services.
Purposeful escalation. The assumption is based on a real precedent: documented conflicts between Delta Chat and the RKN in 2020 and 2024 . However, so far the connection between the three incidents has not been supported by technical data.
For more precise recommendations, the editors of Teplitsa are conducting additional research, the results of which will be published in the near future.
So far the short recommendations are: