On Mon, 2002-06-03 at 10:40, Not Zed wrote:
On Mon, 2002-06-03 at 18:21, Adrian 'Dagurashibanipal' von Bidder wrote:
[...]
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.
why not make signature verifying a part of the decoding process - if you're insisting that you want to store decoded data that would probably be the only way. But I agree that inline pgp is quite ugly, because you don't know it's there before having scanned the text.
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.
Ok, I'll look forward to testing it. I don't send attachments frequently, but as I'm signing all my mail, I naturally noticed this particular problem.
(It seems building from cvs is a bit too complicated, as some of the
[...] Ok, thanks (Rodrigo, you too) for clarifying this. Which branches am I to take?`evo HEAD goes together with gal and gtkhtml HEAD, too?
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). ButHmmm. 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
A MTA should NEVER eat/change anything in the body of the mail. An MTA shouldn't even need to know about MIME (that's why MIME was designed in the first place). MIME allows anything to be encoded 7bit clean, so there should not be any MTA barfing on any MIME mail. Today, most MTAs are 8bit clean, so some MUA send 8 bit mail, but I find this to be a bit risky, as there are still some 7bit MTAs out there (and, IIRC exim for example does not advertise it's 8bit capabilities per default). So 8 bit mail --> 7 bit MTA is the only problem I can see. Bouncing the message in this case is not really acceptable, but I don't think breaking signed mails for this case can be avoided. But - as I said - I feel MIME mail should always be 7bit clean. Decoding - and transforming charsets - is something that belongs at the very end where the mail is displayed. (Of course, how MTAs and MUAs should deal with broken MIME and non-MIME messages is another question alltogether... and unfortunately one that comes up frequently)
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.
But what *is* that 'transport' you're speaking about? imho it must not
be the MTA deciding to encode the mail, but a part of the MUA. The
reason for this is that the MUA has the information to decide what
encoding makes sense, the MUA is usually not a bottleneck, while a MTA
is sometimes busy enough just piping messages to the right destination.
And: the MUA is in user control, so the sender of the message can decide
how the msg should be sent.
Of course, the downside is that the MUA has to make some worst case
assumptions about the MTAs the mail will pass along the way. But with
sending 7bit clean msgs this should mostly taken care of.
Ok, 'nuff said. As I'm not an evo-hacker I'm fully aware that I'm not
the one to make architectural decisions here :-) But I think the Mutt
author (was it him?) had it right: all mail clients suck. Some really
suck, and some are useable. evo is definitely one of the latter, so keep
up the good work & thanks for the most insightfull discussion here.
cheers
-- vbi
--
secure email with gpg avbidder fortytwo ch: key id 0x92082481
avbidder acter ch: key id 0x5E4B731F
Attachment:
signature.asc
Description: This is a digitally signed message part