124 lines
4.4 KiB
Plaintext
124 lines
4.4 KiB
Plaintext
MBOX-Line: From tss at iki.fi Mon Aug 20 14:20:18 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:48 2018
|
|
Subject: [Imap-protocol] IMAP part numbering corner case
|
|
In-Reply-To: <alpine.BSO.2.00.1208170928570.22276@morgaine.smi.sendmail.com>
|
|
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>
|
|
Message-ID: <4E784913-605F-4401-BCE5-268E79F9F41D@iki.fi>
|
|
|
|
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
|
|
>
|
|
|
|
|