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:
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 email@example.com or firstname.lastname@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, email@example.com 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: firstname.lastname@example.org"
> echo "RCPT TO: email@example.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.