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

[tvachon]

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.

[tvachon]

patch to fix this defect

[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

[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 :-)

[tvachon]

Unittest for this defect

[exarkun]

(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.

[exarkun]

Thanks for the patch and unit test.