139 lines
4.8 KiB
Plaintext
139 lines
4.8 KiB
Plaintext
MBOX-Line: From imap at maclean.com Wed Aug 22 07:44:30 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
|
|
Message-ID: <mailman.9.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
|
|
|
|
|