Re: Query: Patches break with Microsoft exchange server.

Re: Query: Patches break with Microsoft exchange server.

[Felipe Contreras]

On Mon, Aug 9, 2010 at 9:07 AM, viresh kumar <viresh.kumar@st.com> wrote:
> Mail server in ST has recently changed and now we have Microsoft
> exchange server. We are using thunderbird as mail client.
> What we observed with this server is that patch are broken now while
> sending as well as receiving. Tabs are replaced by spaces and may
> be some other too which we haven't observed.
>
> Has anybody found a solution to this kind of issues? Are there any
> workarounds possible?

Same in Nokia. I wrote a script to fix exchange's crap, but I also
noticed some quoted-printable mails didn't get converted, so the
easiest would be to tell git to always send quoted-printable.

git folks: any chance of getting that feature to git send-email?

-- 
Felipe Contreras

Re: Query: Patches break with Microsoft exchange server.

[viresh kumar]

On 8/11/2010 3:34 AM, Felipe Contreras wrote:
> On Mon, Aug 9, 2010 at 9:07 AM, viresh kumar <viresh.kumar@st.com> wrote:
>> > Mail server in ST has recently changed and now we have Microsoft
>> > exchange server. We are using thunderbird as mail client.
>> > What we observed with this server is that patch are broken now while
>> > sending as well as receiving. Tabs are replaced by spaces and may
>> > be some other too which we haven't observed.
>> >
>> > Has anybody found a solution to this kind of issues? Are there any
>> > workarounds possible?
> Same in Nokia. I wrote a script to fix exchange's crap, but I also
> noticed some quoted-printable mails didn't get converted, so the
> easiest would be to tell git to always send quoted-printable.
> 

Hi Guys

The situation has changed now.
We are informed that SP2 is already in place in ST and mail client is not
doing any tampering.

When i send a mail using git send-email then it receives fine on
outlook but on thunderbird, tabs are converted to spaces.

This doesn't happen with every patch on thunderbird, but only a few.
And observation is that it happens only with big patches.
(more than 500 lines)

Any idea, how to solve issue now on thunderbird??

viresh.

Re: Query: Patches break with Microsoft exchange server.

[Jeffrey Hundstad]

On 08/11/2010 02:01 AM, viresh kumar wrote:
 > When i send a mail using git send-email then it receives fine on
 > outlook but on thunderbird, tabs are converted to spaces.
 >
 > This doesn't happen with every patch on thunderbird, but only a few.
 > And observation is that it happens only with big patches.
 > (more than 500 lines)
 >
 > Any idea, how to solve issue now on thunderbird??

Hello,

Exchange 2010 does not handle IMAP "chunking" (partial message transfer) 
correctly.  Any request after about 1 megabyte of total message size 
will fail.

Thunderbird uses this "chunking" feature to give you a status update 
while downloading large messages.  The IMAP statements are of this type:
11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)

When the 20480 is larger than 1MB Exchange "claims" there is no more.  
Sigh....

Fortunately you can disable this feature.  To disable this in 
Thunderbird you can go to the Advanced configuration and disable the 
following feature, by setting it to false:
mail.server.default.fetch_by_chunks


-- 
Jeffrey Hundstad

Re: Query: Patches break with Microsoft exchange server.

[David Woodhouse]

On Wed, 2010-08-11 at 10:46 -0500, Jeffrey Hundstad wrote:
> Exchange 2010 does not handle IMAP "chunking" (partial message transfer) 
> correctly.  Any request after about 1 megabyte of total message size 
> will fail.
> 
> Thunderbird uses this "chunking" feature to give you a status update 
> while downloading large messages.  The IMAP statements are of this type:
> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)
> 
> When the 20480 is larger than 1MB Exchange "claims" there is no more.  
> Sigh.... 

I think the problem is not with the fetching -- the problem is that
Exchange lies about RFC822.SIZE before the IMAP client even starts to
fetch the message. It reports a size which is smaller than the actual
size of the message, thus leading to truncated fetches.

In Evolution we have a workaround -- we don't just stop when we get to
the reported RFC822.SIZE; we continue fetching more chunks until the
server actually stops giving us any more. It's not as efficient (because
we fall back to having only one more chunk outstanding at a time rather
than the normal three in parallel), but at least it works around this
brokenness of Exchange.

http://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: Query: Patches break with Microsoft exchange server.

[Jeffrey Hundstad]

