New IMAP mail parsing bug

New IMAP mail parsing bug

[Michael Welsh Duggan]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

I am including the first response and header for the second response
from my nntp buffer of an attempt to call nnimap-transform-split-mail.

Partial backtrace: 

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
nil)
  1+(nil)
  (forward-char (1+ bytes))
  (while (not (eobp)) (while (not ...) (delete-region ... ...) (when
  ... ...)) (setq article (match-string 1) bytes (nnimap-get-length))
  (delete-region (line-beginning-position) (line-end-position)) (insert
\n\nX-nnimap-article: %s" article)) (forward-char (1+ bytes)) (setq
bytes (nnimap-get-length)) (delete-region (line-beginning-position)
(line-end-position)) (forward-char (1+ bytes)) (delete-region
(line-beginning-position) (line-end-position)))
  (catch (quote --cl-block-nil--) (while (not ...) (while ... ... ...)
  (setq article ... bytes ...) (delete-region ... ...) (insert ...)
  (forward-char ...) (setq bytes ...) (delete-region ... ...)
  (forward-char ...) (delete-region ... ...)))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (while
  ... ... ... ... ... ... ... ... ... ...)))
  (block nil (while (not ...) (while ... ... ...) (setq article
  ... bytes ...) (delete-region ... ...) (insert ...) (forward-char ...)
  (setq bytes ...) (delete-region ... ...) (forward-char ...)
  (delete-region ... ...)))
  (let (article bytes) (block nil (while
  ... ... ... ... ... ... ... ... ... ...)))
* nnimap-transform-split-mail()
  nnimap-split-incoming-mail()
  nnimap-request-scan(nil "exchange")
  gnus-request-scan(nil (nnimap "exchange" (nnimap-address
  "owa.sei.cmu.edu") (nnimap-stream ssl) (nnimap-inbox "INBOX")
  (nnimap-expunge-inbox t) (nnimap-split-methods nnmail-split-fancy)
  (nnir-search-engine imap)))
  gnus-get-unread-articles(nil)
  gnus-setup-news(nil nil nil)

The nil comes from second nnimap-get-length call.  The first one returns
2272 as expected, but the forward char only skips to the line containing
the "BODY[1] NIL)" bit.  I expect that the NIL is the problem.  The
attached file may or may not be missing the carriage returns at the end
of each line.


[-- Attachment #2: badmail.txt --]
[-- Type: application/octet-stream, Size: 2371 bytes --]

* 1 FETCH (UID 23062 BODY[HEADER] {2272}
MIME-Version: 1.0
Received: from yoda.sei.cmu.edu (192.58.107.18) by owa.sei.cmu.edu
 (10.64.28.20) with Microsoft SMTP Server id 8.3.106.1; Mon, 11 Oct 2010
 08:35:58 -0400
Received: from mx1.andrew.cmu.edu (MX1.ANDREW.CMU.EDU [128.2.11.35])	by
 yoda.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id o9BCZwob016837	for
 <mwd@sei.cmu.edu>; Mon, 11 Oct 2010 08:35:58 -0400
Received: from bprjfh.broadband.ntl.com
 (spr1-oldh5-3-0-cust232.bagu.broadband.ntl.com [81.102.104.233] (may be
 forged))	by mx1.andrew.cmu.edu (8.14.3/8.14.3) with SMTP id o9BCZoNC029581
	for <gc00@andrew.cmu.edu>; Mon, 11 Oct 2010 08:35:51 -0400
From: Dunnam Cindrich <beaconing@fakeclub.net>
To: Scheuerman Delena <gc00@andrew.cmu.edu>
Date: Mon, 11 Oct 2010 07:35:26 -0400
Subject: rgh,' says he, just reading to h
Thread-Topic: rgh,' says he, just reading to h
Thread-Index: ActpQNttacgU2QpwRK+eTUkQJIaNKQ==
Message-ID: <S4yj1J98qPwrO54141408iJKHUZ5lY2IVyF@fakeclub.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: vader.sei.cmu.edu
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: 6
X-MS-Exchange-Organization-PCL: 2
X-MS-TNEF-Correlator:
x-spam-status: No, hits=0.37 required=5
 tests=MAY_BE_FORGED,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_MED,T_MIME_NO_TEXT
 checker=SpamAssassin version=3.003001
x-scanned-by: MIMEDefang 2.60 on 128.2.11.35
x-spam-score: 99%
x-greylist: delayed for 01:00:25
x-pmx-version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data:
 2010.10.11.122415
x-spam-warning: 99% ( KNOWN_SPAM_PNGSIG 8, IMGONLY_EMPTY_BODY 3,
 RDNS_SUSP_IMGONLY_EB 2.5, EMPTY_BODY 0.1, EMPTY_BODY_NOT_EMPTY 0.1,
 MIME_IMGONLY_MPMIXED 0.05, BODY_SIZE_10000_PLUS 0, PNG_PIXPERBYTE_MED 0,
 RDNS_BROADBAND 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_SPECIFIC 0,
 __BAT_BOUNDARY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
 __CTYPE_MULTIPART_MIXED 0, __HAS_MSGID 0, __MIME_VERSION 0, __PNG_HEIGHT_100
 0, __PNG_WIDTH_100 0, __RDNS_BROADBAND_2 0, __RDNS_POOLED_3 0,
 __RUS_MIME_NO_TEXT 0, __SANE_MSGID 0, __TO_MALFORMED_2 0)
x-dkim-verification: none
Content-Type: multipart/mixed;
	boundary="_002_S4yj1J98qPwrO54141408iJKHUZ5lY2IVyFfakeclubnet_"

 BODY[1] NIL)
* 2 FETCH (UID 23063 BODY[HEADER] {2794}

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]


--
Michael Welsh 
(md5i@md5i.com)

Re: New IMAP mail parsing bug

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> The nil comes from second nnimap-get-length call.  The first one returns
> 2272 as expected, but the forward char only skips to the line containing
> the "BODY[1] NIL)" bit.  I expect that the NIL is the problem.  The
> attached file may or may not be missing the carriage returns at the end
> of each line.

I think the problem is that the message has no body.  I'm not able to
test this myself, but I think the fix I just checked in might fix the
problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New IMAP mail parsing bug

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> The nil comes from second nnimap-get-length call.  The first one returns
>> 2272 as expected, but the forward char only skips to the line containing
>> the "BODY[1] NIL)" bit.  I expect that the NIL is the problem.  The
>> attached file may or may not be missing the carriage returns at the end
>> of each line.
>
> I think the problem is that the message has no body.  I'm not able to
> test this myself, but I think the fix I just checked in might fix the
> problem.

Seems to have worked.  I'm not quite sure.  The first time I ran it,
there was an error, but I didn't have debug-on-error set.  The second
time, no error.  I'll keep an eye on it in the future. 

-- 
Michael Welsh Duggan
(md5i@md5i.com)