[issue32298] Email.quopriprime over-encodes characters

Geoff Kuenning added the comment: I should have read that part of RFC 2047 before I submitted. I'd love to claim that I'm going to write a patch that would do as you suggest. But the reality is that I'm unlikely to find the time, so I'm going to be wise for once and avoid promising what I ca

[issue32298] Email.quopriprime over-encodes characters

R. David Murray added the comment: And of course tools can grep for "f...@bar.com": you can't use encoded words in an address, only in the display name. However, it occurs to me that in fact the restriction applies only to phrases, so one could use a less restrictive character set in an unstr

[issue32298] Email.quopriprime over-encodes characters

R. David Murray added the comment: >From RFC 2047: (3) As a replacement for a 'word' entity within a 'phrase', for example, one that precedes an address in a From, To, or Cc header. The ABNF definition for 'phrase' from RFC 822 thus becomes: phrase = 1*( encoded-word / word )

[issue32298] Email.quopriprime over-encodes characters

Geoff Kuenning added the comment: Oops, that loop is a bit too generous. Here's a better one: for c in list(range(33, 61)) + [62] + list(range(64, 95)) + list(range(96,127)): -- ___ Python tracker _

[issue32298] Email.quopriprime over-encodes characters

New submission from Geoff Kuenning : Email.quopriprime creates a map of header and body bytes that need no encoding: for c in b'-!*+/' + ascii_letters.encode('ascii') + digits.encode('ascii'): _QUOPRI_HEADER_MAP[c] = chr(c) This map is overly restrictive; in fact only two printable characte