On Thu, Nov 29, 2001 at 10:03:55PM -0500, Jeffrey Stedfast wrote: > On Thu, 2001-11-29 at 21:27, Thomas O'Dowd wrote: > > On Thu, Nov 29, 2001 at 08:33:42PM -0500, Jeffrey Stedfast wrote: > > > On Thu, 2001-11-29 at 20:15, Thomas O'Dowd wrote: > > > > It takes care of escaping the "^From " for you so you don't have to > > > > worry about it. > > > > > > That's nice, but it doesn't take care of QP encoding it and I'm not too > > > sure that it CRLF encodes it either. > > > > Hi Jeff, > > > > the -t option on pgp takes care of the crlf issue for you. With respect > > to the quoted printable, you sign first, then if you want everything 7bit > > clean you qp it. The receiving mailers will unqp it first if the header is > > there. Unfortunately for evolution, you don't do this so the signature > > won't validate. I would argue that evolution is wrong in this case. You > > might argue that this is exactly the problem with one mailer doing this > > and the other mailer doing something else, but I think this is the only > > rule that actually makes sense. (ie, unqp and then validate or sign and > > then qp depending on which way you are going) > > > > Take the example where your mta server accepts 8bit and the mailer > > pgp signs your message leaving it as 8bit. If it goes 8bit all the > > way to the receiver there is no problem. Then, there is the problem > > where an intermediatory mta will decide to translate your 8bit mail > > to qp. This is pretty normal, it will add the quoted-printable header > > and your mailer will recieve the mail. If they don't unqp it first > > then pgp won't validate, which is why the majority of mailers handling > > inline pgp, unqp first before passing it to pgp for validation. I > > think evolution is doing the wrong thing here. > > You might try reading rfc2015 before saying Evolution does the wrong > thing, rfc2015 (PGP/MIME) specifies that the client MUST QP/Base64 > encode the content before signing. > > So no, we are not wrong at all.
I was talking about inline pgp which is not covered by that rfc except to say that inline is a bad idea, albeit one that needs to be supported because of other non-compliant mailers we need to talk to. With regard to doing pgp the rfc way, I think evolution is doing the right thing. Fact is though that we need to support inline pgp or evolution will remain unusable for me because I need Outlook and TheBat! mailers to be able to decrypt and verify my mails. Evolution currently has problems verifying inline PGP signed messages from mailers when they are qp'd by a gateway along the way. Mutt doesn't have that problem so I'm suggesting being liberal (as it is inline pgp anyway) and unencode first then verify which is what other mailers seem to do. With regards to sending 8bit signed inline pgp emails, I haven't tested what is the best thing to do yet, but it looks like sign and then qp is what will work with most email clients. I'm sure there are loads of people who'll appreciate it if we get this working with the big email clients. I don't have direct access to other windows clients but I'll hand create some test emails to friends and see what works. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
