Mailing List Message #92757
From: John Rudd <>
Subject: Helper Suite (was: Re: Passwords)
Date: Wed, 26 Sep 2007 17:36:33 -0700
To: CommuniGate Pro Discussions <>
Alexander Lázaro Gómez Valdivia wrote:
This Plugin will be very useful, but What with the newbie users who are not logged yet, if they use Outlook or Webmail the Plugin are Welcome! but if your plan to use Pronto! as mail agent, or use XMPP or SIP only, the things goes wrong!.


El Wed, 26 Sep 2007 16:02:44 -0400
 "Andy Kunkle" <> escribió:
Behalf Of John Rudd

I just wrote a new external authenticator that:

if (auth is successful)
    cache the external auth password into the CGP app password
    enable the CGP app password

John, Would you be interested in sharing this authenticator? Is it for a AD
server syncing to a Linux-based CGPro server? It's exactly what I was
talking to a tech at CommuniGate the other day about. It would be perfect if
you used the LDAP=>bind command to authenticate against AD and then if it's
successful, assign that password to the communigate internal password. This
would also allow us to use Pronto for webmail, since as it stands now, I
cannot authenticate since our CGPro accounts don't have a password in them.

I've been working on a suite of helpers for the last year that all inherit from a single Perl object (CGPHelper).  That way someone can write just the parts of a helper that are specific to their case, instead of having to always write the entire thing from scratch.  The classes I have worked up so far are:

         (sort of like sendmail access file)
         (use regexps to match bad attachment filenames, reject
         bad, add-header for good)
         (implement clamav, allow blocking vs add header
         on a regular expression vs virus name, so
         spam/phishing can be marked and accepted)
         (for tracking messages more easily, esp. in a cluster)
         (sort of like sendmail masquerading, via regexp)
         (implement SpamAssassin, lots of customization)
         (implements "NEW", check remote SMTP recipient)
         (caches valid result as a CGP Forwarder object)
         (caches result of valid authentication in CGP App Password)
         (caches result of valid authentication in CGP App Password)
         (implements password auth via Auth::Krb5::Simple)
         (implements password auth via Auth::Krb5::Simple)

Unless otherwise stated, the AuthHelpers don't actually implement password authentication.  They leave open a function/method that you add, which does its own authentication check (it takes a username and password, and you decide if it's valid or not).  So, if you want LDAP auth, you'd just sub-class one of the classes I created, overload the password checking function, and then it should "just work".  The Kerberos helpers are both usable with kerberos, and serve as an example implementation of a specific authentication mechanism.

The MailHelpers all have modes for use with synchronous rules vs asynchronous rules.  So, it should "do the right thing" with one simple config file entry, based on whether you want to reject during SMTP, discard after SMTP, or bounce after SMTP (requires a special setting in addition to "asynchronous rule mode").

All of them use a consistent config file format, and will automatically reload their config file if it changes (so, you can adjust attachment blocking rules on the fly, change your spam assassin header name, or spam threshold, etc.).  They also have a "testing" mode, where you can run the Helper against a Testing directory with pre-populated messages, so you can verify interactively that everything works without impacting production email.

Last, they have internally multiple logging levels, so you can change the level of detail they send to your CGP logs.  The levels are:

      1 - diagnostic messages
      2 - status messages ("entering run loop", etc.)
      3 - errors (systemic errors, like unable to open a file, etc.)
      4 - pass (message or authentication is acceptable)
      5 - fail (message or authentication is not acceptable)

Setting the loglevel to N implies all messages of higher numeric value (so setting to "1" means "log everything").  Setting to 0 or 6+ means "log nothing".

I'm almost done.  I've got to finish up the look-ahead helpers for use on our new MX servers.  Then I'll be happy to make it all public.  Quite a while ago, someone already asked me for the Masquerade helper ... so it's already on my mind.  Probably about 2-4 weeks.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster