Is kolab srewing up other people's gnupg signatures?

[Ingo Klöcker]

On Wednesday 16 April 2008, Johannes Graumann wrote:
> Johannes Graumann wrote:
> > Hi,
> >
> > I have a somewhat convoluted mail setup:
> > 1. A number of mail accounts all forewarding to a gmail account
> > 2. fetchmail imap-pulling the messages from the gmail account and
> > inserting it into a local kolab installation
> > 3. kontact imap-retrieves the mail from kolab.
> >
> > Recently - not really sure since when - I started noticing that
> > while a self-addressed gpg-signed message validates perfectly well
> > from the "Sent Mail" folder, the received one fails the validation.
> > I can not formally exclude that this is happening on the non-kolab
> > smtp I'm using, but it's unlikely since 2 independent smtp servers
> > at my disposal result in the validation-failure.
> > When diffing the complete exported mime messages - the sent versus
> > the received version - I get the following:
> > # diff Message_Sent Message_Received
> > 0a1
> >
> > 2,3c3
> > < Content-Type: text/plain;
> > <   charset="us-ascii"
> > ---
> >
> >> Content-Type: text/plain; charset="us-ascii"
> >
> > 21c21
> > < Content-Type: application/pgp-signature; name=signature.asc
> > ---
> >
> >> Content-Type: application/pgp-signature; name=signature.asc
> >
> > Something in the kolab suite might/is messing up the message header
> > and invalidates thereby the signature. How might I track this?
> > Who's a likely perpetrator? Do other people see this or is it
> > something I messed up in the configuration?
>
> And btw: looking at the message source at googlemail: they have it
> right, so Kolab definitely is to blame ...

Definitely? It could as well be fetchmail. How do you insert the message 
into Kolab via fetchmail?


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20080418/2175e53c/attachment.sig>