Re: Start implementing GnuPG support...

[Brian Stafford <brian stafford office-logic com>]

Pawel Salek wrote:

> On 2001-02-16 11:15 Jose C. García Sogo wrote:
> 
>>  I think this is the way Balsa should go. But I have not found any
>> conclusion about if Pawel is going to start using it or not.
> 
> 
> 1. I confirm that libmutt will be deprecated - sooner or later.
> 
> 2. GMime seems very promising but I haven't figured out possible
> conflicts with libESTMP and/or camel which both seem quite appealing.
> Can somebody tell us some details about these packages?

As the author of libESMTP I can comment on its (intended) use.

As far as libESMTP is concerned, one of my design goals is that it should
process *only* RFC 822 message headers and remain "orthogonal" to MIME.
In a modern email message, the RFC 822 headers and the MIME headers
are mixed up together at the top level.  libESMTP therefore processes
only top level headers as required to ensure RFC 822 compliance
or to remove headers that should not appear in a message which is
in-transit, e.g. Return-Path:.  It takes special care to avoid any kind
of processing of MIME headers which could potentially corrupt a MIME
document.   The idea is that it is possible to create a MIME document
and feed it into libESMTP which will add the required RFC 822 headers
if necessary.

I have no intention of ever adding MIME capability to libESMTP, I believe
this functionality is best implemented elsewhere such as in Gmime.  Not
all MIME documents are email messages and not all email messages are MIME
documents.  In that respect, if use of libESMTP conflicts with use of
Gmime, that would be regarded as a bug in libESMTP.

Gmime also has the ability to add RFC 822 headers in addition to MIME
headers.  This functionality is not strictly part of MIME.  That said
this will not cause libESMTP a problem - in a program using both libraries
there is a choice of which API should be used to create RFC 822 headers.
Which one is best is probably down to how the application works or
programmer preference.  I have tried not to force users of libESMTP
down any one path in this regard.

As an aside, the eagle eyed may have spotted that libESMTP doesn't
process headers yet.  That code should be completed over the weekend.
Watch for an announcement on Freshmeat next week, the full set of core
functionality will then be in place.

> I am occupied with other parts of the code and I don't really have time
> to look into this myself (sorry).
> 
> /Pawel

--
Brian Stafford