Scalix: Linux Administrator's Guide

By Markus Feilner
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Email and Groupware: History and Basics

About this book

High-end email and groupware is a domain where only few vendors can provide solutions. It is where companies like HP, Novell, or Scalix offer reliable and scalable products. And Scalix is the only one that has licensed parts under a free and open-source license (Scalix Public License). Scalix runs on Linux, is free for up to 10 users, offers a lot of possible features, ranging from caldav or syncml to clusters, and supports any client. Its flexible architecture gives you the freedom to choose your hardware platform, desktop client, security, directory, and storage infrastructure.

"With over one million mailboxes deployed, 140,000 Community Edition downloads, 5,500 community forum members and almost 700 corporate customers, the Scalix collaborating platform is the most field-proven Linux e-mail and group calendaring solution available to enterprise." - The Scalix website

With the right know-how, Scalix can be managed easily, and several thousand mailboxes are possible on a single server, Web GUIs and command-line tools help the administrator, and Scalix integrates easily with other professional tools, such as OpenVPN, Nagios, and others.

During its history of almost 20 years, many tools and programs have been developed for Scalix to help you with your routine work. While the official documentation has several thousand pages, which are not all up to date, this book gives a detailed overview from installation to advanced setups and best practices for configuration and security. It will help you implement and manage both the free open-source Community Edition and the Enterprise Edition of Scalix.The author provides both a concise description of the features of Scalix and an easy-to-use starting guide for those new to administering it. By bringing together material that might take days to find online this book is a real timesaver.

Publication date:
April 2008
Publisher
Packt
Pages
276
ISBN
9781847192769

 

Chapter 1. Email and Groupware: History and Basics

This book starts with a short history of email and related protocols. In this chapter, you will learn how email became a communication standard, what RFCs are, and where you can find the relevant ones. After a short glance on how email works, the related protocols: SMTP, POP, IMAP, and MAPI are explained in brief as well as LDAP, X500, MIME, and SOAP. An overview of the groupware market, including the various definitions of the latter by different vendors closes the chapter.

A Brief History of Email

In the last 20 years, email has become one of the pillars of Internet. Today, almost everyone has at least one or more email addresses, but nobody realizes that the mail system was born as soon as the early 1960s. The community grew in the '70s, matured to big companies and institutes in the '80s, and the commercialized mail system in the '90s. In the last decade, spam and viruses have been endangering our trust in the whole mail system.

Though initially designed for plain text messages, today's mail programs enable users to send messages in HTML or RTF with multimedia documents attached. Modern systems have made sending emails an easy job, but at the same time few people understand what their PC is doing at this moment. This is a pity, because the basic email protocols use very simple processes.

The 1960s—CTSS and MIT

In 1961, a multi-user system called CTSS (Compatible Time-Sharing System) was introduced at MIT, with which remote users could log in and work together on a central server. Working together also included storing files on this machine and exchanging information. Tom van Vleck, then a young programmer at MIT described the situation:

"When CTSS users wanted to pass messages to each other, they sometimes created files with names like TO TOM and put them in "common file" directories, e. g. M1416 CMFL03. The recipient could log into CTSS later, from any terminal, and look for the file, and print it out if it was there."

"The History of Electronic Mail" by Tom Van Vleck: http://www.multicians.org/thvv/mail-history.html.

Needless to say, the programmers at MIT saw the need for a more sophisticated solution. Thus, the first mail program was developed during the following years. Tom and his colleague, Noel Morris, programmed an early version of "mail" for the CTSS during the summer of 1965. This tool had already been used as a privileged program that could add the message to a file in the recipient's directory. Unlike earlier versions, now there was no need for a common directory with write-access for both sender and recipient. Maybe this was the birth of a mail server daemon. When invoked, the mail command took two arguments:

  • The first of these represented the problem.

  • The second represented the programmer, that is, the recipient.

Some wild cards were also possible, a command like mail m1416 * would send a message about problem m1416 to all the programmers on your project. Only a few users could send mail to arbitrary amounts of recipients. Regarding spam, this system was better than our mail system today.

Another feature was implemented later—delivering mail created a file called "MAIL BOX", and the user logging in was informed about new mail with a line printing "YOU HAVE MAIL BOX "or "YOU HAVE URGENT MAIL" if these files existed. What a pity no one thought of a copyright for such sentences then. The mail program would add mail to the MAIL BOX file or, if the mail was tagged as urgent, to a file called URGENT MAIL in the user's home directory.

Noel Morris and Tom Van Vleck wrote several other programs, including the first chat or instant messaging feature. They also tried to find out what the US Post Office would say about this new mailing procedure. Would the monopolist expect postage? A talk between a MIT professor and a US Post representative ended with the words "Don't worry.", which was maybe bad luck for the monopolist, but luck for us all.

Other computer systems like SDC or SDS also had mail commands until the fall of 1965, a speed pretty normal in the '60s. There were neither software patents nor non-disclosure agreements on code; they were unfortunate inventions of the '80s. Until then, large parts of the computer community freely shared their code.

The '70s—From MULTICS to RFC Standards

In 1969, the first MULTICS mail command was created as a reimplementation of CTSS mail. Again, Tom van Vleck was the programmer who did it, and one of the things that got lost during transition from CTSS to Multics was the concept of a privileged command. Multics could not offer privileges like CTSS did, and programming a real daemon would cause too much load. Therefore, Van Vleck passed a momentous decision:

"The only design I could find was one that depended on the good behavior of the users."

The Mailbox of the users was treated as a shared memory segment with a keyword preventing simultaneous writes from corrupting the file. Multics mail is much like our modern mail systems: insecure, forgeable, and trashable. At that time, knowing the user's real name was necessary for delivery. A command mail firstname.lastname would store the message in the recipient's mail box. The Multics mail program was redesigned in the early '70s to an early server style, including a set of permissions for the mail box file.

According to Van Vleck, that was also the time when the very first spam message was sent. Using MIT's CTSS Mail, the first mass mailing was sent in 1971. It was the time of the Vietnam war and the political mood had inspired a privileged user, a programmer of Van Vleck's team, who sent this mail to all the mail users of CTSS:

THERE IS NO WAY TO PEACE. PEACE IS THE WAY.

