GPG support in Mahogany

[Ingo Klöcker]

--Boundary-02=_RT999cU10NV0Nqj
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

On Wednesday 11 December 2002 03:25, David Shaw wrote:
> Oh no, don't do that.  Even if PGP/MIME is better in every single
> detail than plain inline messages, there is one crucial factor: plain
> inline messages are supported in every mail client back to (and
> including) /bin/mail.  Even this many years after its creation,
> PGP/MIME is still only supported in a very few clients.

And therefore it's time to push PGP/MIME. Else this will never change.

> Inline can be trivially scripted ("gpg --clearsign ... | mail"), and
> PGP/MIME can't.

True. But who is still using mail except for automatically generated 
messages? (Yes, I know it was only an example.)

>  Inline doesn't blow up when run through an archiver,
> and PGP/MIME usually does.

Is this PGP/MIME's fault? No, it's the archiver that needs to be fixed.

>  Even mutt, which for years was PGP/MIME
> only finally got inline support as well.  I don't see that as a step
> backwards.

Of course it's no step backwards that Mutt now finally can verify 
clearsigned messages.

> Perhaps the whole world will be PGP/MIME someday, and I'm sure that
> will be wonderful as PGP/MIME handles many important things that
> inline can't (like non US-ASCII character sets), but it's not time to
> stop supporting inline yet.

90+% of the world's population need support for non US-ASCII characters. 
But is there really a problem with non-ASCII charsets? I've been 
clearsigning my messages for a couple of years. And so far there wasn't 
any problems except that a few times some broken MTA stripped the 8th 
bit off of 8-bit characters. The solution to this problem is to always 
use quoted printable instead of 8bit as content transfer encoding.

But PGP/MIME is crucial for signing/encrypting messages with 
attachments. That's simply not possible with OpenPGP.

> Some discussion on this topic:
>
>   http://www.imc.org/ietf-openpgp/mail-archive/msg03786.html

I don't care for mail clients that can't handle PGP/MIME or even MIME 
correctly. We can't always stick to the lowest common denominator. 
Where this ends is nicely shown by web browsers where 50% of the code 
is there just to render all those broken web sites more or less as 
intended by the "web designer". If the first web browsers had been more 
strict most of those workarounds wouldn't be necessary.

Don't using MIME just because some mail clients don't support it 
(correctly or at all) is no solution. Someone has to force the 
developers of those mail clients to support it correctly (namely the 
users which can't view some/any MIME message, which can't verify 
PGP/MIME messages, which can't sign/encrypt attachments). And if the 
developers refuse to fix their product then it's time to choose a mail 
client which does support MIME and PGP/MIME. That's called evolution 
(no pun intended, I'm a developer of KMail which finally supports 
PGP/MIME). The less supportive mail clients die and better more 
standard compliant mail clients rise.

Regards,
Ingo


--Boundary-02=_RT999cU10NV0Nqj
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA999TRGnR+RTDgudgRAlmdAKDPf77EXf3LheX5Npy32uiRxoXoSQCgjNcO
OXlgaOKNz42Kt6/tsM1A26k=
=+QiT
-----END PGP SIGNATURE-----

--Boundary-02=_RT999cU10NV0Nqj--