[ale] testing firegpg with mailman

[Tim Watts]

On Sat, 2009-11-28 at 16:06 -0500, Jeremy T. Bouse wrote:

> 	I've been sending gpg signed messages through Thunderbird using
> Enigmail without problems. Further I've sent emails to myself from Gmail
> using FireGPG and the signature was come through fine. I just hadn't
> sent anything to the list from my Gmail account and using FireGPG.
> 
> 	As I noted though FireGPG was base64 encoding the messages themselves
> along with the MIME encoding so I don't know if it's that combination
> that's causing a problem for the ALE mailing list software. It has been
> isolated to email sent via FireGPG though it seems. Whether the fix
> should be found in the mailing list software or FireGPG itself could
> probably be debated in great length.
> 

In this particular case it's being caused by something wrapping a header
in the signed portion of the message body.

If you use Evolution try this experiment:
1. Export Jim's email with the invalid sig (File / Save Message)
2. Change lines 57-58 from this

Content-Type: multipart/alternative;
	boundary="firegpg0710eqg2kkoajgv6vsvmxiqq1"

   to this:

Content-Type: multipart/alternative;
boundary="firegpg0710eqg2kkoajgv6vsvmxiqq1"

(i.e. unwrap the header and leave a single space before "boundary=")
3. Import it.
4. Enjoy the valid signature!

(You can probably do something similar w/ Thunderbird.)

Conclusion: the wrapped header caused the sig to be invalidated.

Open question: Who wrapped it, Mailman, firegpg or gmail?

My answer: probably mailman. On what grounds? Using a message sent to
ALE via gmail/firegpg, I compared the raw message sent by mailman to the
one stored in my gmail Sent folder. Firegpg sends messages by going
around the gmail web interface and sending them to gmail directly via
smtp. Thus the copy in my gmail Sent folder would reflect what firegpg
sent whereas the one in my inbox from ALE reflects what mailman sent.
The difference (apart from an additional envelope) was in that one
header, which when corrected, gave a valid sig.

Now what I haven't seen is the raw message as it arrives at the ALE mail
server. That would be interesting because it would tell us whether
mailman or gmail wrapped the header. Also looking at the message just
before it leaves the server could help. Perhaps there's another layer
after mailman (as Jeremy suggests below).


> 	If anything running on the ALE mail server that would affect mail going
> through the list could be a cause. If it's not repacking the message
> back exactly as it was received this would invalidate the signature very
> easily...
> 

Which seems to be what's happening.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20091128/6fe1fb77/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20091128/6fe1fb77/attachment.bin