On Mon, 16 May 2011 13:59:51 -0700, Carl Worth wrote:
> So what I'd love to see from here is a commit with a description like
> the above, and then a test case looking like your example.
>
> From there, I'd next like a new version of the commit that gets the
> intended behavior with less code
lol, made my day!
Simon
On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote:
> On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
>> So a message like this:
>>
>> A???multipart/signed 355339 bytes
>> B ???multipart/mixed 353462 bytes
>> C ???text/plain 235 bytes
>> D ???image/jpeg attachment
On Mon, 16 May 2011 13:59:51 -0700, Carl Worth cwo...@cworth.org wrote:
So what I'd love to see from here is a commit with a description like
the above, and then a test case looking like your example.
From there, I'd next like a new version of the commit that gets the
intended behavior with
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins wrote:
> See mml-secure-message-sign-pgpmime to sign an entire message, as
> opposed to just a single part.
Thanks! That's good to know. (Trying here.)
> I think the two paths reconverge later in the series. Can you look
> ahead a bit
On 05/16/2011 05:20 PM, Carl Worth wrote:
> Interestingly, this is not quite the behavior I get (with commit
> 373f352). With --format=text I'm now seeing:
>
> 2) C
> 3) D
> 4) E
--format=text should only show the parts that are readable in text.
the ultimate goal is to get the part numbers
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
> So a message like this:
>
> A???multipart/signed 355339 bytes
> B ???multipart/mixed 353462 bytes
> C ???text/plain 235 bytes
> D ???image/jpeg attachment [foo.jpg] 352752 bytes
> E ??application/pgp-signature attachment [signature.asc] 1030
On 05/16/2011 04:42 PM, Carl Worth wrote:
> Meanwhile, I still can't tell exactly what the behavioral change
> intended is. The commit message talks about "fully recursing"
> and "match[ing] the MIME structure of the message". Was it not
> fully recursing before? In what
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth wrote:
> I'll have to learn better how to control the emacs mail composer in
> order to understand how to get signatures to cover attachments if I want
> to do that kind of thing.
See mml-secure-message-sign-pgpmime to sign an entire message, as
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor wrote:
> So a message like this:
>
> A???multipart/signed 355339 bytes
> B ???multipart/mixed 353462 bytes
> C ???text/plain 235 bytes
> D ???image/jpeg attachment [foo.jpg] 352752 bytes
> E ??application/pgp-signature attachment
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor wrote:
> before, the output was a linearized version of the mime tree, in
> particular removing the multipart pieces and only enumerating the leaves
> in a depth-first walk of the tree.
>
> So a message like this:
[snip example of change]
On 05/16/2011 04:42 PM, Carl Worth wrote:
Meanwhile, I still can't tell exactly what the behavioral change
intended is. The commit message talks about fully recursing
and match[ing] the MIME structure of the message. Was it not
fully recursing before? In what way did
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
before, the output was a linearized version of the mime tree, in
particular removing the multipart pieces and only enumerating the leaves
in a depth-first walk of the tree.
So a message like this:
[snip
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
So a message like this:
A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
E └╴application/pgp-signature attachment [signature.asc] 1030 bytes
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
So a message like this:
A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
E └╴application/pgp-signature
lol, made my day!
Simon
On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote:
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
So a message like this:
A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
On 05/16/2011 05:20 PM, Carl Worth wrote:
Interestingly, this is not quite the behavior I get (with commit
373f352). With --format=text I'm now seeing:
2) C
3) D
4) E
--format=text should only show the parts that are readable in text.
the ultimate goal is to get the part numbers aligned
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth cwo...@cworth.org wrote:
I'll have to learn better how to control the emacs mail composer in
order to understand how to get signatures to cover attachments if I want
to do that kind of thing.
See mml-secure-message-sign-pgpmime to sign an entire
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
See mml-secure-message-sign-pgpmime to sign an entire message, as
opposed to just a single part.
Thanks! That's good to know. (Trying here.)
I think the two paths reconverge later in the series. Can
18 matches
Mail list logo
