MBOX-Line: From imap at maclean.com  Wed Aug 22 07:41:37 2012
To: imap-protocol@u.washington.edu
From: Pete Maclean <imap@maclean.com>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] IMAP part numbering corner case
In-Reply-To: <4E784913-605F-4401-BCE5-268E79F9F41D@iki.fi>
References: <502DBEA4.2070204@verizon.net>
	<alpine.BSO.2.00.1208162109520.13998@morgaine.smi.sendmail.com>
	<060A31A9-066E-43F0-97AF-4B68522832B1@iki.fi>
	<alpine.BSO.2.00.1208162143500.13998@morgaine.smi.sendmail.com>
	<F673FF00-66E4-4C44-8E3D-5914E92F5083@iki.fi>
	<alpine.BSO.2.00.1208162213560.13998@morgaine.smi.sendmail.com>
	<16C2B175-8815-42C5-B4BF-621EE86B8050@iki.fi>
	<alpine.BSO.2.00.1208170928570.22276@morgaine.smi.sendmail.com>
	<4E784913-605F-4401-BCE5-268E79F9F41D@iki.fi>
Message-ID: <mailman.8.1528486488.22076.imap-protocol@mailman13.u.washington.edu>

In a communication on this mailing list of 24-Jan-2011, Mark Crispin 
wrote:  "For all body parts that are not children of a MULTIPART, the 
'MIME' specifier returns the empty string (not NIL)."  At the time, I 
fixed my server to comply with this.  I think it would be no bad 
thing if "MIME" meant get the MIME headers (and only MIME headers) 
for any old part but that seems clearly not the intention (and not 
the way that most servers have it implemented) so I am inclined to 
stick with this rule.

Pete Maclean

At 05:20 PM 8/20/2012, Timo Sirainen wrote:
>I think this is somewhat ambiguous.. Servers probably should do what 
>you suggest (I changed mine to do it it again, only a few days of 
>not doing it), but then again clients shouldn't rely on it, since 
>some servers are known not to allow it (UW-IMAP at least).
>
>Somewhat related to this, I've been wondering about adding optional 
>levels of testing to imaptest, where by default it tests only how 
>all the servers should really behave, and with more options it could 
>test some more strict features that maybe aren't really so relevant 
>anymore (e.g. substring searches).
>
>On 18.8.2012, at 3.13, Philip Guenther wrote:
>
> > On Fri, 17 Aug 2012, Timo Sirainen wrote:
> >> On 17.8.2012, at 8.16, Philip Guenther wrote:
> >>> On Fri, 17 Aug 2012, Timo Sirainen wrote:
> >>> ...
> >>>> Anyway, [1.MIME] isn't a valid request in Joshua's test mail.
> >>>
> >>> Chapter and verse, please?
> >>>
> >>> (There are specific restrictions on when HEADER and TEXT are valid,
> >>> but no such restrictions are specified for the MIME part specifier...)
> >>
> >> Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME]
> >> refers to the part's MIME headers, and if the parent isn't a multipart,
> >> there are no MIME headers, so the proper result is empty.
> >
> > Well, RFC 3501 says:
> >         The MIME part specifier refers to the [MIME-IMB] header for
> >         this part.
> >
> > [MIME-IMB] is a reference to RFC 2045.  That RFC doesn't define "header"
> > itself, but does describe headers on not just body parts but entities:
> >
> > 2.4.  Entity
> > ...
> >   <...>  Any sort of field may be present in the header of an entity,
> >   but only those fields whose names begin with "content-" actually have
> >   any MIME-related meaning.  Note that this does NOT imply thay they
> >   have no meaning at all -- an entity that is also a message has non-
> >   MIME header fields whose meanings are defined by RFC 822.
> >
> > That implies to me that "header" doesn't necessarily mean "header on body
> > part".
> >
> > Also, RFC 3501 refers to [MIME-IMB] header fields in the description of
> > the BODYSTRUCTURE fetch item, wherein message/rfc822 parts do have their
> > header parsed to fill in the various fields.
> >
> >
> > So, I would argue that RFC 3501 does specify that .MIME work on all parts
> > and, in the particular case of message/rfc822 part, is equivalent to
> > asking for HEADER one level higher.
> >
> >
> > Philip Guenther
> >
> >
> > (In case that last "one level higher" doesn't make sense, here's a longer
> > example:
> >
> > ------------------------------------------------------
> > Date: Fri, 01 Jan 2010 12:00 -0500
> > To: x@x.x
> > From: y@y.y
> > Subject: download on demand problem
> > MIME-Version: 1.0
> > Content-Type: message/rfc822
> >
> > Date: Fri, 01 Jan 2012 12:00 -0500
> > To: y@y.y
> > From: x@x.x
> > Subject: Blast from the future
> > MIME-Version:1.0
> > Content-Type: multipart/mixed; boundary=foo
> >
> > --foo
> >
> > Do you know what to do when you see this message?
> >
> > --foo
> > Content-Type: text/html
> >
> > <HTML><BODY>Blah blah blah</BODY></HTML>
> > --foo
> > Content-Type: multipart/digest; boundary=bar
> >
> > --bar
> >
> > Subject: blah
> > Foo: bar
> >
> > sdlfkj
> > sdlfkj
> > sdlfkj
> >
> > --bar--
> >
> > --foo--
> > ------------------------------------------------------
> >
> > In that, [1.3.1] is the digest message, starting at the "Subject: blah"
> > line and continuing through the three "sdlfkj" lines.  [1.3.1.1] is just
> > the three "sdlfkj" lines.  [1.3.1.1.MIME] is the same as [1.3.1.HEADER],
> > which is the header of the digest message, being "Subject: blah", "Foo:
> > bar", and the blank line after.)
> > _______________________________________________
> > Imap-protocol mailing list
> > Imap-protocol@u.washington.edu
> > http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
> >
>
>_______________________________________________
>Imap-protocol mailing list
>Imap-protocol@u.washington.edu
>http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol


