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.



What can be used for computers to send each other quick messages over a LAN

The situation may seem familiar to some users, that they are hosting numerous computers on their LAN, and that they’d like to send a message from one to the other. Some users who were accustomed to ‘WinPopup’ and ‘LinPopup’, have been longing for a replacement. Because WinPopup is no longer a part of Windows, and because LinPopup is no longer a part of the standard Linux repositories, their use is extremely limited. For example, even if we custom-compile LinPopup and install it to our Samba server, there is no way for an up-to-date Windows computer to send us a message, because we cannot and should not install this to Windows. And, when sending a message from a Linux machine, it will often work best to do so from the ‘smbclient’ command-line, and not even to use this old program / GUI. [:1]

Yet, If we choose to install this type of software, we would like for it to be compatible between Windows and Linux machines. Otherwise, we could just be installing any software, from any programmer, paying a subscription fee per machine, and only find that our solution does not support Linux.

And so one solution which I have gone with, is called “IP Messenger“. This software is popular in Japan, and has Windows installers. There is only one note of caution from me though: Version 3.52, which I have installed under Windows, does not allow us to disable the Autostart feature, and this behavior can seem a bit malware-like. Also, if we have this daemon running, it can prevent a Windows machine from going into standby correctly. The computer could just keep waking itself up. And so my standard behavior is to terminate this program from the Systray Icon’s Context Menu manually, after every reboot.

What some people may like about this solution, is that there are at least two working Linux versions which we can install directly from the package manager: ‘xipmsg’ and ‘iptux’ . ‘g2ipmsg‘ does not work on recent Linux versions, due to “Attempting To Unlock A Mutex Which Wasn’t Locked”.

‘xipmsg’ is a bit of a kluge, an old implementation based solely on X-server-libraries, that has few of the features which IP Messenger is supposed to have. ‘xipmsg’ will simply allow a text message to be sent and received, and that is all, while the full version will also allow for messages to be given simplistic encryption and for file attachments. ‘iptux’ has more of a full-featured GUI, and allows for these features to be used under Linux as well – assuming that the machine on the other side also has these extensions installed.

Another way in which ‘IP Messenger’ differs from ‘LinPopup’ though, is that the old solution would virtually guarantee that we can receive a message, even if we don’t have this service running, “as long as our computer is turned on”. ‘IP Messenger’ cannot offer this. We would need to have the service running, in order for messages to be received, at the time they were sent.


[Edit 1: ] If we did try to send a LinPopup message to an up-to-date Samba server, in my experience, the server will request a password authentication from the sender, even though none should be necessary. Thus, the ‘smbclient’ command-line used would need to specify an ‘-N’ parameter, in addition to the ‘-M’ parameter, the former of which suppresses the password prompt.

However, when the LinPopup v2.1.0 GUI was written in 2009, there was no awareness of this specific need on the side of the sender. Hence, LinPopup would try to invoke ‘smbclient’ without this parameter, and then some users were mystified as to why the message was not sent.

So that GUI cannot even be used to send, to a current server version.