Planet Ergo

Kolab Groupware has a strong focus on security, and data integrity - not just your own mailbox but the flow of traffic between you and your peers as well.

Please allow me to take the opportunity to explain to you some of the background of what Kolab Groupware does, and why. In this blog post, I'm zooming in on our use of the submission port (587).

There's a standard 3 ports associated with receiving email messages:

1. Port 25/tcp, or SMTP, which a mail exchanger uses to receive email from the Internet, and from other systems in your network that need to use this mail exchanger as their smarthost (conditions apply). Most commonly, port 25 accepts messages from the Internet for local recipients, or mail traffic from trusted systems inside your network, that are destined for the outside world.
   Typically, no authentication is required, and the envelope sender of a message is not guaranteed to actually be the real human being that would receive your reply should you reply to the envelope sender address.
2. Port 465/tcp, or SMTP with implicit SSL a.k.a. SMTPS a.k.a. SSMTP, which a mail exchanger rarely uses to receive messages from the internet, and only sometimes uses to receive messages from other systems on your network.
   Usually, the internal network is considered as trusted (to some extent). You would want to use SMTPS in networks where the network is not trusted, perhaps including requiring authentication using client-side SSL certificates. At the very least, the implicit SSL nature of SMTPS ensures the communication stream is encrypted.
3. Port 587/tcp, or Submission, which is intended for use by actual human beings. This is the service Kolab Groupware chooses to make use of.

You would not want to use ports 25 nor 465 for submission of data from your groupware users, because both usually include bluntly allowing what is called $mynetworks - the list of IP Address (Spaces) that are trusted networks.

To illustrate, consider the following; You have a LAMP stack that sends out notifications to subscribers via the SMTP port number 25 on localhost. The envelope sender could be something like apache@example.org or noreply@example.org. You would typically have configured (it may actually be the default configuration) "mynetworks = 127.0.0.0/8". The setting "smtpd_sender_restrictions" or "smtpd_recipient_restrictions" typically includes "permit_mynetworks".

Now you install an awesome webmail program called Roundcube, and you configure it to use localhost:25 as its SMTP server. Anyone able to log in to Roundcube is now able to configure an identity with any envelope sender address making messages sent out using that identity appears as if they were coming from that actual envelope sender.

So, joesmo@example.org could now send messages pretending to be the CEO of Example.org, Inc., simply by adding an identity of "The Bossman ", and would go completely unchecked while doing so.

What you can't do is restrict $mynetworks further than 127.0.0.0/8 - your LAMP stack would fail attempting to send messages to your subscribers.

You will want to use a service that does not trust *anyone*, *requires* authentication and *enforces* the user sending the message is authorized to send messages using the envelope sender address of the very message.

I say "authorized to send messages (...)", because one feature that you may need is delegation; the secretary sending a message or two on behalf of the bossman is not a very uncommon scenario.

This is where Kolab Groupware kicks in. We implement pieces of software you are probably already intimately familiar with, and then take it up a notch.

It will not accept messages appearing to originate from an envelope sender address that is within a local domain name space from anyone or anything, unless the actual sender is verifiably authorized to send using the envelope sender address the message will appear to have come from, or unless the sender system is explicitly trusted.

By means of a demo, at Kolab Systems itself, not only do we run a couple of Kolab Groupware deployments, but we also service some mailing lists for third party Free Software projects - hence I can only verify the actual envelope sender address, and not the domain name space:

$ (
> sleep 1
> echo "HELO $(hostname -f)"
> echo "MAIL FROM: vanmeeuwen@kolabsys.com"
> echo "RCPT TO: vanmeeuwen@kolabsys.com"
> echo "DATA"
> sleep 1
> echo "Subject: Nice blog post, thanks"
> echo "Hey there,"
> echo ""
> echo "I think your blog post is awesome."
> echo "."
> sleep 1
> echo "QUIT"
> ) | telnet ext-mx01.kolabsys.com 25

Then do the same against your own SMTP server, with a set of address of your own.