none of them has a problem with mail from KMail - other than, it seems, ZIMACS.
Possibly - maybe in the same way that IE has no problem with websites written in Frontpage?
No, more like the way IE doesn't have any sort of decent CSS implementation so everyone else is supposed to hang back and wait - a *much* more accurate and correct analogy to draw, if you ask me, except that zimacs is the 1%.
PGP/MIME over 7bit is *not* Microsoft Hairball (Frontpage HTML). There is no parallel, I think.
I used to be a Zetnet user a few years ago and I remember back then that ZIMACS was a horrible e-mail client - so much so that I refused to use it. Seems like it hasn't changed.
Nowadays, if we (beta testers, or anyone else for that matter) find a problem, it's very often fixed the same day and the new version on the alpha site for download.
Well each to their own, I say. Can I just say that I'm not sure the empty boxes and spaces a few of us are seeing, are the result of everything being done in a standard manner. :)
You may have a problem that needs sorting.
I'd love to have a look at zimacs myself, but I can't seem to get Visual Basic apps running on Wine at the minute, having zapped my old config with the recent changes to Wine. :D
Like I said, the world has moved on. MIME aware software has been standard for at least 10 years. Anyone not using MIME aware software should either upgrade or put up with the consequences - its
I agree to a certain extent. Quoted-printable is to be considered an old encoding now, it's also referenced by various *real* standards (not nntp aups, see below) through the last decade or so.
We always endeavour to not muddy the waters with _unnecessary_ encodings, of course, but you have got to try very, very, very VERY hard indeed to consider quoted-printable a new-fangled or standards-defiant encoding, and qp does happen sometimes.
Where's the QP-aware version of grep and awk?
A bit of a facile point to not make if you don't mind me saying so, especially in reference to "MIME-aware software", since neither has any more or less support for MIME or qp than anyone would expect.
As well to ask which version of grep supports bicycles, or biscuit tins.
:-)
8bit is (usually) a more sensible choice even within MIME than QP: it's both smaller and more readable in the absence of MIME software. Why the resistance to using it?
Where 8-bit is more suitable than qp, 8-bit is more sensible and vice versa.
Certainly a logical truism. :)
PGP signed MIME messages are 7bit affairs, however, so must use Content-Transfer-Encoding to ensure that 8-bit data gets constrained to 7-bit data... :)
Of course, if the user only uses 7bit data, qp becomes unnecessary. As does 8bit.
Carry on long rambling bandwidth wasting conversations about email via email mailing lists quoting "standards" but not including references to the relevant RFCs, so people watching end up no more informed than at the beginning. Conversations that almost threaten to turn into a flame war but havn't quite got enough fuel them to get there.....
;)
In this case I think the reluctance to get into a flamewar is what's prolonging the dead horse flogging, heh.
Of course you're right about muttering the word "standards" in a vague way and not explaining what seems to be happening.
Generally speaking, I tend to avoid the whole "RFC this" and "RFC that" thing like the plague, since it only seems to provide that fuel you're talking about and generally carries the ambience of some terrible slashdot Fred.
Besides which, it's often a zero-sum game because there'll be some caveat someone can apply which makes them right under another RFC if they qualify it enough :)
Anyway, to address the vagueness here*...
As regards Anthony's position on qp being a standards-buster, I think we're talking about misinterpreting and then misapplying the "plain-text only in emails" restrictions of RFC822/2822 *in the wrong circumstances* on everybody else in the world because one non-standard windows-only MUA demands it.
This seems like a nonsense for various reasons, not least of which are:
~RFC2822 does not effectively restrict message bodies to what Anthony considers plaintext, only headers,
...and...
~people use pgp/mime signed mails on mailing lists these days and such restrictions do not (cannot?) apply to these messages in anyone's book, they fall within the remit of PGP/MIME standards (notably RFC's 2015 and 3156) which quite specifically allow for using quoted-printable If It Seems Like A Good Idea At The Time(tm).
It's largely unnecessary to use quoted-printable encoding, so most of the time we don't use it.
Of course when we send an ordinary email and think better of something, we might ignore trailing spaces etc. as unimportant - but when kmail notices them in a pgp-mime message, it knows they *must* be represented at the other end, and via 7 bit (rfc3156) too, so it uses qp(rfc2015).
This seems entirely sensible behaviour on the part of the MUA.
I would go even further - it's my _personal_ opinion that if your client does not support the requirements of MIME, it is not MIME-compliant/aware, and that therefore any MIME messages you can't read are YP.
Since 'some' messages now use mime and pgp/mime, c'est la vie, really.
YES! I want to waste space on everyone's hard disks and the network. Please rush me my guide to how to send my emails with unnecessary Content-Transfer-Encodings as a base64'd ASCII text file.
To be fair, it looks like the umbrage was taken not with avoiding unnecessary encodings - nobody would dispute that we use plain encodings where we can. Nobody's going to just say "well tough" to people, when all they want is readable email.
I think it's the preposterous idea that quoted-printable is some non-standard munging on a par with obscure Microsoft EAE formats(HTML mails, frontpage hairball and Word specifically), and that kmail is guilty of behaving like MS word or frontpage, and we're all to be ashamed of ourselves for breaking standards, when quoted-printable encoding is not.
Now, I can see everybody else's point here, and I've seen too many "is/isn't qp evil" arguments to get at all riled about this one, heh.
It may be ebil, but it is not standards-breaking behaviour on a par with MS.
*Disclaimer: IANA(RFC)L