On 08/11/2010 10:58 AM, David Woodhouse wrote:
 > On Wed, 2010-08-11 at 10:46 -0500, Jeffrey Hundstad wrote:
 >> Exchange 2010 does not handle IMAP "chunking" (partial message transfer)
 >> correctly.  Any request after about 1 megabyte of total message size
 >> will fail.
 >>
 >> Thunderbird uses this "chunking" feature to give you a status update
 >> while downloading large messages.  The IMAP statements are of this type:
 >> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)
 >>
 >> When the 20480 is larger than 1MB Exchange "claims" there is no more.
 >> Sigh....
 >
 > I think the problem is not with the fetching -- the problem is that
 > Exchange lies about RFC822.SIZE before the IMAP client even starts to
 > fetch the message. It reports a size which is smaller than the actual
 > size of the message, thus leading to truncated fetches.
 >
 > In Evolution we have a workaround -- we don't just stop when we get to
 > the reported RFC822.SIZE; we continue fetching more chunks until the
 > server actually stops giving us any more. It's not as efficient (because
 > we fall back to having only one more chunk outstanding at a time rather
 > than the normal three in parallel), but at least it works around this
 > brokenness of Exchange.
 >
 > http://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064
 >

In either case it can be used successfully by disabling 
mail.server.default.fetch_by_chunks in Thunderbird.

-- 
Jeffrey Hundstad

Re: Query: Patches break with Microsoft exchange server.

[Avery Pennarun]

On Wed, Aug 11, 2010 at 11:58 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> In Evolution we have a workaround -- we don't just stop when we get to
> the reported RFC822.SIZE; we continue fetching more chunks until the
> server actually stops giving us any more. It's not as efficient (because
> we fall back to having only one more chunk outstanding at a time rather
> than the normal three in parallel), but at least it works around this
> brokenness of Exchange.
>
> http://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064

Out of curiosity, why fall back to one chunk at a time?  It seems to
me that IMAP should be able to still support multiple outstanding
requests in that case, but you'd just get errors on the latter chunks.

It is just that there was no point optimizing the workaround case?

Have fun,

Avery

Re: Query: Patches break with Microsoft exchange server.

[David Woodhouse]

On Wed, 2010-08-11 at 12:18 -0400, Avery Pennarun wrote:
> 
> Out of curiosity, why fall back to one chunk at a time?  It seems to
> me that IMAP should be able to still support multiple outstanding
> requests in that case, but you'd just get errors on the latter chunks.
> 
> It is just that there was no point optimizing the workaround case?

There wasn't a lot of point in optimising it.

The current logic, shown in the patch I referenced, is to keep fetching
new chunks while the stream position matches the end of the previous
chunk we attempted to fetch.

To handle multiple outstanding requests, especially if they can be
satisfied out-of-order, would have been more complex because the stream
position (in the 'really_fetched' variable) wouldn't necessarily match
anything interesting. We'd have to keep more state, and the whole thing
would get a lot more intrusive.

Also, for the common case where the server isn't broken and the mail
size happens not to fall on a chunk boundary, the current implementation
results in no extra fetch requests. Doing otherwise would either mean
extra fetch requests even for this common case, or would mean even more
complexity to 'catch up' by issuing additional fetch requests as soon as
we realise the server lied about RFC822.SIZE (which is when we receive
the last chunk, and it runs over the size we expected).

It may be that there's a neat and simple way to handle all of the above,
and if so then patches would be welcome -- but personally, I just
couldn't be bothered to think too hard about it. There were more
pressing matters to attend to, like implementing QRESYNC support.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: Query: Patches break with Microsoft exchange server.

[Avery Pennarun]

On Wed, Aug 11, 2010 at 12:30 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2010-08-11 at 12:18 -0400, Avery Pennarun wrote:
>> Out of curiosity, why fall back to one chunk at a time?  It seems to
>> me that IMAP should be able to still support multiple outstanding
>> requests in that case, but you'd just get errors on the latter chunks.
>>
>> It is just that there was no point optimizing the workaround case?
>
> There wasn't a lot of point in optimising it.

Say no more :)

I code on some IMAP clients occasionally and I just wanted to make
sure I wasn't missing something important.

Thanks!

Avery

Re: Query: Patches break with Microsoft exchange server.

[viresh kumar]

 On 8/11/2010 9:16 PM, Jeffrey Hundstad wrote:
> Hello,
>
> Exchange 2010 does not handle IMAP "chunking" (partial message transfer) 
> correctly.  Any request after about 1 megabyte of total message size 
> will fail.
>
> Thunderbird uses this "chunking" feature to give you a status update 
> while downloading large messages.  The IMAP statements are of this type:
> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)
>
> When the 20480 is larger than 1MB Exchange "claims" there is no more.  
> Sigh....
>
> Fortunately you can disable this feature.  To disable this in 
> Thunderbird you can go to the Advanced configuration and disable the 
> following feature, by setting it to false:
> mail.server.default.fetch_by_chunks
Jeffrey,

I tried this but problem is still there.

viresh.