Where the @ Comes From, In Modern e-mail Addresses

A long, long time ago, individual programmers connected to time-sharing computers using terminals, and each so-called account on the time-sharing computer already had a username. And so a need arose, for people to send messages to each other, on the same computer, because those users were not physically located where the computer was located. The computer would typically be located at a remote, secure location, while the user would be located in a terminal-room, without the ability to speak to the other user face-to-face, but somehow requiring the cooperation of the other user.

If this was taking place on a UNIX system, then we considered ourselves to be privileged, because when UNIX was first developed, it was considered advanced, and we could actually give a command such as:


mail dirk


To send a message to the user named ‘dirk’.

Eventually, multiple computers got into the act – i.e. computers existed on small networks. And when I open a terminal-session on any of my Linux computers, I get a command-prompt something like this:




This command-prompt means that I’m user ‘dirk’ but on the computer named ‘Phoenix’. If each Linux computer on my LAN still had legacy packages installed such as ‘sendmail’ or ‘postfix’, then I could type in the command instead, that would read:


mail dirk@Klystron


Which would tell the computer, I wanted to send a message to another computer on the same LAN.

The fact that the characters which follow the ‘@’ form a Fully-Qualified Domain Name – an FQDN – only really started to exist, once the Internet had started to spread.

Now, the way it is on modern Linux systems, we no longer have the ‘sendmail’ utility installed by default, so that we can no longer send each other emails from the command-line. Like the rest of the world, we will need to open a full email-client, to do so instead. And for users who don’t like the fancier GUIs, there is also an email client named ‘mutt’, which allows for emails to be sent from an ASCII-representation, even with no X-server running.

Users who do this are considered to be something of an oddity, much like users who use ‘Lynx’ as their non-graphical Web-browser. But because some legacy software still exists, which would like to be installed on legacy UNIX, we have a package named ‘lsb-invalid-mta’, which we can install, and which provides a superficial appearance of the old ‘mail’ utility being available. But if we ever try to send an actual message or email with this, we will just get an error-message every time.

OTOH, If we wanted to expand our configuration to such a degree, that we could send an actual email using ‘mail’, effectively, we need to install ‘postfix’ as an exclusive alternative either to ‘lsb-invalid-mta’ or to ‘sendmail’. But I suspect that many users would consider this to be a security risk, because then, any application on our local machine could start sending emails, even if those just had user-status – i.e. without root – because it was the user in question, who used the ‘mail’ command to begin with. In the case of email, we’d give ‘postfix’ the (secured) login credentials to an actual, external SMTP server, over which all our locally-generated emails would go out. I think that most Linux users are slightly more-at-ease, knowing that their regular, user-applications, do not have the privileges to do this.



Android Permissions Control

One fact which I had written about before, was that Android differs from Linux, in that under Android, every installed app has its own username. Also, because different users installed a different set of apps in different order, the UID – an actual number – for any given username will be different from one device to the next. And then I also wrote, that a username belonging to a group or not so, can be used to manage access control, just like under Linux.

There is a reason for which things are not so simple with Android. Most Android apps are written in a language named “Dalvik”, the source code of which has syntax identical to “Java”, and which must be compiled into “Bytecode”. The bytecode in turn runs on a bytecode interpreter, which is also referred to as a Virtual Machine.

The reason for which this affects permissions, is because as far as the kernel can see, this VM itself runs under one username. This is similar to how a Java VM would run under one username. And so a much more complex security model is put in place by the VM itself, because presumably this VM’s username has far-reaching capabilities on the device.

The actual use of groups to control access under Android is simpler, and applies at first glance to processes which have been compiled with the ‘NDK’ – with the “Native Development Kit” – and which therefore run directly, say from C++ source code.

Further, the Dalvik VM is capable of reading the permissions of actual files, and is capable of applying its own security model, in a way that takes the permission bits into account, that have been assigned to the files by the Linux kernel. So for most purposes, the security model on the VM is more important than the actual permission bits, as assigned and implemented by the kernel, because most Android source code is effectively written in a Java-like language.