Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <290346684.1219663184316.JavaMail.jira@brutus>
Date: Mon, 25 Aug 2008 04:19:44 -0700 (PDT)
From: "Rick McGuire (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Assigned: (GERONIMO-4260) Multipart message from POP3 has
 spurious attachment
In-Reply-To: <250268574.1219404764321.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/GERONIMO-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick McGuire reassigned GERONIMO-4260:
--------------------------------------

    Assignee: Rick McGuire

> Multipart message from POP3 has spurious attachment
> ---------------------------------------------------
>
>                 Key: GERONIMO-4260
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-4260
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: mail
>         Environment: geronimo-javamail_1.4_mail-1.4.jar
> IBM JRE 6 SR 1
> Windows XP
>            Reporter: Dave Rushall
>            Assignee: Rick McGuire
>            Priority: Minor
>
> A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
> RETR 1
> +OK 1076 octets
> Received: ***********************************************************
> 	by *****************************************************************************
> 	for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
> Date: Fri, 22 Aug 2008 12:17:00 +0100
> Message-Id: <200808221117.m7MBGxhc1310736@*************************>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
> Subject: Test message
> To: *********************************
> From: ***********************
> Status:  O
> --0_070831_1751148640_104597052_1219403816453
> Content-Type: text/html;
>    charset="UTF-8"
> Content-Transfer-Encoding: base64
> PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
> ZHk+PC9odG1sPg==
> --0_070831_1751148640_104597052_1219403816453
> Content-Location: attachment1.txt
> Content-Disposition: attachment;
>    filename="attachment1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
> QXR0YWNobWVudCAx
> --0_070831_1751148640_104597052_1219403816453--
> .
> (Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.