MBOX-Line: From brong at fastmail.fm  Wed Nov 27 17:03:44 2013
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] Strange behavior from Office 365 IMAP
In-Reply-To: <52969020.8070807@comaxis.com>
References: <52969020.8070807@comaxis.com>
Message-ID: <1385600624.4495.52958797.3CE9620E@webmail.messagingengine.com>

On Thu, Nov 28, 2013, at 11:36 AM, Jeff McKay wrote:
> I am trying to send a message to Office 365 via IMAP (using my own 
> software).  What
> I am seeing is, if the message is over a certain size (10240 bytes, to 
> be exact) the
> server will fail the APPEND command like this:
> 
> Delivered-To: BAD Command Error. 10
> 
> The server name is "outlook.office365.com".  Using SSL on port 993.
> 
> The "Delivered-To:" happens to be the first line of the message 
> (although there is
> additional text after that, it does not show up in the error message).  
> For some
> reason it thinks that the first line of data is a command, instead of 
> message text.
> If the total length of the message is less than 10240, then it works 
> just fine
> (with the exact same data, just cutoff at the end).  For example, here 
> is the
> first part of the trace, where it fails:
> 
> <send 67>A009 APPEND "Migrated/INBOX" "08-May-2013 13:38:56 -0800" {21748}
> <recv 38>+ Ready for additional command text.
> <send 21748>Delivered-To: jmckay9351@gmail.com
> Received: by 10.194.162.225 with SMTP id yd1csp6294wjb;
>          Wed, 8 May 2013 08:38:58 -0700 (PDT)
> 
> 
> (the <send> and <recv> strings are not part of the data, just info from 
> the trace).
> 
> Here is a trace where it works:
> 
> <send 67>A009 APPEND "Migrated/INBOX" "08-May-2013 13:38:56 -0800" {8000}
> <recv 38>+ Ready for additional command text.
> <send 8000>Delivered-To: jmckay9351@gmail.com
> Received: by 10.194.162.225 with SMTP id yd1csp6294wjb;
>          Wed, 8 May 2013 08:38:58 -0700 (PDT)
> 
> 
> In this case, I have arbitrarily cut off the data at 8000 bytes. The 
> APPEND command works
> fine. By the way, this exact same code/data works fine with every other 
> IMAP server I have
> tried.  Any ideas?

I would be interested in seeing the END of the larger message.  It's almost
certainly a bug in office365's IMAP implementation of course.

Of particular interest is whether it's a security hole ;)

Other fun things to check - does it only happen over SSL?

What if you send smaller blobs and flush them, rather than streaming all 20k bytes at once?

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

