encrypted mails and quoted-printable

encrypted mails and quoted-printable

[Andreas Jaeger]

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


Composing the appended email with gpg.el under current CVS the text is
in quoted printable - but there's no need for it since all characters
are ASCII.  I even prefer iso-8859-1 and have set up the necessary
vars for it AFAIK.

Any ideas why I still get quoted-printable?

Andreas



[-- Attachment #2: Type: message/rfc822, Size: 1240 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 134 bytes --]


Is this quoted printable or not?

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2.1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #3: Type: text/plain, Size: 101 bytes --]



-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: encrypted mails and quoted-printable

[ShengHuo ZHU]

Andreas Jaeger <aj@suse.de> writes:

> Composing the appended email with gpg.el under current CVS the text is
> in quoted printable - but there's no need for it since all characters
> are ASCII.  I even prefer iso-8859-1 and have set up the necessary
> vars for it AFAIK.
> 
> Any ideas why I still get quoted-printable?

QP encoding is to avoid the article to be mangled.  Though a message
contains only ASCII, lines starting with "From " or so be mangled.

BTW, to forward a signed or encrypted mail unchanged, you'd better use
`2 C-c C-f'.

ShengHuo

Re: encrypted mails and quoted-printable

[Andreas Jaeger]

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

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Andreas Jaeger <aj@suse.de> writes:
> 
>> Composing the appended email with gpg.el under current CVS the text is
>> in quoted printable - but there's no need for it since all characters
>> are ASCII.  I even prefer iso-8859-1 and have set up the necessary
>> vars for it AFAIK.
>> 
>> Any ideas why I still get quoted-printable?
> 
> QP encoding is to avoid the article to be mangled.  Though a message
> contains only ASCII, lines starting with "From " or so be mangled.

I see - but that's rather unfortunate.  Is there no way to avoid this?
I'd rather don't use QP.

> BTW, to forward a signed or encrypted mail unchanged, you'd better use
> `2 C-c C-f'.

Will do next time, thanks,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: encrypted mails and quoted-printable

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

>> QP encoding is to avoid the article to be mangled.  Though a message
>> contains only ASCII, lines starting with "From " or so be mangled.
> 
> I see - but that's rather unfortunate.  Is there no way to avoid this?
> I'd rather don't use QP.

Then you'd be breaking the PGP/MIME specification, and the receiver
probably couldn't validate your message.

3.  Content-Transfer-Encoding restrictions

   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 [1].
   However, many existing mail gateways will detect if the next hop does
   not support MIME or 8-bit data and perform conversion to either
   Quoted-Printable or Base64.  This presents serious problems for
   multipart/signed, in particular, where the signature is invalidated
   when such an operation occurs.  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).

Re: encrypted mails and quoted-printable

[Andreas Jaeger]

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

Simon Josefsson <jas@extundo.com> writes:

> Andreas Jaeger <aj@suse.de> writes:
> 
>>> QP encoding is to avoid the article to be mangled.  Though a message
>>> contains only ASCII, lines starting with "From " or so be mangled.
>> 
>> I see - but that's rather unfortunate.  Is there no way to avoid this?
>> I'd rather don't use QP.
> 
> Then you'd be breaking the PGP/MIME specification, and the receiver
> probably couldn't validate your message.
> 
> 3.  Content-Transfer-Encoding restrictions
> 
>    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 [1].
>    However, many existing mail gateways will detect if the next hop does
>    not support MIME or 8-bit data and perform conversion to either
>    Quoted-Printable or Base64.  This presents serious problems for
>    multipart/signed, in particular, where the signature is invalidated
>    when such an operation occurs.  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).

But this means that I still can use ASCII for 7bits and do not need to
use QP for 7-bit only data.

Have a look at this email - it's signed, contains AFAIK no 8-bit data
and is still QP.  That's the problem I see.

Thanks for the explanation I now accept that I have to live with QP as
soon as my emails contain 8-bit data.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: encrypted mails and quoted-printable

[Florian Weimer]

Andreas Jaeger <aj@suse.de> writes:

> Have a look at this email - it's signed, contains AFAIK no 8-bit data
> and is still QP.  That's the problem I see.

Your message contains trailing whitespace, which has to be stripped or
encoded in order to conform to RFC 2015bis.  We don't want to strip
trailing whitespace because it would castrate the '-- ' signature
separator, too.

