A 3rd-party, Android email client, still worth using: FairEmail.

One of the observations which I’ve made about the Android platform is, that many of the 3rd-party email apps that once used to run well, no longer do so under Android 10, and that, additionally, their devs have often abandoned them.

For that reason, I’m happy to find that such an app still exists, or newly exists, and its name is FairEmail. This is an app, the free version of which can actually be used in the long term, but which I paid for, just to get the extra features.

One of the observations which I can make about this app is, that it has a plethora of settings, some of which I haven’t learned the meaning of yet. But, by default, the way to use it is to follow what is located in its first settings tab, which displays wizards to set up email accounts according to a database of recognized providers, and then, to leave the settings at their defaults. Additional wizards help the user give the app special settings under Android. The app directs the user to the required or optional settings, but it’s up to the user actually ‘to throw the switch’ each time. (:2)

Multiple email accounts can all be set up, using the same wizard.

The app runs in phone-optimized as well as tablet-optimized formats.

Screenshot_20200723-121436_FairEmail_1_e

Screenshot_20200723-121814_FairEmail_2_f

One of the features that were highly important to me was, support for both ‘S/MIME’ and ‘OpenPGP’. When using OpenGPG, this app will always encode it using the trendy ‘PGP/MIME’ format, and no longer, using ‘Clearsigning’, which was also referred to as ‘Inline Format’. The use of OpenPGP requires that an additional key-management app be installed, and on my devices, Open Keychain was already so, and was recognized immediately by FairEmail.

The app displays many widgets inside displayed emails, most of which give explicit commands to do things, that might impact the privacy of the user, such as, to display images, to display tracking images, etc. The app tries to distinguish between these two types of images because additionally, being an IMAP Client, downloading even plain images will consume additional data, when many emails can Humanly be understood, without the need actually to see the images. This is especially true for actual Spam.

The app leaves Spam filtering up to the IMAP Server, but displays the Spam Folder as fully accessible.

And many configuration details show me, that it assumes trendy preferences, even though I can’t say that either I, or most of my email contacts, qualify as trendy Internet users. One trendy feature is that this app mainly supports IMAP, and that any support of POP3 which the user may find, will be incomplete at best.

Another trendy setting in this app has to do with “Flowed Text”. This is a term which refers to ‘Pure Text Emails’, in which one paragraph is essentially written on one line. Traditionally, this lack of formatting was reserved for HTML-composed emails, and the receiving email client would always display those flowed. By contrast, traditionally, Pure Text had fixed line-lengths, determined by the sender, and the receiving client would break lines where line-breaks were sent, even if doing so, or not doing so, tended to wreck the appearance of the email…

(Updated 8/13/2020, 10h10… )

Continue reading A 3rd-party, Android email client, still worth using: FairEmail.

Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

The reality is that, being 52 years old and only having studied briefly in my distant past, my formal knowledge in Computing is actually lacking these days, and one subject which I know too little about, is how Push Notifications work. Back in my day, if a laptop was ‘asleep’ – i.e. In Standby – it was generally unable to be woken externally via WiFi, but did have hardware clocks that could wake it at scheduled times. Yet we know that mobile devices today, including Android and iOS devices, are able to receive push notifications from various servers, which do precisely that, and that this feature even works from behind a firewall. And so I can muse over how this might work.

I can think of two ways in which this can hypothetically work:

  1. The application framework can centralize the receipt of push notifications for the client device, to one UDP port number. If that port number receives a packet, the WiFi chip-set wakes up the main CPU.
  2. Each application that wants to receive them, can establish a client connection to a server in advance, which is to send them.

The problem with approach (1) is that, behind a firewall, by default, a device cannot be listening on a fixed port number, known to it. I.e., the same WAN IP Address could be associated with two devices, and a magic packet sent to one fixed port number, even if we know that IP Address, cannot be mapped to wake up the correct device. But this problem can be solved via UPnP, so that each device could open a listening port number for itself on the WAN, and know what its number is.

We do not always know that UPnP is available for every NAT implementation.

Approach (2) requires more from the device, in that a base-band CPU needs to keep a list, of which specific UDP ports on the client device will be allowed to wake up the main CPU, if that port receives a packet.

Presumably, this base-band CPU would also first verify, that the packet was received from the IP address, which the port in question is supposed to be connected to, on the other side, before waking the main CPU.

(Edit 12/19/2016 : Google can simply decide that after a certain Android API Number – i.e., Android version – the device needs to have specific features, that earlier Android APIs did not require.

Hence, starting from , or , Google could have decided that it was no longer a special app permission, for the user to acknowledge, to wake the device. Likewise, starting from some Android version, possessing a base-band CPU might have become mandatory for the hardware, so that the API can offer a certain type of push notification.)

Also, approach (1) would have as drawback, a lack of authentication. Any networked device could just send this magic packet to any other networked device, provided that both the IP address and the port number it is sensitive to are known.

Approach (2) would bring as an advantage, that only specific apps on the client device could be enabled to receive push notifications, and the O/S would be aware of which UDP ports those are sensitive on, so that the base-band CPU would only be waking up the main CPU, if push notifications were received and associated with an app authorized to wake the device.

Also, with approach (2), the mapping of WAN port numbers back to LAN port numbers would still take place passively, through port triggering, so that the WAN-based server does not need to know, what LAN-based port number the connected port is associated with on the client device.

But, approach (2) has as a real drawback, that a server would need to keep a socket open, for every client it might want to send a push notification to. This might sound unimportant but is really not, since many, many clients could be subscribed to one service, such as Facebook. Are we to assume then, that the Facebook server also keeps one connection open to every client device? And if that connection is ever dropped, should we assume that a sea of client devices reconnect continuously, as soon as their clocks periodically wake them?

Dirk

Continue reading Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

Wake On LAN (WoL)

Some time ago, a hardware capability named “Wake On LAN”, or ‘WoL’ was explained to me, which was based on an Ethernet network. According to that explanation, a number of computers at a workplace could be powered down – shut down – but their Ethernet cards would still be receiving a trickle of current from their power supplies. And then, just before the workforce would show up to begin their day, their switches and routers would send out a so-called “Magic Packet”, which would cause all the computers to boot up, and then to be ready for the workforce when it arrives for work.

Well I was recently surprised – though pleasantly surprised – to find out that a homologous feature does after all exist for WiFi, which has also been referred to as Wake On LAN, or WoL, even though the WiFi version of it does not work exactly the same way. For our WiFi-connected phones and tablets, when they are in standby, their WiFi antennae are typically still powered up, and when those receive their magic packet, it wakes them up from standby.

This is a hardware capability, which also explains why such devices are really able to receive push notifications.

I had previously explained to my friends, that with Android or iOS, instead of each app listening forever on a port number for a push notification, this capability has been centralized into the Application Framework, as part of the O/S effectively. But this being centralized to one port number for the device, would still not have been completely enough to explain push notifications.

Well apparently, in the WiFi version of this feature, the magic packet is also sent to a specific port number, which means that it can wake up a device which is behind a firewall.

And then that way, cell phones on their broadband data instead of on WiFi, also retain their IP numbers, and can thus also receive push notifications easily.

Dirk