Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1978 defect closed fixed (fixed)

fetch [message number] body[1] processed incorrectly for non-multipart messages

Reported by: tvachon Owned by:
Priority: high Milestone:
Component: mail Keywords: imap4
Cc: Branch:
Author: Launchpad Bug:

Description

According to rfc 2060, a command like

000001 FETCH 1 BODY[1]

should be legal for non-multipart messages, since

Every message has at least one part number.
Non-[MIME-IMB] messages, and non-multipart
[MIME-IMB] messages with no encapsulated message,
only have a part 1.

Currently, Twisted responds to this command by calling IMessagePart.getSubPart (twisted/imap4.py:1726):

def spew_body(self, part, id, msg, _w=None, _f=None):
    if _w is None:
        _w = self.transport.write
    for p in part.part:
        msg = msg.getSubPart(p)
    if part.header:
...

but according to the twisted.mail.imap4.IMessagePart interface, IMessage.getSubPart should raise a TypeError for non-multipart messages.

The fix is to replace

    def spew_body(self, part, id, msg, _w=None, _f=None):
        if _w is None:
            _w = self.transport.write
        for p in part.part:
            msg = msg.getSubPart(p)
        if part.header:
...

with

    def spew_body(self, part, id, msg, _w=None, _f=None):
        if _w is None:
            _w = self.transport.write
        for p in part.part:
            if msg.isMultipart():
                msg = msg.getSubPart(p)
            else:
                if p > 0:
                    raise TypeError, "Requested subpart of non-multipart message"

        if part.header:
...

This will raise a type error for the non-sensical query

00001 FETCH 1 BODY[2]

on a non-multipart message, but will make

00001 FETCH 1 BODY[1]

conform to the standard to non-multipart messages.

I have only seen this issue using Pine, but since it breaks compatibility with Pine I have marked this as High priority.

Attachments (2)

ticket1978fix_against20060731svn.diff (625 bytes) - added by tvachon 8 years ago.
patch to fix this defect
ticket1978_unittest.diff (1.4 KB) - added by tvachon 8 years ago.
Unittest for this defect

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by tvachon

patch to fix this defect

comment:1 Changed 8 years ago by tvachon

This and ticket #1977 are my first bug submissions to Twisted. I expect that just submission of these patches is not enough to get them included, and would be more than happy to follow up with whatever steps are needed to move the inclusion process along.

Thanks,

Travis Vachon

comment:2 Changed 8 years ago by tvachon

I've been alerted to the fact that the latest IMAP rfc is 3501 (blame Google for leading me astray). This bug holds true for that rfc as well, and I apologize for the faux pas :-)

Changed 8 years ago by tvachon

Unittest for this defect

comment:3 Changed 8 years ago by exarkun

  • Resolution set to fixed
  • Status changed from new to closed

(In [17873]) Apply tvachon's non-multipart message handling patch

Author: tvachon
Reviewer: exarkun
Fixes #1978

IMAP4 allows individual parts of multipart/* messages to be retrieved. Messages which have
a major type other than multipart have a single implicit part. Previously the IMAP4 server
would attempt to retrieve the first part from the application-level message object when this
implicit part was requested. This should always have resulted in an error, since the message
interface specifies that it should. Now the IMAP4 server detects this condition and handles it
properly without involving the application-level message object. The ultimate result is that
requesting the first part of a single part message is now handled properly.

comment:4 Changed 8 years ago by exarkun

Thanks for the patch and unit test.

comment:5 Changed 4 years ago by <automation>

  • Owner exarkun deleted
Note: See TracTickets for help on using tickets.