[Evolution] Attaching emails invalidates PGP signature
Not Zed
notzed@ximian.com
Mon, 02 Aug 2004 14:00:14 +0800
--=-/MX4iWtUPCwl0lP89qg5
Content-Type: multipart/alternative; boundary="=-YD6aJGFXrFYzKVwgDFDx"
--=-YD6aJGFXrFYzKVwgDFDx
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Sun, 2004-08-01 at 22:45 -0500, Ron Johnson wrote:
> On Mon, 2004-08-02 at 11:12 +0800, Not Zed wrote:
> >
> > > The problem is "how does Evolution know to scan thru all the emails
> > > on your system, and know exactly which attachments to convert from
> > > application/octet-stream to message/rfc822?"
> > >
> > > I don't think they can.
> > But that isn't how drag and dropped messages work when dragged
> > internally. It sends them as uids+folders in 1.5.something+, so they
> > can't be anything but the right type.
> >
> > They have to be encoded right at the sending end to start with if
> > they're ever to be recognised later.
>
> I thought that was what the bug was.
>
> When I ran 1.5.9.1, a drag-n-dropped email was attached as
> application/octet-stream.
>
> When I upgraded to 1.5.91 and tried again, a drag-n-dropped email
> was attached as message/rfc822.
It was fixed after 1.5.9 sometime.
Do you rely on the pattern of the name of the attachment to notice
> that it is a uids+folder, instead of the mimetype? If so, there
> is still a bug, because Evo 1.5.91 looks at that application/octet-
> stream attachment, and will only let me Save As.
No no, its only in the drag and drop. As the last statement said above
the mime type MUST be set at the sending end, we never try to guess it
at the recieving end. It was a sending bug earlier in the 1.5 series.
--
Michael Zucchi <notzed@ximian.com>
"born to die, live to work, it's all
downhill from here"
Novell's Evolution and Free Software
Developer
--=-YD6aJGFXrFYzKVwgDFDx
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.1.18">
</HEAD>
<BODY>
On Sun, 2004-08-01 at 22:45 -0500, Ron Johnson wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">On Mon, 2004-08-02 at 11:12 +0800, Not Zed wrote:</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> > The problem is "how does Evolution know to scan thru all the emails</FONT>
<FONT COLOR="#000000">> > on your system, and know exactly which attachments to convert from</FONT>
<FONT COLOR="#000000">> > application/octet-stream to message/rfc822?"</FONT>
<FONT COLOR="#000000">> > </FONT>
<FONT COLOR="#000000">> > I don't think they can.</FONT>
<FONT COLOR="#000000">> But that isn't how drag and dropped messages work when dragged</FONT>
<FONT COLOR="#000000">> internally. It sends them as uids+folders in 1.5.something+, so they</FONT>
<FONT COLOR="#000000">> can't be anything but the right type.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> They have to be encoded right at the sending end to start with if</FONT>
<FONT COLOR="#000000">> they're ever to be recognised later. </FONT>
<FONT COLOR="#000000">I thought that was what the bug was.</FONT>
<FONT COLOR="#000000">When I ran 1.5.9.1, a drag-n-dropped email was attached as </FONT>
<FONT COLOR="#000000">application/octet-stream.</FONT>
<FONT COLOR="#000000">When I upgraded to 1.5.91 and tried again, a drag-n-dropped email</FONT>
<FONT COLOR="#000000">was attached as message/rfc822.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
<PRE>
It was fixed after 1.5.9 sometime.
<FONT COLOR="#000000">Do you rely on the pattern of the name of the attachment to notice</FONT>
</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">that it is a uids+folder, instead of the mimetype? If so, there </FONT>
<FONT COLOR="#000000">is still a bug, because Evo 1.5.91 looks at that application/octet-</FONT>
<FONT COLOR="#000000">stream attachment, and will only let me Save As.</FONT>
</PRE>
</BLOCKQUOTE>
No no, its only in the drag and drop. As the last statement said above the mime type MUST be set at the sending end, we never try to guess it at the recieving end. It was a sending bug earlier in the 1.5 series.
<PRE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<TABLE CELLSPACING="6">
<TR>
<TD>
<IMG SRC="cid:1091426405.17934.6.camel@lostzed.mmc.com.au" WIDTH="48" HEIGHT="48" ALIGN="top" ALT="" BORDER="0">
</TD>
<TD>
<B>Michael Zucchi</B> <<A HREF="mailto:notzed@ximian.com">notzed@ximian.com</A>><BR>
<I>"born to die, live to work, it's all downhill from here"</I><BR>
<TT>Novell's <A HREF="http://codeblogs.ximian.com/blogs/evolution/">Evolution</A> and <A HREF="http://www.gnu.org/philosophy/free-sw.html">Free Software</A> Developer</TT>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</PRE>
</BODY>
</HTML>
--=-YD6aJGFXrFYzKVwgDFDx--
--=-/MX4iWtUPCwl0lP89qg5
Content-ID: <1091426405.17934.6.camel@lostzed.mmc.com.au>
Content-Disposition: attachment; filename=zed-48.small.jpg
Content-Type: application/octet-stream; name=zed-48.small.jpg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4p
LSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk//2wBDAQ4ODhMREyYVFSZPNS01T09PT09P
T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0//wAARCAAwADADASIA
AhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAwQFAgYB/8QALhAAAgEDAgUEAQIHAAAAAAAAAQID
BBEhABIFEzFBURQigZEGYXE0UmJyobHx/8QAFwEBAQEBAAAAAAAAAAAAAAAABAMCAf/EAB0RAAID
AQEAAwAAAAAAAAAAAAABAgMREjEiMkH/2gAMAwEAAhEDEQA/AK8sEEq35nLaP3e1cW/m8kfdtAfh
824L7I1YFrnaRt8+L40U1ECxiGjLzSCocRYuQhubW7jIxrcFZRzU7q3sh3e8deWvX67/AKX0Xegi
TixevoZdxjhnkk2xBj2Z7DIA74Gs+kgpoaamPLllqE5yPuO4i1+nix7+NS3qatikPNZa+idmjLGx
YE+7r16DHgnTEtRWTVIraiknUrE42mJvYTY/IyfjT66YZjNzkzSSRTrEYTuz0tbpg6oV1V62op5G
3QhV9yn+7t8DXPDiZlaepq0AYIBGEFtuRc2/WwH7aroXho98jNG5RVa4wDYNbzqNsefqdcnmM0J0
pp1kKyRywsdpU46EX/19aT4ioWgmanATG0Mpvcd89750arjMg2L1DfQtnSixTMW5hO0ZBZsEg5t5
xodU+8fhit7jZz4ChQWS99U1lC0H8RNZx74xK2DkAG48ePOtU0UUsQLC6kki/wC+jqtMpeLapjYg
XJyNLcxyr1EUHaWaEspHXPbXVcNkUcCUOjvNv2kAdAehOkVo4LrDEFG9hcnPe+rlUsNNSenUIWkk
ZHfbflqFC475IvqdnyWaRsgl6MNwysp13y8uLG3cTk6LBwCmliFR6lw7XBKdMdj50t+X8RkWOnhV
rbnLfX/dUPx1ivAoTJnmFm+CdIVEIx6XpFQSZxVVH6KrkRRaAudn9I8HXhniSPcyC/ntqzxOjMNS
6uNyMbqT0I1Ogoad6pF5S23C4t1zqOa8Y7xbEDSxmesguHDId4DKQDjGqMqHmNLGygFnujAZF8DF
820/xYpQ8RWcRLtkBINuh6Ef5B0tNRH0L7UEjGzCVTZirDBGfJ+NasrcMf4CnLp6f//Z
--=-/MX4iWtUPCwl0lP89qg5--