The mail log should identify which user account was compromised, and the protocol that was used. You will have to locate the log event that shows how the message(s) was first received by your server.

Here is an example:
[25/Jun/2014 10:39:19] Recv: Queue-ID: 53aaa6d7-000000f4, Service: Kerio Connect client, From: <user<_at_>domain>, To: <user<_at_>domain>, Size: 854, Sender-Host: 10.10.10.1, User: user@domain, SSL: yes, Subject: test, Msg-Id: <3533420989-24989@domain>

The sender address can be spoofed if you don't enable sender anti-spoofing protection (described in KB 1491). You need to locate the original log event where the message was received by the server (like the example I provided in my previous reply). This will provide more details regarding the compromise, specifically, the protocol, the authenticated user, and the offending IP address.
If there should be any viable proposal to improve the security of Kerio Connect we would need to know if the attack could not have been prevented by one of the many security features already available in the product.

We can see from the log event that the messages were sent via SMTP, they were sent by an authenticated user, and the offending host is in Russia (79.104.198.37). This host is also on several blacklists.
Probably a bot guessed this user's password by brute force.
Ways to prevent this:
Password complexity, probably you don't have it enabled.
Blacklists, maybe you don't have any enabled.
Password guessing protection, probably you don't have it enabled.
These settings are all described or linked in KB 1239

Password complexity is enabled.
Black Lists Enabled: SpamCop and SpamHaus
Block user accounts probably targeted by password guessing is enabled.

If there should be any viable proposal to improve the security of Kerio Connect we would need to know if the attack could not have been prevented by one of the many security features already available in the product.

1. Implement default per-account limits on numbers of outgoing emails.
2. Log the authenticated user account for each email sent.
3. Include the authenticated user account name in the email headers.
4. Monitor the mail flow from each account!
5. Check for and reject weak passwords.
6. Rate limit authentication attempts to prevent password cracking.

In your case, as with previous cases I've seen, the offending host uses SMTP. This means that the messages were first injected into the queue via incoming SMTP. Therefore the security options in the SMTP server apply.

In KB 1833 there are some example settings you can use based on the screenshots.
http://kb.kerio.com/product/kerio-connect/server-configurati on/services/securing-the-smtp-server-1833.html
MXtoolbox.com has some nice online tools to help measure the responsiveness of your SMTP server and they can notify you in case of an issue.

We had the same problem, 50k+ spammails sent through a compromised account (probably cross-password-phishing, since the user used the same password for many other services in the net), 33k in the queue the rest was already sent out as we stopped the server.
The costs were about 1-2 days work-time to clean everything up (queue, mailbox, blacklists, spam-signature-lists, explaining to internal and external workers and customers, contact to other postmasters etc.)

This could be prevented, if there were a option to "limit the amount of mails sent by a single user-account"... there would be only few hundreds spammails be sent, if we could set a limit of 100 per hour/user.
We could setup an alert if the logs would contain a warning that the limit was exceeded.

I made a feature-request, please vote up:
feedback.kerio.com/forums/161327-kerio-connect-client/sugges tions/18692392-limit-emails-sent-by-user-by-hour