For the remaining cases, I don't think changing Gnus is worth the
trouble.

Re: encrypted mails and quoted-printable

[Andreas Jaeger]

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

Florian Weimer <fw@deneb.enyo.de> writes:

> Andreas Jaeger <aj@suse.de> writes:
> 
>> Have a look at this email - it's signed, contains AFAIK no 8-bit data
>> and is still QP.  That's the problem I see.
> 
> Your message contains trailing whitespace, which has to be stripped or
> encoded in order to conform to RFC 2015bis.  We don't want to strip
> trailing whitespace because it would castrate the '-- ' signature
> separator, too.

It does?  Ok, I'm defeated :-)

> For the remaining cases, I don't think changing Gnus is worth the
> trouble.

In that case I agree.

Cheers,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: encrypted mails and quoted-printable

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

>>=20
...
> But this means that I still can use ASCII for 7bits and do not need to
> use QP for 7-bit only data.
>
> Have a look at this email - it's signed, contains AFAIK no 8-bit data
> and is still QP.  That's the problem I see.

Ah, yes.  The quote prefix adds trailing SPC on empty lines, which is
not nice.  Attached patch should clean things up.

> =2D-=20

The signature delimiter has trailing whitespace, so it needs QP.  But
this patch should remove all other uses of QP in your article.

--- message.el.~6.109.~	Mon Aug  6 00:05:29 2001
+++ message.el	Mon Aug  6 00:12:58 2001
@@ -540,7 +540,7 @@
   :group 'message-insertion)
 
 (defcustom message-yank-cited-prefix ">"
-  "*Prefix inserted on cited lines of yanked messages.
+  "*Prefix inserted on cited and empty lines of yanked messages.
 Fix `message-cite-prefix-regexp' if it is set to an abnormal value.
 See also `message-yank-prefix'."
   :type 'string
@@ -2109,7 +2109,7 @@
 	  (while (< (point) (mark t))
 	    (cond
 	     ((eolp) 
-	      (insert message-yank-prefix)
+	      (insert message-yank-cited-prefix)
 	      (setq last-line nil))
 	     ((looking-at ">")
 	      (if (memq last-line '(nil spaces right-angle quoted))

Re: encrypted mails and quoted-printable

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> Ah, yes.  The quote prefix adds trailing SPC on empty lines, which is
> not nice.  Attached patch should clean things up.

I've just commited a similar change to the HEAD version of message.el.
Thanks.

Re: encrypted mails and quoted-printable

[Nuutti Kotivuori]

Andreas Jaeger wrote:
> ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> 
>> Andreas Jaeger <aj@suse.de> writes:
>> 
>>> Composing the appended email with gpg.el under current CVS the
>>> text is in quoted printable - but there's no need for it since all
>>> characters are ASCII.  I even prefer iso-8859-1 and have set up
>>> the necessary vars for it AFAIK.
>>> 
>>> Any ideas why I still get quoted-printable?
>> 
>> QP encoding is to avoid the article to be mangled.  Though a
>> message contains only ASCII, lines starting with "From " or so be
>> mangled.
> 
> I see - but that's rather unfortunate.  Is there no way to avoid
> this?  I'd rather don't use QP.

,----[ RFC2015 ]
| 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).
`----

,----[ RFC2015 ]
| Though not required, it is generally a good idea to use Quoted-
| Printable encoding in the first step (writing out the data to be
| signed in MIME canonical format) if any of the lines in the data begin
| with "From ", and encode the "F".  This will avoid an MTA inserting a
| ">" in front of the line, thus invalidating the signature!
`----

So, if the message is exactly 7-bit, the standard does not _require_
you to use quoted printable, but does recommend it.

Ofcourse, News is generally decidedly 8-bit clean and unmangling, so
one might break the standard there to be nice.

-- Naked

Re: encrypted mails and quoted-printable

[Florian Weimer]

Nuutti Kotivuori <nuutti.kotivuori@smarttrust.com> writes:

> Ofcourse, News is generally decidedly 8-bit clean and unmangling, so
> one might break the standard there to be nice.

In fact, old USEFOR drafts explicitly broke RFC 2015.  After some
discussion, we convinced the editor to remove this because RFC 2015 is
a bit fragile and it is not clear what happens if Joe User's OpenPGP
implementation suddenly encounters 8-bit characters.