MBOX-Line: From tss at iki.fi  Fri Oct  7 07:39:58 2011
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] FETCH (rfc822) response
In-Reply-To: <4E8F0D21.3040004@earthlink.net>
References: <4DEBB242.2090200@BusCom.net>
	<alpine.OSX.2.00.1106051606130.4942@hsinghsing.panda.com>
	<4E3382E3.3010509@earthlink.net>
	<alpine.BSO.2.00.1107292118540.19142@morgaine.smi.sendmail.com>
	<alpine.OSX.2.00.1107292242400.911@hsinghsing.panda.com>
	<4E8F0D21.3040004@earthlink.net>
Message-ID: <1317998399.21919.63.camel@hurina>

On Fri, 2011-10-07 at 09:30 -0500, Rick Sanders wrote:
> I'm working with a server whose response to a FETCH (rfc822) is 
> different than I have seen before.
> 
>  >> 1 FETCH 1 (rfc822)
> << * 1 EXISTS
> << * 1 FETCH (RFC822[] {0}
> 
> I'm used to seeing something like * 1 FETCH (RFC822 {1522}.  In this 
> case I have to send a separate 1 FETCH 1 (rfc822.size) command to get 
> the message size:   << 1 FETCH (rfc822.size 5149).
> 
> Just curious, is this compliant?

No, the server is broken. But you could try to work around it with
fetching BODY.PEEK[] instead.




