Email from Querx with restrictions

April 22, 2022

   

Due to technical limitations of the small Querx, there may be compatibility issues with certain email providers when sending emails in some cases. For maximum compatibility, we recommend using our successor model Querx WLAN, which does not exhibit these limitations.

The possibility to be informed by email that limits have been exceeded is a useful feature of network-based sensors. The communication between network sensor and mail server does not always work right away. Our tutorial may be helpful.

Basically, creating and sending an email is no real challenge for the device itself. However, this is only true as long as confidentiality and integrity do not matter. These are becoming increasingly important, however, and many mail servers now insist on encrypted communication, which is state of the art. For small, low-power devices with limited resources it is not always possible to fully comply with the latest standards.

egnite Querx appeared on the market in 2014. Until that time, most mail servers still accepted the unencrypted reception of emails, but major providers, such as GMX or Gmail, had already announced that they would insist on encrypted transmission via TLS in the future. At that time, versions 1.0 and 1.1 of this encryption protocol were in use, which require that each participant is able to store a 16 kByte data block. If you know that the small Querx network sensor only has a total of 64 kBytes of data memory, most of which is taken up by the integrated web server, it quickly becomes clear that this condition cannot be met.

The successor, egnite Querx WLAN, offers extensive support for encrypted communication. Accordingly, significantly more memory is provided and a more powerful CPU is installed. The disadvantages are the larger case, the higher power consumption and, of course, the higher price.

Supported Querx Querx WLAN
TLS versions 1.0 / 1.1 / 1.2 1.0 / 1.1 / 1.2
Key for certificate RSA up to 2048 bit RSA up to 4096 bit, as well as ECC NIST P-256, P-384, P-521 a.o.
Hash functions for certificate MD5, SHA1, SHA224, SHA256 MD5, SHA1, SHA224, SHA256, SHA384, SHA512
Max. block size 8 kByte 16 kByte
Cipher Suites
  • RSA-WITH-AES-256-CBC-SHA256
  • RSA-WITH-AES-256-CBC-SHA
  • RSA-WITH-AES-128-GCM-SHA256
  • RSA-WITH-AES-128-CBC-SHA256
  • RSA-WITH-AES-128-CBC-SHA
  • ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
  • ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
  • ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
  • ECDHE-ECDSA-WITH-AES-256-CBC-SHA
  • ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
  • ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
  • ECDHE-ECDSA-WITH-AES-128-CBC-SHA
  • ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
  • ECDHE-RSA-WITH-AES-256-GCM-SHA384
  • ECDHE-RSA-WITH-AES-256-CBC-SHA384
  • ECDHE-RSA-WITH-AES-256-CBC-SHA
  • ECDHE-RSA-WITH-AES-128-GCM-SHA256
  • ECDHE-RSA-WITH-AES-128-CBC-SHA256
  • ECDHE-RSA-WITH-AES-128-CBC-SHA
  • RSA-WITH-AES-256-GCM-SHA384
  • RSA-WITH-AES-256-CBC-SHA256
  • RSA-WITH-AES-256-CBC-SHA
  • RSA-WITH-AES-128-GCM-SHA256
  • RSA-WITH-AES-128-CBC-SHA256
  • RSA-WITH-AES-128-CBC-SHA

 

It can make sense to use the larger WLAN variant even if you do not use wireless communication.

Normally, however, data blocks of that maximum size do not occur when communicating with the mail server. Commands, responses and the actual content of the email are much smaller. Only the certificate sent by the server makes an exception here. In fact, the authenticity of the server is not checked by the small Querx, so one could simply ignore this data block. However, it also contains the key for the following communication, so it is mandatory to save this entire data block when it is received in order to be able to decrypt it afterwards.

In most cases, this block reaches a size of a few kilobytes and can thus still be processed by Querx. We regularly review some of the major free email service providers to ensure that our customers can use them as an alternative in the event that the designated mail server no longer works with Querx. No one can predict whether this will always be possible. On the one hand, the requirements of new security standards are increasing, and on the other hand, the insight is gaining ground, that any network is only as secure as its weakest link. It is technically possible to make minimal low-power systems secure. The only thing is that the accepted standards must include these possibilities. Currently, the prospects are not bad. RFC 6066 would be one way to make the data blocks manageable for small systems, and new encryption methods require less memory and less processing power. The savings in resources will ultimately benefit us all.