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

[Hiroyuki Yamamoto]

Hello,

On Mon, 14 May 2007 11:31:32 +0200
"Michael Schwendt" <mschwendt at gmail.com> wrote:

> > Whitespace-stripping is done *before* signing, so it is not a
> > violation.
> 
> Right. At the sender's side, but not at the recipient's side.
> 
> Apparently, based on your later comment, some MUAs *do* alter the
> message contents prior to *verifying* the signature.

No, I just said some MUAs can't handle quoted-printable well.

> I didn't say that Sylpheed violates the guideline. Actually, it
> doesn't matter whether the user deletes whitespace or whether Sylpheed
> does it *before* the mail is passed on to GPGME. It is a normal edit
> operation that defines the mail to be sent. But the recipient needs to
> perform a matching series of modifications/conversions before it can
> verify the signature.
> 
> RFC 3156 says:
> 
>       In most cases, trailing whitespace can either be removed, or
>       protected by applying an appropriate content-transfer-encoding.
> 
> Note the "either, or".

Sylpheed is using the former method to avoid the trailing-space problem.

> And:
> 
>       Implementor's note: It cannot be stressed enough that
> applications using this standard follow MIME's suggestion that you "be
>       conservative in what you generate, and liberal in what you
>       accept."
> 
> With regard to "-- ", the way to go would be QP, so the space
> character is preserved. The recipient's MUA, however, must not strip
> this character either, but decode it and accept it.
> 
> > 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).
> 
> If just the whitespace in "-- " is preserved, does that also corrupt
> the mail then? Then that still is a case where Sylpheed, by default,
> should not try to work around bugs in the recipient's MUA.

Just preserving "-- " with 7bit CTE will not corrupt the mail on
recipient, but then it doesn't follow RFC 3156 (and it might be modified
along the way).

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