[ale] testing firegpg with mailman

[Jeremy T. Bouse]

Jim Kinney wrote:
> OK. Since this began I've sent several messages as well others through
> the entire ALE mailman process. I am receiving valid signatures on
> messages. During this time, nothing has changed with mailman or
> mailscanner.
> 
> What email cleaners are you using? procmail filters? thunderbird
> autosort filters?
> 

	I'm using Thunderbird with Enigmail plugin... I also have the Display
MUA plugin installed so I can tell what MUA a message was sent with...
Other than that just Thunderbird filter rules to sort mail into folders
based on the List-Id header.

	As I've stated though I've sent email from Gmail using FireGPG to my
personal email address that Thunderbird checks and the signatures have
been valid; however, anyone's email sent from Gmail with FireGPG has
been invalid.

> On Sat, Nov 28, 2009 at 7:04 PM, Tim Watts <timtw at earthlink.net
> <mailto:timtw at earthlink.net>> wrote:
> 
>     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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20091129/96955d9e/attachment.bin