Kochi - in more detail
Kochi is a set of Perl modules, supplied with Perldoc documentation and a couple of examples demonstrating how to make use of the functionality. It also provides a daemon with a ClamAV-style API, allowing it to work with any MTA which can support real-time calls to a ClamAV engine.
This means it can be integrated with any MTA which has the ability to run external scripts - Exim can do this natively using the $perl expansion item; there are also a couple of Perl Milter protocol implementations allowing Sendmail and Postfix to take advantage of Kochi too (although we haven't written a Milter for it - yet!).
Essentially, a message is scanned after the DATA part of the SMTP transaction by passing the decoded message to Kochi which then:
These are configurable, but a good starting point is a regular expression based around the terms "username" and "password".
This regexp can be extended to include as many - or as few, although this makes for false positives so prudence is key here - expressions as required./p>
We're fortunate at Loughborough in that our usernames follow a predictable pattern based on department and the user's name, so we're able to build a regexp to restrict candidate strings to extract only those which match local policy.
Again, we're fortunate here because we have a strong password policy - the character set available for our users to utilise in passwords is defined, which means (again) that the regexp to match possible passwords doesn't match every possible available string in the message. This may not be possible in all systems, and is a good example of policy and technical implementation working together to enhance security.
This is where interoperability starts to be very important. If you run Kochi on a Linux system (or other system capable of using Pluggable Authentication Modules - PAM) then you can make use of a host of different authentication backends. We're using pam_krb5 against a Windows 2003 native Active Directory; this could just as easily be local system passwords, an RDBMS backend, a RADIUS system, some kind of SASL system... the list is almost endless.
However - something very important to understand is that your authentication backend must not lock user's accounts after a preconfigurable number of authentication failures. By design, Kochi will check multiple candidate passwords where they are found - if your system locks accounts after, say, 3 authentication failures then you will very quickly have a lot of locked accounts! It should be noted that Kochi does cache negative results, however, so the same string won't be checked for a period after it previously failed to authenticate. This is a balancing act, which can be tuned.
If authentication succeeds, then (hopefully this part is relatively obvious) the system has detected valid local credentials in the message. How you respond to this depends upon local policy again, but to give an example based around Exim you could:
At Loughborough, we drop the message and send an appropriately worded response to the message sender.