This is an experimental posting: A gpg clearsign text document
containing the actual message, has been attached to this email via mime
encoding. If you desire to verify the gpg sig you may need to save the
attachment to disk with any standard mail client and use a gpg utility
on it... If this method is bothersome, please let me know why.
Thanks!
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <<jtwdyp@xxxxxxxx>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It would appear that on Sep 11, Michael Schwendt did say:
> On Fri, 10 Sep 2004 18:16:46 -0400, Joe(theWordy)Philbrook wrote:
>
> > OK, so basically for _normal_ users, when mail clients deploy gpg as a
> > detached sig, the only reasonable way to verify or if needed, decrypt
> > the message would be to choose a similar mailclient...
>
> Yes, one that implements PGP/MIME support.
>
> > That's so much like
> > M$'s way of thinking that I wouldn't choose to use that method even if I
> > "liked" any of the gui mail clients...
>
> Can you explain that theory of thinking further?
>
If they wanted to have implemented a tool that allows ANYONE to verify
it shouldn't have been hard for them to base the automatic processing
one something that any mime capable mail tool could save the
attachment(s) to disk. And have them be all you need to feed to gpg...
If they designed it that way, then the integrated package would still be
able to do it on the fly.
> > Especially when/if a user of such
> > a mail client wants to verify, or decrypt some ascii armored message
> > body from me, all they should need to do is to save the message as a
> > temporary text file, and run a command line utility on it,
>
> ... and run into problems when some mail relay converted the original
> content encoding to something else, e.g. 8-bit to quoted-printable or
> vice versa.
>
I was not aware of that...
Hmmmn what happens to an ascii armored clear text signed text document
disk file that is simply attached (with ANY mime capable mail client)
to an email message with an short actual text body possibly containing the
advice that "To actually verify the ascii armored text content, save the
text attachment to disk and invoke gpg on it..." Letting the mime take
care of restoring the original form of the ascii armored text file so
that gpg can work on it???
That is:
Would:
A) mime successfully restore the attachment to file in gpg
recognizable condition on any kind of consistent basis?
B) those who only want to read the contents without bothering
verify the clearsign sig, be able to simply read the
text regardless of any "content encoding conversions" that
may occur? ((Much the same as the text attachment of a detached
sig style email can at least be read (if not actually
encrypted) by any standard mail client...))
C) Hopefully both A & B might apply?
Perhaps we should test this theory?
> >
> > - --
> ^^^^ This is an ugly side-effect of inlined PGP signing. The
> signature separator is escaped with a leading '- ', and most--if not
> all--mail user agents won't recognize it anymore. E.g. I had to strip
> off your overlong signature manually. Signatures should not exceed
> four lines of text.
Is this any better?
#################################################################
# gpg sig for: Joe (theWordy) Philbrook <JtWdyP@xxxxxxxx> (:-0% #
# You can find my public gpg key at http://pgpkeys.mit.edu/ #
#################################################################
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBQmtyRZ/61mwhY94RAt9BAKDJzZ4clVI5UqhFRITMczpAY3hyhQCfVIN3
gGvSacNKh12C3yR3QebpcB4=
=3hoE
-----END PGP SIGNATURE-----
