X Tutup
The Wayback Machine - https://web.archive.org/web/20241214183138/https://github.com/python/cpython/issues/44196
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

mail message parsing glitch #44196

Open
mcspang mannequin opened this issue Nov 5, 2006 · 4 comments
Open

mail message parsing glitch #44196

mcspang mannequin opened this issue Nov 5, 2006 · 4 comments
Labels
stdlib Python modules in the Lib dir topic-email type-bug An unexpected behavior, bug, or error

Comments

@mcspang
Copy link
Mannequin

mcspang mannequin commented Nov 5, 2006

BPO 1590744
Nosy @warsaw, @bitdancer, @akheron
Dependencies
  • bpo-14731: Enhance Policy framework in preparation for adding email6 policies as provisional
    		•
    Files
  • mbox: mailbox
  • preserve_leading_whitespace.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = None
created_at = <Date 2006-11-05.09:21:04.000>
labels = ['type-bug', 'expert-email']
title = 'mail message parsing glitch'
updated_at = <Date 2012-06-18.08:03:55.567>
user = 'https://bugs.python.org/mcspang'

    bugs.python.org fields:

    activity = <Date 2012-06-18.08:03:55.567>
actor = 'petri.lehtinen'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['email']
creation = <Date 2006-11-05.09:21:04.000>
creator = 'mcspang'
dependencies = ['14731']
files = ['2204', '21370']
hgrepos = []
issue_num = 1590744
keywords = ['patch']
message_count = 4.0
messages = ['30445', '30446', '131976', '161476']
nosy_count = 4.0
nosy_names = ['barry', 'mcspang', 'r.david.murray', 'petri.lehtinen']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1590744'
versions = ['Python 3.3']
    @mcspang
    Copy link
    Mannequin Author

    mcspang mannequin commented Nov 5, 2006

    There's something wrong with the handling of line
    continuation in headers.

    In the attached mbox the 'Message-id' header is read
    and stored with a leading space. So message_id = '
    <9B09D75DF5B3494BA06E6FE478CE9CC10526CFAF@mgtserver3.ontario.int.ec.gc.ca>'
    when it's first read.

    If you write this message out to a new mbox, it is
    written with the leading space and without the newline.

    THEN, if you read it in AGAIN, the parser ignores the
    leading space.

    One of these steps is buggy, I'm not sure which. It
    seems to me that the value returned by
    msg['Message_id'] should not change when the file is
    written then re-read. In the initial read and final
    reads above the value differs by a space.

    @mcspang mcspang mannequin assigned warsaw Nov 5, 2006
    @mcspang mcspang mannequin added the stdlib Python modules in the Lib dir label Nov 5, 2006
    @mcspang mcspang mannequin assigned warsaw Nov 5, 2006
    @mcspang mcspang mannequin added the stdlib Python modules in the Lib dir label Nov 5, 2006
    @warsaw
    Copy link
    Member

    warsaw commented Mar 12, 2007

    This makes some sense, although it may not be ideal. The "leading space" is really an RFC 2822 continuation line, so that whitespace at the start of the second line is folding whitespace. Technically those two lines should (and do) get collapsed.

    The question is whether this message should be printed idempotently. In general the email package tries hard to maintain this principle, so I think it's probably a valid bug. However, it doesn't affect the semantics of the message so it's not a high priority fix.

    @devdanzin devdanzin mannequin added type-bug An unexpected behavior, bug, or error labels Mar 30, 2009
    @warsaw warsaw assigned bitdancer and unassigned warsaw May 5, 2010
    @bitdancer
    Copy link
    Member

    I needed an airplane-trip-sized problem to work on on the way back from PyCon and the sprints, so I tried my hand at "fixing" this. The attached patch is really just a proof of concept. Because it is so invasive of the email package machinery I doubt that I will apply it, but it does serve to prove that it is quite practical, given the right design, to preserve the leading whitespace in message headers, and this does enable the email package to read and write the messages in the sample mbox without changing them. I will incorporate what I learned from this exercise into the header management in email6.

    On the other hand, if anyone else thinks this *is* worth tidying up an applying I could be convinced.

    Note that after this patch one test fails, but that test failure is actually a buggy test that hides a bug in the header formatter (a failure to provide folding white space at the start of a continuation line). That bug I may revisit.

    @bitdancer
    Copy link
    Member

    I think I can actually fix this once the patch in bpo-14731 is applied.

    @bitdancer bitdancer added topic-email and removed stdlib Python modules in the Lib dir labels May 24, 2012
    @bitdancer bitdancer removed their assignment May 24, 2012
    @bitdancer bitdancer added topic-email and removed stdlib Python modules in the Lib dir labels May 24, 2012
    @bitdancer bitdancer removed their assignment May 24, 2012
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @iritkatriel iritkatriel added the stdlib Python modules in the Lib dir label Nov 23, 2023
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    stdlib Python modules in the Lib dir topic-email type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @warsaw @bitdancer @iritkatriel
    X Tutup