According to Brad Templeton, the first commercial spam mail was sent later, in 1978, by a marketer for DEC. ("Reflections on the 25th Anniversary of Spam" by Brad Templeton: http://www.templetons.com/brad/spam/spam25.html).

In 1968, John Licklider of the ARPA contacted Tom Van Vleck with the idea of connecting the various ARPANETs to one big network, one of the birthdays of the Internet. One of the topics discussed most was how to enable mail communication between these networks, because they all had different mail systems. The ideal place for such a standard is an RFC, a "Request for Comments", and as a consequence, in 1971, for the first time a RFC, # 0196 (RFC 196—"A Mail Box Protocol": http://www.faqs.org/rfcs/rfc196.html) with the title "Mail Box Protocol" dealt with electronic mail, specifying how mail had to be delivered to a ARPANet site.

According to techtarget.com, "A Request For Comments (RFC) is a formal document from the Internet Engineering Task Force (IETF) that is the result of committee drafting and subsequent review by interested parties." (http://whatis.techtarget.com/definition/0,,sid9_gci214264,00.html.)

A RFC is the ultimate place for administrators who need to find out definitions, standards, and how some things should work theoretically. A RFC-defined standard is commonly accepted and remains unchanged for long periods of time. Whenever you're stuck in a technical discussion, picking the right RFC will back you up.

The Story of @

By 1971, every site could handle mail with its own system. The system indicated a combination of username and host at a site for the destination. The computer engineer, Ray Tomlinson, had written a mail program called READMAIL—a mailer that was designed to send and receive mail from a local host. However, it was not designed to deal with mail from, or to, other hosts. Connecting the machines in his office made it necessary for a distinguisher between email addresses and hosts. Tomlinson says why he chose the @-sign:

"I am frequently asked why I chose the at sign, but the at sign just makes sense. The purpose of the at sign (in English) was to indicate a unit price (for example, 10 items @ $1.95). I used the at sign to indicate that the user was "at" some other host rather than being local." ("The First Network Email" by Ray Tomlinson http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html).

On March 8, 1973, the @-sign was defined as the distinguishing character between username and host RFC 469 (RFC 469 - "Network Mail Meeting Summary": http://tools.ietf.org/html/469).

The '70s became the time of standardization of electronic mail. Many RFCs continued to specify various aspects of email throughout the 1970s and '80s. The new medium "mail" became more and more popular. It soon became obvious that the ARPANET was becoming a human-communication medium with very important advantages over normal mail and telephone calls. The formality and perfection that most people expect in a typed letter did not become associated with network messages, probably because the network was so much faster, and so much more like the telephone. (J.C.R. Licklider, Albert Vezza, "Applications of Information Networks", Proc of the IEEE, 66(11), Nov 1978, as quoted by Dave Crocker: http://www.livinginternet.com/e/ei.htm.

RFCs—Request for Comments

Obviously, the lack of form was an important aspect that made the Internet and mail appealing for a growing number of people. Totally underestimated by its creators, email became more and more popular. As soon as 1971, more traffic in the ARPANET was generated by Email than from FTP or telnet. With the increasing amount of mail, it became important to have messages sorted and ordered. Tomlinson's README was rewritten and the mail program RD was developed. NRD, BANANARD, and MSG followed until the mid-'70s. According to Dave Crocker, initiator of several RFCs concerning Email and Domain Name System, MSG was the first Email program that provided an "Answer" function. In 1975, an early mail client was developed by Steve Walker at RAND, it was named MS and is said to have been "very powerful, and very, very slow". After several drafts, for the first time, RFC 733 standardized mail formats under the title of "Standard for the format of ARPA network text messages". (RFC 733 - Standard for the format of ARPA network text messages: http://tools.ietf.org/html/733).

Three years later, the next milestone followed with RFC 772, "Mail Transfer Protocol". Until then, network mail had been a component of FTP, according to RFC 385. RFC 772 defined the Mail Transfer Protocol and set the path for the Simple Mail Transfer Protocol SMTP (RFC 821, August 1982), which we still use today. RFC821 is still the most read RFC of all times. The website www.faqs.org ( The Top 50 RFCs: http://www.faqs.org/rfc-pop1.html) offers a complete and up-to-date list of all RFCs and is a very helpful location, offering searches, listings, and lots of links. According to the chart on this site, there are four RFCs concerning mail in the top twenty of the most viewed RFCs. These papers are definitely the best place to go to whenever you are unsure of some technical specifications, if you need to impress your boss or colleagues, or simply want to prove a point. The following descriptions in this chapter will contain a lot of links to such RFCs, simply because they are the commonly accepted authority throughout the Internet.

If you are using KDE, Konqueror has a neat function to help you search for RFCs: an Internet shortcut is provided, with which you can search the apt RFC for a keyword. Simply type "rfc SMTP" in the address bar, and Konqueror takes you to the results of the IETF's RFC search. Of course, most of today's browsers support similar shortcuts.

Mailing Lists, Sendmail, X.400, BBS, and More

In the late '70s, Email usage began to soar and reach more and more people. The very first mailing list was created. According to Howard Rheingold, it was called "SF-Lovers" and enabled the ARPANET mail users to exchange information about their favorite literature: science fiction (Howard Rheingold on the very first mailing list: http://www.rheingold.com/vc/book). Rheingold says:

"In computer technology, playgrounds often are where real innovations emerge."

During the early 1980's, Sendmail was programmed. It later became the (in)famous dinosaur among all mail servers. Still in use today, though there are many replacements, Sendmail is both hated for the syntax of its configuration files and loved for its stability (once properly configured). Sendmail's origin lies in Berkeley, California. A free UNIX operating system called BSD was being developed at Berkeley University, and Sendmail was its mailer. In the beginning, the mail command used UUCP (UNIX to UNIX Copy Protocol) to copy files from one UNIX system to a different vendor's system. After RFC 821, Sendmail became the first and most common SMTP mail program. Today, Sendmail still lives on in different flavors, both commercial and free, and it is still delivered with many Linux distributions. There is also a Sendmail daemon running Scalix SMTP services.

Nevertheless, the classic email system soon became competitors: In 1984, the mail standard X.400 was developed by CCITT, Comité Consultatif International Téléphonique et Télégraphique, which is today the International Telecommunication Union, (ITU) located in Geneva ( X.400 Message handling services: http://www.itu.int/rec/T-REC-X.400/en). X.400 became ISO standard 10021, and was called Standard Message Oriented Text Interchange System (MOTIS). In contrary to standard Email, the X.400 Mail System is transparent. Origin, path, and receiver of every message are traceable, which is why X.400 is still being used in many military or security environments. Other competitors like Mailbox Systems, X.25, BTX or Bulletin Board Systems (BBS) were overtaken by the success of the Internet in the 1990s, and are practically non-existent today. However, especially BBS's, left lots of traces on the Web—the idea of blogs, chat, and more can easily be traced back to these systems. Citadel ( Citadel BBS: http://www.citadel.org), an open source BBS and SMTP-Mailserver shows how alternative concepts can work.

The '90s: Groupware, the WWW, and Microsoft

In the late '80s and early '90s, collaboration software for enterprises like HP OpenMail, IBM Domino/Notes (Lotus), and Novell GroupWise emerged. The term groupware was created and comprised basically of everything related to email, contacts, and calendaring within a team of colleagues. From the very beginning, each vendor followed his own path.

At the end of the 1980s, CompuServe had started the first commercial Email service, and in the early '90s, providers like AOL connected their networks, providing the World Wide Web (WWW) for everyone. Late, but powerful, Microsoft (MS) finally entered the scene with its Exchange Server, Outlook and Internet Explorer. Until the end of the millennium, MS achieved a market leader's role and is today still almost a monopolist in the groupware market. If you are interested in the history of MS Exchange, go to "A history of MS Exchange": http://blogs.brnets.com/michael/archive/2005/02/07/347.aspx. For many Windows users, Outlook, Exchange, and Mail have become a synonym for the same concept. But the monoculture of Microsoft's products, made spam, viruses, and other threats flourish. Of course, some causes lie in history, openness, and design failures of the mail protocols, but another big burden can be found in severe, conceptual security issues of the Windows operating system, the email software, and a software design that focuses more on usability than security, thereby opening the system for intruders. Mail has become a nuisance because spam, viruses, phishing, and other threats make us spend more and more time dealing with our emails. Time for a change!

 

A Brief History of Email


In the last 20 years, email has become one of the pillars of Internet. Today, almost everyone has at least one or more email addresses, but nobody realizes that the mail system was born as soon as the early 1960s. The community grew in the '70s, matured to big companies and institutes in the '80s, and the commercialized mail system in the '90s. In the last decade, spam and viruses have been endangering our trust in the whole mail system.

Though initially designed for plain text messages, today's mail programs enable users to send messages in HTML or RTF with multimedia documents attached. Modern systems have made sending emails an easy job, but at the same time few people understand what their PC is doing at this moment. This is a pity, because the basic email protocols use very simple processes.

The 1960s—CTSS and MIT

In 1961, a multi-user system called CTSS (Compatible Time-Sharing System) was introduced at MIT, with which remote users could log in and work together on a central server. Working together also included storing files on this machine and exchanging information. Tom van Vleck, then a young programmer at MIT described the situation:

"When CTSS users wanted to pass messages to each other, they sometimes created files with names like TO TOM and put them in "common file" directories, e. g. M1416 CMFL03. The recipient could log into CTSS later, from any terminal, and look for the file, and print it out if it was there."

"The History of Electronic Mail" by Tom Van Vleck: http://www.multicians.org/thvv/mail-history.html.

Needless to say, the programmers at MIT saw the need for a more sophisticated solution. Thus, the first mail program was developed during the following years. Tom and his colleague, Noel Morris, programmed an early version of "mail" for the CTSS during the summer of 1965. This tool had already been used as a privileged program that could add the message to a file in the recipient's directory. Unlike earlier versions, now there was no need for a common directory with write-access for both sender and recipient. Maybe this was the birth of a mail server daemon. When invoked, the mail command took two arguments:

  • The first of these represented the problem.

  • The second represented the programmer, that is, the recipient.

Some wild cards were also possible, a command like mail m1416 * would send a message about problem m1416 to all the programmers on your project. Only a few users could send mail to arbitrary amounts of recipients. Regarding spam, this system was better than our mail system today.

Another feature was implemented later—delivering mail created a file called "MAIL BOX", and the user logging in was informed about new mail with a line printing "YOU HAVE MAIL BOX "or "YOU HAVE URGENT MAIL" if these files existed. What a pity no one thought of a copyright for such sentences then. The mail program would add mail to the MAIL BOX file or, if the mail was tagged as urgent, to a file called URGENT MAIL in the user's home directory.

Noel Morris and Tom Van Vleck wrote several other programs, including the first chat or instant messaging feature. They also tried to find out what the US Post Office would say about this new mailing procedure. Would the monopolist expect postage? A talk between a MIT professor and a US Post representative ended with the words "Don't worry.", which was maybe bad luck for the monopolist, but luck for us all.

Other computer systems like SDC or SDS also had mail commands until the fall of 1965, a speed pretty normal in the '60s. There were neither software patents nor non-disclosure agreements on code; they were unfortunate inventions of the '80s. Until then, large parts of the computer community freely shared their code.

The '70s—From MULTICS to RFC Standards

In 1969, the first MULTICS mail command was created as a reimplementation of CTSS mail. Again, Tom van Vleck was the programmer who did it, and one of the things that got lost during transition from CTSS to Multics was the concept of a privileged command. Multics could not offer privileges like CTSS did, and programming a real daemon would cause too much load. Therefore, Van Vleck passed a momentous decision:

"The only design I could find was one that depended on the good behavior of the users."

The Mailbox of the users was treated as a shared memory segment with a keyword preventing simultaneous writes from corrupting the file. Multics mail is much like our modern mail systems: insecure, forgeable, and trashable. At that time, knowing the user's real name was necessary for delivery. A command mail firstname.lastname would store the message in the recipient's mail box. The Multics mail program was redesigned in the early '70s to an early server style, including a set of permissions for the mail box file.

According to Van Vleck, that was also the time when the very first spam message was sent. Using MIT's CTSS Mail, the first mass mailing was sent in 1971. It was the time of the Vietnam war and the political mood had inspired a privileged user, a programmer of Van Vleck's team, who sent this mail to all the mail users of CTSS:

THERE IS NO WAY TO PEACE. PEACE IS THE WAY.

According to Brad Templeton, the first commercial spam mail was sent later, in 1978, by a marketer for DEC. ("Reflections on the 25th Anniversary of Spam" by Brad Templeton: http://www.templetons.com/brad/spam/spam25.html).

In 1968, John Licklider of the ARPA contacted Tom Van Vleck with the idea of connecting the various ARPANETs to one big network, one of the birthdays of the Internet. One of the topics discussed most was how to enable mail communication between these networks, because they all had different mail systems. The ideal place for such a standard is an RFC, a "Request for Comments", and as a consequence, in 1971, for the first time a RFC, # 0196 (RFC 196—"A Mail Box Protocol": http://www.faqs.org/rfcs/rfc196.html) with the title "Mail Box Protocol" dealt with electronic mail, specifying how mail had to be delivered to a ARPANet site.

According to techtarget.com, "A Request For Comments (RFC) is a formal document from the Internet Engineering Task Force (IETF) that is the result of committee drafting and subsequent review by interested parties." (http://whatis.techtarget.com/definition/0,,sid9_gci214264,00.html.)

A RFC is the ultimate place for administrators who need to find out definitions, standards, and how some things should work theoretically. A RFC-defined standard is commonly accepted and remains unchanged for long periods of time. Whenever you're stuck in a technical discussion, picking the right RFC will back you up.

The Story of @

By 1971, every site could handle mail with its own system. The system indicated a combination of username and host at a site for the destination. The computer engineer, Ray Tomlinson, had written a mail program called READMAIL—a mailer that was designed to send and receive mail from a local host. However, it was not designed to deal with mail from, or to, other hosts. Connecting the machines in his office made it necessary for a distinguisher between email addresses and hosts. Tomlinson says why he chose the @-sign:

"I am frequently asked why I chose the at sign, but the at sign just makes sense. The purpose of the at sign (in English) was to indicate a unit price (for example, 10 items @ $1.95). I used the at sign to indicate that the user was "at" some other host rather than being local." ("The First Network Email" by Ray Tomlinson http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html).

On March 8, 1973, the @-sign was defined as the distinguishing character between username and host RFC 469 (RFC 469 - "Network Mail Meeting Summary": http://tools.ietf.org/html/469).

The '70s became the time of standardization of electronic mail. Many RFCs continued to specify various aspects of email throughout the 1970s and '80s. The new medium "mail" became more and more popular. It soon became obvious that the ARPANET was becoming a human-communication medium with very important advantages over normal mail and telephone calls. The formality and perfection that most people expect in a typed letter did not become associated with network messages, probably because the network was so much faster, and so much more like the telephone. (J.C.R. Licklider, Albert Vezza, "Applications of Information Networks", Proc of the IEEE, 66(11), Nov 1978, as quoted by Dave Crocker: http://www.livinginternet.com/e/ei.htm.

RFCs—Request for Comments

Obviously, the lack of form was an important aspect that made the Internet and mail appealing for a growing number of people. Totally underestimated by its creators, email became more and more popular. As soon as 1971, more traffic in the ARPANET was generated by Email than from FTP or telnet. With the increasing amount of mail, it became important to have messages sorted and ordered. Tomlinson's README was rewritten and the mail program RD was developed. NRD, BANANARD, and MSG followed until the mid-'70s. According to Dave Crocker, initiator of several RFCs concerning Email and Domain Name System, MSG was the first Email program that provided an "Answer" function. In 1975, an early mail client was developed by Steve Walker at RAND, it was named MS and is said to have been "very powerful, and very, very slow". After several drafts, for the first time, RFC 733 standardized mail formats under the title of "Standard for the format of ARPA network text messages". (RFC 733 - Standard for the format of ARPA network text messages: http://tools.ietf.org/html/733).

Three years later, the next milestone followed with RFC 772, "Mail Transfer Protocol". Until then, network mail had been a component of FTP, according to RFC 385. RFC 772 defined the Mail Transfer Protocol and set the path for the Simple Mail Transfer Protocol SMTP (RFC 821, August 1982), which we still use today. RFC821 is still the most read RFC of all times. The website www.faqs.org ( The Top 50 RFCs: http://www.faqs.org/rfc-pop1.html) offers a complete and up-to-date list of all RFCs and is a very helpful location, offering searches, listings, and lots of links. According to the chart on this site, there are four RFCs concerning mail in the top twenty of the most viewed RFCs. These papers are definitely the best place to go to whenever you are unsure of some technical specifications, if you need to impress your boss or colleagues, or simply want to prove a point. The following descriptions in this chapter will contain a lot of links to such RFCs, simply because they are the commonly accepted authority throughout the Internet.

If you are using KDE, Konqueror has a neat function to help you search for RFCs: an Internet shortcut is provided, with which you can search the apt RFC for a keyword. Simply type "rfc SMTP" in the address bar, and Konqueror takes you to the results of the IETF's RFC search. Of course, most of today's browsers support similar shortcuts.

Mailing Lists, Sendmail, X.400, BBS, and More

In the late '70s, Email usage began to soar and reach more and more people. The very first mailing list was created. According to Howard Rheingold, it was called "SF-Lovers" and enabled the ARPANET mail users to exchange information about their favorite literature: science fiction (Howard Rheingold on the very first mailing list: http://www.rheingold.com/vc/book). Rheingold says:

"In computer technology, playgrounds often are where real innovations emerge."

During the early 1980's, Sendmail was programmed. It later became the (in)famous dinosaur among all mail servers. Still in use today, though there are many replacements, Sendmail is both hated for the syntax of its configuration files and loved for its stability (once properly configured). Sendmail's origin lies in Berkeley, California. A free UNIX operating system called BSD was being developed at Berkeley University, and Sendmail was its mailer. In the beginning, the mail command used UUCP (UNIX to UNIX Copy Protocol) to copy files from one UNIX system to a different vendor's system. After RFC 821, Sendmail became the first and most common SMTP mail program. Today, Sendmail still lives on in different flavors, both commercial and free, and it is still delivered with many Linux distributions. There is also a Sendmail daemon running Scalix SMTP services.

Nevertheless, the classic email system soon became competitors: In 1984, the mail standard X.400 was developed by CCITT, Comité Consultatif International Téléphonique et Télégraphique, which is today the International Telecommunication Union, (ITU) located in Geneva ( X.400 Message handling services: http://www.itu.int/rec/T-REC-X.400/en). X.400 became ISO standard 10021, and was called Standard Message Oriented Text Interchange System (MOTIS). In contrary to standard Email, the X.400 Mail System is transparent. Origin, path, and receiver of every message are traceable, which is why X.400 is still being used in many military or security environments. Other competitors like Mailbox Systems, X.25, BTX or Bulletin Board Systems (BBS) were overtaken by the success of the Internet in the 1990s, and are practically non-existent today. However, especially BBS's, left lots of traces on the Web—the idea of blogs, chat, and more can easily be traced back to these systems. Citadel ( Citadel BBS: http://www.citadel.org), an open source BBS and SMTP-Mailserver shows how alternative concepts can work.

The '90s: Groupware, the WWW, and Microsoft

In the late '80s and early '90s, collaboration software for enterprises like HP OpenMail, IBM Domino/Notes (Lotus), and Novell GroupWise emerged. The term groupware was created and comprised basically of everything related to email, contacts, and calendaring within a team of colleagues. From the very beginning, each vendor followed his own path.

At the end of the 1980s, CompuServe had started the first commercial Email service, and in the early '90s, providers like AOL connected their networks, providing the World Wide Web (WWW) for everyone. Late, but powerful, Microsoft (MS) finally entered the scene with its Exchange Server, Outlook and Internet Explorer. Until the end of the millennium, MS achieved a market leader's role and is today still almost a monopolist in the groupware market. If you are interested in the history of MS Exchange, go to "A history of MS Exchange": http://blogs.brnets.com/michael/archive/2005/02/07/347.aspx. For many Windows users, Outlook, Exchange, and Mail have become a synonym for the same concept. But the monoculture of Microsoft's products, made spam, viruses, and other threats flourish. Of course, some causes lie in history, openness, and design failures of the mail protocols, but another big burden can be found in severe, conceptual security issues of the Windows operating system, the email software, and a software design that focuses more on usability than security, thereby opening the system for intruders. Mail has become a nuisance because spam, viruses, phishing, and other threats make us spend more and more time dealing with our emails. Time for a change!

 

How does Email Work?


So what is behind email? We have learnt that in per-network-mail, files on a server were created and the user was informed upon login. This does not seem like the way we are using mail today. The following pages show, what is working behind the scenes of sending and retrieving emails. We are watching two users, Norbert and Arne, and we will dive into it deeper and deeper, step by step.

In an example, our user Arne notices that his friend Norbert has his birthday today and decides to send him an email. After composing it in his mail client, Arne hits the Send-button and the message is put on its way to Norbert. Some hours later, Norbert reads his new email and replies to Arne with a short "Thank you!". This is how everybody knows email. But what is really happening in the background?

Sending Mail—the User View

Arne composes an email: A text message is being written. His mail client uses a special format to "wrap" the message text inside with additional information that is needed by the mail servers involved. Such information contains the sender's and the recipient's address, a time stamp, and more. The email with the metadata is transferred to Arne's mail server, which looks up the recipient's mail server in the Domain Name System's (DNS) database. Among other useful things, DNS servers hold paired lists of the name and IP of servers in the Internet. Furthermore, an MX (Mail Exchanger) entry in this database tells a client which mail server provides mail to a recipient's domain.

After having found Norbert's mail server's IP, the message is transferred using SMTP. The receiving mail server notices that the Email is destined for Norbert and stores it in its local storage. Sometime later, Norbert is switching on his PC and retrieving Email with his mail client. The server hands over the new mails, including Arne's best wishes. Norbert now presses reply and hacks in his "Thank you". Once he clicks on Send, the same procedure runs again. That's how everybody uses email today. But what's happening in the background?

The Protocols Involved

In detail: Arne's mail client contacts his mail server using SMTP. A Mail Transfer Agent (MTA) like Sendmail takes the mail, maybe performing some checks on it. At first, the mail will be put in the MTA's mail queue. After having found the IP of Norbert's mail server in the Domain Name System (DNS), Arne's server uses SMTP to transfer the mail to Norbert's server. The latter recognizes that the mail is for a local user and hands it over to the local Mail Delivery Agent (MDA) who stores the mail locally and hands it to Norbert's mail client via a protocol like POP, IMAP or an interface like MAPI. POP and IMAP are protocols only used to retrieve mail or other data by a Mail User Agent (MUA), who we know as mail client or mail program. SMTP, however, is being used for sending mail both by servers and by clients. Thus, after having received his new mail by using POP or IMAP, Norbert will send the reply by SMTP to his mail server, who hands it to Arne's mail server using the same protocol.

The acronym...

...means

MTA

Mail Transfer Agent

MDA

Mail Delivery Agent

MUA

Mail User Agent

SMTP

SMTP stands for "Simple Mail Transfer Protocol" and is used for sending mail. It is defined in RFCs 821, 876, 1047, 1090, 1425-1427, 1651-53, 1830, 1845, 1846, 1854, 1869, 1870, 2197, and many others later on. Whereas a SMTP server sends and receives email via SMTP, clients only use this protocol for sending mail. Alternative standards are UUCP and X.400. Standard SMTP uses TCP port 25 (as defined in /etc/services on Linux machines). Because SMTP is a plain text protocol, Arne could have sent his birthday greetings also with the help of telnet. The following command can be used to send emails in a telnet session.

The correct syntax is: telnet <hostname> <portnumber>.

A typical SMTP session thus looks like the following example.

[email protected] :~> telnet scalixbook.org 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 scalixbook.org ESMTP Postfix
helo localhost
250 scalixbook.org
mail from: <[email protected]>
250 2.1.0 Ok
rcpt to: <[email protected]>
250 2.1.5 Ok
data
from: [email protected]
to: [email protected]
subject: Happy Birthday, Arne!
354 End data with <CR><LF>.<CR><LF>
Hello Norbert,
Happy Birthday!
Arne
.
250 2.0.0 Ok: queued as A335540A08B1
quit
221 2.0.0 Bye
Connection closed by foreign host.
[email protected] :~>

The command telnet scalixbook.org 25 opens a telnet session to port 25 on the machine scalixbook.org. In the following lines, a SMTP session takes place. After the initial greeting with helo <yourhostname> or ehlo <yourhostname> (the latter invokes extended SMTP features), Arne has typed "mail from:" and "rcpt to:" to specify sender and addressee. Following the keyword "data", we find the content of the message as it will appear in the mail client later.

The lines "to:" and "from:" are necessary for correct display of the message in the mail client. If the line "to:" is left out, the mail client will display "undisclosed-recipients:" in the "to:" field. If you are using a spam filter, such a mail would probably be tagged as spam, dropped or rejected. The "data" block is finished with a new line followed by a single dot and another new line, this is what the " <CR><LF>.<CR><LF>" means.

Famous open-source SMTP servers are Sendmail, Postfix, Qmail, and Exim.

POP

POP3 (The Post Office Protocol Version 3) is the abbreviation for Post Office Protocol, currently in version 3, and is used by an MDA. It has been defined in 1984 in RFC 937, enabling a first standard for mail clients who have temporary Internet access only. POP was further specified in RFCs 937, 1081, and 1939—and several later RFCs. Together with SMTP, POP has become the most common mail protocol on the Internet.

A POP server accepts and stores mails in a local storage. If a POP-enabled client connects, the POP server delivers the mail to the client. Normally, the client simply receives all new messages that are deleted from the server after fetching. Nevertheless, most POP servers also provide server-side deleting of mails without delivery, which can be very useful when a low bandwidth client connects and does not want to download a mail with a 100MB attachment.

Norbert is now fetching his mail. He is also using telnet:

[email protected]:~> telnet scalixbook.org 110
Trying 62.116.156.xx ...
Connected to scalixbook.org.
Escape character is '^]'.
+OK Qpopper (version 4.0.5) at scalixbook.org starting. <[email protected]>
user norbert
+OK Password required for norbert.
pass mybirthday2day
+OK norbert has 1 visible message (0 hidden) in 538 octets.
list
+OK 1 visible messages (538 octets)
1 538
.
retr 1
+OK 538 octets
Date: xx yy zzzz 21:16:58 +0100
From: Arne Baeumler <[email protected]>
Subject: Happy Birthday, Norbert!
Message-ID: <[email protected]>
Status: RW
Hello Norbert,
I just wanted to say: Happy Birthday!
Enjoy your Party.
Arne
.
quit
+OK Pop server at scalixbook.org signing off.
Connection closed by foreign host.
[email protected]:~>

The POP syntax is as simple as the SMTP Syntax. After an initial login with the "user" and "pass" command, Norbert can read his mail using "list" and "retr". After having read his birthday greetings, the logout is done with "quit". The following table gives an overview of common pop commands:

The POP Command...

... lets you...

user

enter your username.

pass

enter your password.

stat

list status, incl. the number of new mails.

list

list number and length of the emails.

retr <n>

retrieve email number <n>.

dele <n>

delete mail <n>.

noop

test server. The Server should respond with "Ok".

rset

reset all "dele" commands.

quit

exit the pop session.

Famous open-source POP servers are Cyrus, Qpopper, Dovecot, and Uwimap. Standard POP uses TCP port 110, SSL-encoded POP is using port 995.

IMAP

IMAP stands for Internet Message Access Protocol. This protocol has been standardized through RFCs 1731, 1732, 1733, and many more until RFC 3501 from 2003 defined the standard IMAP Version 4 that we are still using today. It was invented in the '80s at Stanford University, has been steadily improved and has become rather complex today. With IMAP, a mail client can access a mail server's mail storage without downloading a single mail. IMAP offers the possibility of centralizing the storage. Clients only connect to read and manage mail. All the action takes place only on the server, the client does not need a local mail storage. With a POP-based mail system, the local administrator would have had to backup every local PC, but with IMAP a backup of the server's mail storage is sufficient for a whole company.

The central mail storage makes mail accessible from different locations. A user can access his email with an IMAP client from everywhere, given access to the server. Furthermore, a client no longer needs to download the complete email. Especially in low-bandwidth networks, this concept has had great success, and modern mobile services like Blackberry still use similar concepts. A client can connect to the IMAP server and retrieve only the metadata of the new emails, like sender, size, and subject. The user selects the mail he wants to read and has his mail client download it, whereas the other mails stay untouched. However, with large mailboxes, this protocol will use much more network bandwidth, because the communication between client and server is far more complex.

IMAP supports access rules, creation of folders on the server, sharing these folders between users, and searches for and in messages—before the client really has read their content. Many servers use indexing services that speed up searches significantly. Arbitrary flags like "new" or "unread" can now be set by the users, who can also subscribe to or unsubscribe from shared folders.

As in the examples before, Norbert now uses telnet to fetch the birthday email from Arne, using some commands of the IMAP protocol.

[email protected]:~# telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OK scalixbook.org Cyrus IMAP4 v2.2.12-Debian-2.2.12-4ubuntu1 server ready
. login norbert xxxxxxxxxxxxx
. OK User logged in
. list "" "*"
* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.Bestellungen"
(...)
. status INBOX (messages)
* STATUS INBOX (MESSAGES 6)
. OK Completed
. select INBOX
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
(...)
. fetch 1 rfc822.header
* 1 FETCH (RFC822.HEADER {1240}
Return-Path: <a>
Received: from scalixbook.org ([unix socket])
by scalixbook.org (Cyrus v2.2.12-Debian-2.2.12-4ubuntu1) with LMTPA;
Wed, xx xxx 2007 21:40:43 +0000
X-Sieve: CMU Sieve 2.2
(...)
Message-ID: <[email protected]>
Date: Wed, xx xx 2007 21:40:43 -0000 (UTC)
From: Arne Baeumler <[email protected]>
Subject: Happy Birthday, Norbert!
Message-ID: <[email protected]>
Status: RW
(...)
. fetch 1 rfc822.text
* 1 FETCH (RFC822.TEXT {633}
Hello Norbert,
I just wanted to say: Happy Birthday!
Enjoy your Party.
Arne
(...)
. OK Completed (0.000 sec)
. logout
* BYE LOGOUT received
. OK Completed
Connection closed by foreign host.
. logout
[email protected]:

All IMAP commands in this telnet session begin with an initial ".". After logging in with the command . login, followed by his username and password, Norbert types ". list"""*"" to have the IMAP server display all his mail folders. A ". status INBOX (messages)" displays all new messages in the folder INBOX, which is where new mail goes per default. Norbert uses the command ". select INBOX" to switch his context to the Inbox and types ". fetch 1 rfc822.header"". fetch 1 rfc822.text" to receive the header and the content of the first new email, which is the happy-birthday Email from Arne. A final ". logout" quits his IMAP session.

The following table shows some IMAP commands:

The IMAP command ...

means:

. login <name> <password>

Enter your username and password.

. list

List mailbox and folders.

. status <folder>

List status of current folder.

. examine <folder>

Display information on folder

. select <folder>

Select folder as context for next commands.

. create <folder>

Create a folder.

. rename <folder>

Rename a folder.

. delete <folder>

Mark a folder for deletion.

. expunge

Delete the messages marked for deletion.

. close

Expunge messages and exit the session.

. fetch <message number><options>

. fetch 1 rfc822.header

. fetch 2 rfc822.text

Access the information on Email <number>,

- the headers of the mail #1,

- the text of mail #2.

. getacl <folder>

List the access rules for <folder>.

. store <message number> <flags>

Change flags and access rules of messages and folders.

. copy <message> <folder>

Copy a message to a folder.

A special way of dealing with IMAP is the so-called "cached IMAP": The client connects to the server, fetches all mail folders and data and stores it in its local file system. Every time the user triggers the "Check mail" button, the local mail storage is synchronized with the server. By doing so, a user with a client that is only temporarily connected to the IMAP server can still work with his email. This method is often called "Offline-Sync(hronization)" and is only used with desktop email clients, mainly on mobile devices like laptops. Offline Sync combines the advantages of classical POP and IMAP.

Famous open-source IMAP Servers are Courier, Cyrus, UWImap, and Dovecot. Standard IMAP uses TCP port 143. SSL-encoded IMAP is using TCP Port 993.

MAPI—IMAP, the Microsoft Way

First of all: there is no RFC on MAPI. It is not an open protocol, but a vendor-specific interface for Microsoft clients and servers. MAPI is an abbrevation for Messaging Application Programming Interface. Programs that are MAPI-compliant can directly send application data attached to emails and retrieve information stored in MAPI mail servers. Even though there are some free projects developing MAPI implementations, there is no free MAPI version around.

Microsoft was a little late at discovering the importance of the Internet and especially of the mail system. However, in 1987, the company decided to develop a proprietary mail system plus API on their own, and it has been integrated in all Microsoft applications and operating systems since 1995. Its origins can be found in the late '80s. MAPI version 0 originally contained functions that were X.400-based; a "Simple MAPI" interface followed and was removed from Exchange 2003, and replaced by the Extended MAPI Interface.

Since MAPI was developed at a time when open and free standards like SMTP and IMAP had been running successfully for more than a decade, Microsoft has always been under suspicion of trying to use its operating system monopoly to establish a nonstandard mail protocol. The details of the MAPI protocol are proprietary and intellectual property of Microsoft. According to techtarget.com, MAPI consists of:

"a standard set of C language functions that are stored in a (...) dynamic link library (DLL)." (MAPI definition at techtarget.com: http://searchexchange.techtarget.com/sDefinition/0,,sid43_gci214084,00.html)

Open-source projects like Samba and companies like HP (or later Scalix) have acquired great knowledge of Microsoft's protocols. A common rumor suggests that the Samba guys know more about the network behavior of Windows systems than the MS engineers do, and Scalix is said to have the best MAPI implementation, even better than Microsoft's own.

The Microsoft Developer's Network, (MSDN) is probably the best official place to get information on MAPI (Microsoft's MAPI documentation: http://msdn2.microsoft.com/en-us/library/ms879918.aspx). If you intend to dive into reengineering MAPI, go to the wiki of the OpenChange project ( Openchange Projekt: http://www.openchange.org), where open source Samba and Groupware specialists share their knowledge in order to create a free MAPI implementation for a free MAPI server. Until then, we have to work with Outlook plugins connecting the MAPI client to a non-MAPI server. Standard MAPI uses TCP port 135.

MIME

Multipurpose Internet Mail Extensions are of a standard (RFCs 2045, 2046, 2047, 2048, and 2077) that define how application data, normally non-ASCII-text, is sent via email. As you may have noticed, the email protocol is a text-based protocol that supports US-ASCII only. MIME-types specify encoding styles and content types for binary data formats within Emails (and other www-related protocols). MIME Encoding helps to send arbitrary data with protocols like SMTP that only supports 7-bit ASCII code. Thus for example German umlauts or 8-bit binary content can be wrapped within the 7-bit ASCII code of a standard email. MIME encoding is something most people hardly ever know or care about. Since the mail clients have always been doing this work for the user transparently, no interaction is needed. MIME adds a subset of email headers to an email that define the parameters of the encoding and the MIME type of the file attached. Such a message is also called a Multipart/MIME message.

This example shows how an image would be embedded in an email using MIME:

Subject: MIME message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="------content"
Content-type: text/plain; charset=utf-8
Hello Arne,
I have attached a nice picture from my birthday party!
Best regards,
Norbert
------content
Content-type: image/jpg; name="party01.jpg"
Content-Transfer-Encoding: base64
asdf12312d//fADWERD34212424SFVFDGSG...
------content

The Wikipedia page on MIME (http://en.wikipedia.org/wiki/MIME) is a very good start . Examples for typical MIME types are:

Documents with the file name extension ...

... usually are of the Mime type

.doc

application/msword.

.dot

application/msword.

.zip

application/x-compressed.

.zip

application/x-zip-compressed.

.zip

application/zip

The extensions S/MIME and PGP/MIME allow safe encryption and digital signing of mails and attachments; they are defined in RFC 2015 and 3156.

Headers—What Does an Email Look Like?

RFC 2822, RFCs 2045, and the following ones define in detail how an email has to be structured. In some parts of this chapter, we have already seen what that means. A standard email is split in two big parts: the headers and the body. The header fields contain the metadata of the email like sender and recipient, the body contains the message text, and eventually MIME blocks. Here is the Multipart Mail from Norbert to Arne containing the birthday picture:

From: [email protected]
To: [email protected]
Subject: Images from my party
Date: Sun, xx xx 2007 01:29:14 +0100
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_bfI/FxN8p5hMpLk"
X-KMail-Recipients: [email protected]
Message-Id: <[email protected]>
Status: R
X-Status: NQ
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:
--Boundary-00=_bfI/FxN8p5hMpLk
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello Arne,
I have attached a nice picture from my birthday party!
Best regards,
Norbert
--
--Boundary-00=_bfI/FxN8p5hMpLk
Content-Type: image/jpeg;
name="party01.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="party01.jpg"
/9j/4AAQSkZJRgABAQEASABIAAD/4RT5RXhpZgAASUkqAAgAAAAJAA8BAgAGAAAAegAAA BABAgAXAAAAgAAAABIBAwABAAAAAQAAABoBBQABAAAAmAAAABsBBQABAA
AACgBAwABAAAAAgAAADIBAgAUAAAAqAAAABMCAwABAAAAAQAAAGmHBAA BAAAAvAAAAIQJAABDYW5vb
(...)
DcMxiA3ky4MYozYLzRjEDAMYDIKMYAGMYIDdGMYKxupjAbqYxgMbo YwGB1MYAm6GMBrMjGAzdBi7
wYxFE15MYI//2Q==
--Boundary-00=_bfI/FxN8p5hMpLk--

The listing leaves out large parts of the encoded JPEG picture. After the 15 lines with initial headers, the body of this Email is composed of two parts, a text part with the message, and a longer part with the MIME-encoded picture.

The following table explains the used headers and shows more standard headers:

Header:

Explanation:

From:

Sender of the Email.

To:

Recipient (as specified in the SMTP protocol).

CC:

Carbon Copy.

Bcc:

Blind Copy.

Subject:

The subject line of the mail

Date:

The date when this Email was sent

Received:

The path the Email took (every standard SMTP server will add an header here)

Content-Type:

The MIME type of the Email's content

A complete list of common email headers can be retrieved from the Internet Assigned Numbers Authority (IANA, Permanent Message Header Field Names List by the IANA: http://www.iana.org/assignments/message-headers/perm-headers.html), including links to the corresponding RFCs. As the listing shows, there are also headers generated by the mail client. Obviously, Norbert has composed this mail using KMail, and the KDE mail program has left its traces.

 

Storing the Groupware Data


As far as Email is concerned, classical SMTP, POP and IMAP offer anything an Internet user might expect. Mails can be sent and retrieved, and stored on a central server or on a local machine. Nevertheless, one more issue leads us directly to groupware: How does an email user know the address of the recipient? There has to be some kind of address book. In companies, this has to be stored, dispatched, and backed up from a central server.

Directory Services—DAP and LDAP

A standard way to accomplish this is a directory service. A directory is a kind of database where data is stored in a read-optimized manner. Whereas changes to an address book occur rather seldom (that is, writing to the database), reading the contact data is happening all the time. Like in a telephone book, the arrangement of data is optimized for quick searches.

The ISO Standard X.500 (ISO/IEC 9594) includes several subsets of directory standards like DAP, the Directory Access Protocol. X.500 was originally developed to accomplish the needs of the X.400 Mail standard. X.400 has unique identifiers for every member of the communication, thus the need for a central directory was obviously stronger and rose much earlier than for common email services. One disadvantage of DAP was that the Network infrastructure had to be adapted to its X.400 roots. Few scenarios could provide the full OSI protocol stack needed for DAP, and consequently the Lightweight Directory Access Protocol was developed. LDAP has since then had tremendous success and is standardized in RFC 4510 in its current version 3.

The communication between a LDAP Server and his client comprises authentication, adding, deleting, modifying, and searching. The data in the directory is arranged in the form of a tree with branches and leaves. A leaf may represent a person, one of this person's attributes is his or her name, a small branch of the tree could be the department where she works, a thicker branch might stand for the company's American branch with the tree representing the company. Thus a distinguishing name for a person might be:

Germany, Regensburg, Feilner-IT, Markus Feilner.

If we want to make clear the meaning of each of these words, we might need to add:

Country=Germany, City=Regensburg, Company=Feilner-IT, Name="Markus Feilner"

This is almost a perfect description in LDAP syntax. LDAP uses abbreviations as well. Another correct example could be:

cn=Markus Feilner, o=Feilner-IT, ou="Regensburg Division", c=Germany.

In this example, "cn" stands for common name,CN "o" for organization, "ou" for organizational unit, and "c" for country. LDAP is highly configurable, thus the structure of such a "dn" (Distinguished Name) is almost completely up to the administrator. He can add schemata, including object descriptions and extra attributes, and thus build a directory tree from scratch.

LDAP is the standard directory service today. Data can easily be imported and exported from an LDAP directory via ".ldif" (LDAP Data Interchange Format) files. Command line tools and GUIs import, export, and manage the data in the directory, and almost every mail client's address book can be bound to a LDAP Server.

VCAL, ICAL, GroupDAV, CalDAV, WebDAV, ...

Another very common way of storing address book data are databases or standardized text files. An interchangeable standard for such files is vcard (RFC 2426). But the file format is only one side: The address book data has to be stored in the network and made accessible to clients. Several projects, servers, and protocols have risen to accomplish this: users of GroupDAV, WebDAV, and CalDAV share their addresses via an HTTP-based server with write access. Groupware solutions like Kolab store XML or VCAL text files within Emails in specially tagged folders on an IMAP server. Other Groupware solutions use databases—mostly PostgreSQL or MySQL—for storing the contact data. However, LDAP is the de facto standard, to which every groupware solution, client and server software has to be compatible. Almost all groupware solutions fulfill this demand; the others usually have import/export tools.

One of the biggest challenges for all groupware solutions is storing and providing calendar data. Although it is obvious that free standards and open formats like iCAL, vCAL, CalDAV, and GroupDAV will dominate the future, today there are no solutions that provide interchangeable data and that can cooperate with groupware clients and servers from other vendors. Even worse, only few groupware solutions can export calendar data. Almost every software package has its own different model and the communication between server and client is mostly proprietary and closed-source. A lot of calendaring and scheduling is done by the client, especially if group calendars are involved and dates must be scheduled in teams. The exchange of free/busy lists and the definition of recurring events are the biggest problems for groupware coexistence. The only perspective I see is the development around the CalDAV standard (RFC 4791), and more and more vendors seem to adopt this standard.

In a nutshell, a server simply ought to publish both free/busy lists and calendar data for a client. The client is supposed to authenticate to the server, retrieve the dates, calculate schedules, and present group calendars to the user. Although that sounds easy, there is only one Windows program capable of this task and merely two Linux programs that partly manage that. The first is Microsoft Outlook, the latter two are KDE Kontact and Novell Evolution (GNOME).

A lot has been written about the dangers of using Outlook, about viruses, spam and phishing attacks. Linux evangelists argue, that Outlook and Window's flaw only made that possible. But still there is no replacement. The open-source groupware clients are far from enterprise-ready when run with a groupware server. AJAX (Asynchronous Java And XML)-enabled Web Clients are cheaper to develop and obviously sufficient for the Linux desktop. That is why all groupware projects still focus on the Microsoft client. And so does Scalix.

Groupware Definitions

Apart from Microsoft Exchange and Scalix, there are many groupware products, both open source and proprietary available. And there are as many definitions of "groupware" as there are solutions. Products like openXchange and eGroupWare include wikis, document management, project management, and even CRM options. The typical setup for Microsoft's environment includes fax and telephony software integrated in your client's address book. Novell's GroupWise comes with a full featured instant messaging and IBM's Lotus maps your whole company's work flow in the groupware system.

Famous groupware solutions are:

  • IBM Domino Server with Lotus Notes

  • Novell GroupWise

  • HP OpenMail, that became Samsung Contact and then Scalix

  • Microsoft Exchange

  • OpenXchange

  • Kolab

  • Zarafa

  • Zimbra

  • Citadel

  • eGroupWare

And many more...

Scalix calls its product a "mail and calendaring solution", avoiding the term groupware in its marketing. Nevertheless, the scope of Scalix fulfills my favorite definition of groupware: email, contacts, group calendaring plus optional features.

 

Summary


In this chapter, you have learnt how email became the communication standard we are using today. You now know why some things are not perfect, and where to look up the RFC that may contain the information you need. You know what's happening when you send an email and what servers and daemons are necessary for sending and retrieving email. Furthermore, LDAP, iCAL, and vCAL are not cryptical abbreviations anymore.

About the Author

  • Markus Feilner

    Markus Feilner is a seasoned Linux expert from Regensburg, Germany. He has been working with free and open source software since 1994, as a trainer, consultant, author and journalist. His first contact with UNIX was a SUN cluster and SPARC workstations at Regensburg University (during his studies of geography).

    Since 2000, he has published many books and courses used in Linux training sessions all over the world. Among that were three books for Packt (two on OpenVPN and one on Scalix Groupware). In the same year, he founded his own Linux consulting and training company, Feilner IT. He was also working as a trainer, consultant, and systems engineer at Millenux, Munich, where he focused on groupware, collaboration, and virtualization with Linux-based systems and networks.

    Until 2015, he had been deputy editor-in-chief at the German Linux-Magazine, where he wrote about open source software for both printed and online magazines, including the Linux Technical Review and the Linux Magazine International (the U.S., UK, and Australia).

    Today, the Conch diplomat, Minister of the Universal Life Church, Jedi Knight, and owner of lunar property holds several nationalities and is employed as Team Lead of the SUSE Documentation Team in Nürnberg. He regularly gives keynotes, workshops, lectures, and presentations at tech and political conferences in Germany.

    He is interested in anything about geography, traveling, photography, philosophy (especially that of open source software), global politics, modern science, arts and literature, but always has too little time for these hobbies.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now