On Mon, 2002-06-03 at 04:40, Not Zed wrote: > On Mon, 2002-06-03 at 18:21, Adrian 'Dagurashibanipal' von Bidder wrote: > > On Sun, 2002-06-02 at 19:01, Not Zed wrote: > > > > On Mon, 2002-06-03 at 05:16, Jeffrey Stedfast wrote: > > > > > There were some bugs in the 1.0.x PGP/MIME code, these should all be > > > > > fixed now in the development CVS. Perhaps you came accros one of these > > > > > bugs? > > [...] > > > > > I dunno about all, but some more have been fixed. And only for > > > multipart/signed (i dont ever want to support inline pgp, its even more > > > broken). However i ran some tests, and i could generate mails that > > > > Damn. I missed the MIME bit in Jeffrey's post. But I can understand not > > wanting to support inline pgp. Still annoying, though, as they are still > > quite frequent. Perhaps better remove inline support altogether (per > > default), making it an experimental feature instead? Having inline > > signatures not validating half of the time makes pgp/gpg look very > > unreliable, which it isn't in my experience (it works basically > > everywhere except in evolution...) > > Well, inline pgp suddenly stipulates that a text/plain part must be > treated the same way as an 8 bit or binary part. As completely opaque > data. We store data decoded in memory, and so this breaks this > requirement. And we're not about to change it.
Not to mention that it seems PMail (or was it something like PGPMail? I forget the name of the client) sends binary attachments as inline pgp signed data as well - so it's not *just* text parts. This makes it an even bigger PITA. > > > The most annyoing bug for me was that signed mails with attachments > > would never verify. That fixed? > > Well, I sent some multipart/signed parts that had attachments inside > them, and they worked. So, you'll have to test. It hasn't been tested > a lot, I (and jeff?) dont have a great deal of infrastructure to test > with. Right. I've tested a few variations of things that I knew to cause problems before the changes, and they all passed after the patches went in. I can't say it's 100% fool proof now, but we'll see I guess. > > > (It seems building from cvs is a bit too complicated, as some of the > > debian ...-dev pkgs are not current enough (libgal). Do I have to > > rebuild most gnome libraries? Hmmm. I'll just wait for evo 1.2 release, > > I think...) > > gal and gtkhtml are really parts of evolution as far as development > goes, you need to build them both from cvs as well if you are to have > any joy in the process ... > > > > The multipart/signed rfc's are broken, they break valid assumptions you > > [...] > > > if for example any mailer blows apart mime parts and stores them > > > decoded, which imho is a perfectly valid thing to want to do). But > > > > Hmmm. I'd agree that this may be a valid thing to do in the local cache. > > But I strongly feel that the mailer changing the msg body stored in the > > mail spool (or imap dir) without being told so is broken. > > So, how do you then move a message to a system that supports different > character sets? Should you just throw it away? No, you translate the > character sets? What about if a mail is sent in 7 bit format, but your > transport supports an 8 bit or binary format? Or visa versa? It is > entirely upto the transport to decide what transfer encoding methods it > uses to get the content to the other end. Thats the entire purpose of > mime in the first place, it isn't just to view the message content, its > to get it there in a reasonable manner which it can decide. It's unfortunate that the PGP/MIME specification authors forgot this :\ Jeff -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
