Mailing List CGatePro@mail.stalker.com Message #92770
From: Bret Miller <bret.miller@wcg.org>
Subject: RE: Helper Suite (was: Re: Passwords)
Date: Thu, 27 Sep 2007 07:58:17 -0700
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: CommuniGate Pro MAPI Connector 1.2.12/1.2.12(local)
Awesome! Can't wait to see it.

Bret


> 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" <akunkle@aimengr.com> 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:
>
>
>    CGPHelper
>      CGPMailHelper
>        CGPAccessMailHelper
>           (sort of like sendmail access file)
>        CGPAttachmentMailHelper
>           (use regexps to match bad attachment filenames, reject
>           bad, add-header for good)
>        CGPClamAVMailHelper
>           (implement clamav, allow blocking vs add header
>           on a regular expression vs virus name, so
>           spam/phishing can be marked and accepted)
>        CGPLogHelper
>           (for tracking messages more easily, esp. in a cluster)
>        CGPMasqueradeMailHelper
>           (sort of like sendmail masquerading, via regexp)
>        CGPSpamAssassinMailHelper
>           (implement SpamAssassin, lots of customization)
>      CGPAuthHelper
>        CGPLookAheadAuthHelper
>           (implements "NEW", check remote SMTP recipient)
>        CGPCachedLookAdheadAuthHelper
>           (caches valid result as a CGP Forwarder object)
>        CGPCachedAuthHelper
>           (caches result of valid authentication in CGP App Password)
>        CGPCachedKerb5AuthHelper
>           (caches result of valid authentication in CGP App Password)
>           (implements password auth via Auth::Krb5::Simple)
>        CGPKerb5AuthHelper
>           (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