[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Problem with passphrase entry
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2002-07-31 0:11:06
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 July 2002 05:29, Malte Starostik wrote:
> Well, as I said before, I never had any problems with 8bit CTEs, they
> only appeared after the "aegyptifycation".

We had at least one person on this list who couldn't verify my signed 
messages because of problems with 8bit CTE. After I changed to 
QP-encoding he could verify my messages. So at least one year ago there 
still was at least one MTA which didn't support 8bit correctly.

> As already stated the
> problem is IMHO not using 8bit in general, but using 8bit in a MIME
> part that is child of a mail marked as 7bit. i.e.
>
> Main message - CTE: 7bit
> 	signed data - CTE: 8bit
> 	signature - CTE: 7bit
>
> I bet once this is changed to
>
> Main message - CTE: 8bit
> 	signed data: CTE: 8bit
> 	signature - CTE: 7bit
>
> the problem goes away, since some MTAs will honour the 8bit in the
> mail's header but not give a damn about 8bit-cleanness if the mail
> header states it's 7bit (MTAs won't look into child MIME part
> headers...). How should a child part of a 7bit part guarantee
> 8bit-cleanness?

You are most likely correct. But as Marc already wrote the signed data 
MUST not be 8bit encoded according to the RFCs.

So there are two bugs in the Aegypten code:
1. Signed data must not be 8bit encoded.
2. If a message part is 8bit encoded then this must be announced in the 
main header.

Regards,
Ingo

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

iD8DBQE9RxZiGnR+RTDgudgRAtuoAKDI5eEQ7NI/TH8xmSZ/Eu7Jnl3+kgCgy573
9E7BTEjMuR+s8ppLwN6n3tQ=
=LiGk
-----END PGP SIGNATURE-----


_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]