PGP/MIME replaces lines starting with "from " with "From "

PGP/MIME replaces lines starting with "from " with "From "

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Hi.  I have noticed that Gnus replaces lines matching "^from " with
"From " when PGP/MIME is used.  This is probably due RFC 3156:

      Note: If any line begins with the string "From ", it is strongly
      suggested that either the Quoted-Printable or Base64 MIME encoding
      be applied.  If Quoted-Printable is used, at least one of the
      characters in the string should be encoded using the hexadecimal
      coding rule.  This is because many mail transfer and delivery
      agents treat "From " (the word "from" followed immediately by a
      space character) as the start of a new message and thus insert a
      right angle-bracket (>) in front of any line beginning with
      "From " to distinguish this case, invalidating the signature.

I believe this ought to be case-sensitive "^From " matches only, which
would not include "^from ".  I have tested both the Claws Mail and
Evolution MUAs, and they will QP-encode lines matching "^From " (both as
"=46rom " incidentally) but NOT escape lines matching "^from ".

I haven't been able to figure out where in Gnus (or the PGP sub-systems)
this happens, so I'm bringing it up here to see if anyone else agrees
with my interpretation and is able to fix this.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: PGP/MIME replaces lines starting with "from " with "From "

[Daiki Ueno]

Simon Josefsson <simon@josefsson.org> writes:

> I believe this ought to be case-sensitive "^From " matches only, which
> would not include "^from ".  I have tested both the Claws Mail and
> Evolution MUAs, and they will QP-encode lines matching "^From " (both as
> "=46rom " incidentally) but NOT escape lines matching "^from ".
>
> I haven't been able to figure out where in Gnus (or the PGP sub-systems)
> this happens, so I'm bringing it up here to see if anyone else agrees
> with my interpretation and is able to fix this.

It seems to be actually done in the QP-encoding phase.  I've pushed a
trivial fix:
http://git.gnus.org/cgit/gnus.git/commit/?id=6aa54ac2

Regards,
-- 
Daiki Ueno