[issue32298] Email.quopriprime over-encodes characters
Geoff Kuenning <ge...@cs.hmc.edu> 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 can't deliver. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32298] Email.quopriprime over-encodes characters
Geoff Kuenning <ge...@cs.hmc.edu> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue32298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32298] Email.quopriprime over-encodes characters
New submission from Geoff Kuenning <ge...@cs.hmc.edu>:
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 characters need to
be omitted: the space and the equals sign. The following revision to the loop
creates a correct table:
for c in list(range(33, 61)) + list(range(62, 127)):
_QUOPRI_HEADER_MAP[c] = chr(c)
Why does this matter? Well, first, it's wasteful since it creates messages
with larger headers than necessary. But more important, it makes it impossible
for other tools to operate on the messages unless they're encoding aware; for
example, one can't easily grep for "f...@bar.com" because the at sign is
encoded as =40.
--
components: Library (Lib)
messages: 308181
nosy: gkuenning
priority: normal
severity: normal
status: open
title: Email.quopriprime over-encodes characters
type: behavior
versions: Python 3.4
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31864] datetime violates Postel's law
Geoff Kuenning <ge...@cs.hmc.edu> added the comment: Duh, my mistake. The problem is in dateutil, which AFAICT is indeed not part of the Python standard library. I'll hang my head in shame and go report the problem in the right place. -- resolution: third party -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31864] datetime violates Postel's law
Change by Geoff Kuenning <ge...@cs.hmc.edu>: -- components: +Library (Lib) type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31864] datetime violates Postel's law
New submission from Geoff Kuenning <ge...@cs.hmc.edu>:
The datetime package is too eager to reject nonconforming VCALENDAR-format
files. The particular issue I encountered is related to time zones. RFC 5545
clearly states that the DTSTART field is required. However, there are
situations where DTSTART isn't strictly necessary because the zone in question
doesn't observe daylight-savings time and never has.
For example, I have a VCALENDAR file that was generated by a program that omits
DTSTART for such zones. Here's an example:
BEGIN:VTIMEZONE
TZID:America/Phoenix
X-LIC-LOCATION:America/Phoenix
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:STANDARD
END:VTIMEZONE
Clearly, this file violates RFC 5445, and I have reported that fact to the
program's maintainer (who will fix the problem soon). Nevertheless, feeding an
ICS file to datetime._parse_rfc with this error causes a ValueError exception,
which makes the VCALENDAR file unreadable.
In keeping with Postel's law ("Be conservative in what you do, be liberal in
what you accept from others"), _parse_rfc should attempt to accept VCALENDAR
files whenever it is possible to make sense of them. Thus, for example:
if not founddtstart:
rrulelines.append('DTSTART:19000101T02')
The above could be improved a bit, for example by still rejecting entries in
which the standard and daylight sections had different offsets (although even
then it seems valid to assume a DTSTART in the distant past).
Although the dtstart issue is the one that prompted this report, I also noticed
the following in _parse_rfc:
if name == "BEGIN":
if value in ("STANDARD", "DAYLIGHT"):
# Process component
pass
else:
raise ValueError("unknown component: "+value)
Again, there's an opportunity to be more robust here. One could issue a
warning message, but then ignore the unknown component.
In both cases (and I suspect numerous others), halting parsing is an extreme
response to various errors, since it leaves the user of the package with no way
to process a nonconforming file. That's especially problematic since VCALENDAR
files are generated by so many different programs, many of which are written by
programmers who haven't bothered to read RFC 5445--or who have read it but then
made some minor mistake that produces broken files.
--
messages: 304944
nosy: gkuenning
priority: normal
severity: normal
status: open
title: datetime violates Postel's law
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31864>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
