[sylpheed:31301] Re: PGP/MIME-signing breaks sig delimiter

[Hiroyuki Yamamoto]

Hello,

On Sat, 12 May 2007 14:23:51 +0200
"Michael Schwendt" <mschwendt at gmail.com> wrote:

>     Multipart/signed and multipart/encrypted are to be treated by
> agents as opaque, meaning that the data is not to be altered in any
> way.
> 
> Stripping off whitespace of the end of lines is in violation with that
> guideline. I believe Sylpheed ought not try to work around broken
> PGP/MIME implementation in other MUAs. Instead, it ought to follow
> RFC2015 and be done.

Whitespace-stripping is done *before* signing, so it is not a violation.

>     For this reason all data signed
>     according to this protocol MUST be constrained to 7 bits (8- bit
> data should be encoded using either Quoted-Printable or Base64).
> 
> Contrary to that, I see that Sylpheed creates PGP/MIME signed
> "text/plain, UTF-8, 8bit" message content instead of encoding it QP,
> 7bit. Try it by signing Unicode content.
> 
> So, the real fix looks more like the code that is disabled with "#if
> 0" below the strchompall call in compose.c. I hope that Hiroyuki can
> enlighten us about the reason for the strchompall attempt. What was
> the original problem?

Yes, removing strchomp_all() and re-enable the code disabled by "#if 0"
will revert it to the previous behavior.

The original problem is that some MUAs such as Outlook Express and
Eudora (and some more?) doesn't handle PGP/MIME + quoted-printable
encoding well (well, OE is broken anyway), and the receiver results in
seeing corrupted messages (at least in Japanese).

In conclusion, I think it should be reverted to the previous behavior,
but with some exceptions (if charset=ISO-2022-JP, send with 7bit with
stripping trailing whitespaces).

-- 
Hiroyuki Yamamoto <hiro-y at kcn.ne.jp>