Re: SFL and Balsa

[Brian Stafford <brian stafford uklinux net>]

On Sun, 14 October 18:15 Timothy Ang wrote:
>  You are right, Wil.
>  Like I have told Brian, CDSA was initially sought after for SMIME in Balsa,

Oops, sloppy reading - didn't notice the S before MIME!

>  however, the lack of messaging APIs in CDSA was a big factor in switching
>  over
>  to SFL. Other functionalities like certificate management in SFL are a huge
>  plus
>  in organising certificates with LDAP in Balsa.
>   I am not using PGP because PGP is based on web-of-trust certification which
>  is not
>  the kind of secure email that I have in mind. I need to have a Certificate
>  Authority to
>  administer the certs.

The multipart/encrypted and multipart/signed MIME types make it easy to add
both S/MIME and PGP/MIME.  The "traditional" method of using PGP in mail
is supposed to be deprecated in favour of using MIME.

Anyway the point is having S/MIME does not preclude the use of PGP/MIME.

>  I have managed to integrate SFL in C++ with Balsa last week(with much pain)
>  Would like to share with you guys. Basically gcc is used in Balsa,
>  g++ is used to compile SFL and g++ compiles codes that accesses SFL.
>  By modulising codes that accesses SFL and integrating it into libbalsa
>  library, SFL
>  in C++ can be called.

I am of the opinion that libraries should be written in C and not C++.  C++
is a pain to integrate in non C++ programs.  OTOH, it is trivial to wrap a
well designed C API for more languages than you could shake a stick at.

>  Best Regards,
>  Tim

>  > Another thing is, it is fairly difficult to both support S/MIME and PGP at
>  > the same time (I don't even know of any commercial mailer that can do it).
>  > GPG Made Easy is an API that is supposed to be generic but it looks pretty
>  > young a project.

Wrong.  Read up on multipart/encrypted (RFC 1847).  Any number of mechanisms
can coexist in this framework.

Regards,
Brian Stafford