{"thread":{"id":"24701","subject":"Re: Query: Patches break with Microsoft exchange server.","startedAt":"2010-08-10T22:04:08Z","lastAt":"2010-08-12T04:41:07Z","messageCount":9,"participants":["Felipe Contreras","viresh kumar","Jeffrey Hundstad","David Woodhouse","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147691","messageId":"AANLkTinxwRFLUibJECm0c3_oL5mYRkmscsw-xXgAHSTe@mail.gmail.com","threadId":"24701","inReplyTo":"4C5F9B25.8080401@st.com","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-08-10T22:04:08Z","receivedAt":"2010-08-10T22:04:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Aug 9, 2010 at 9:07 AM, viresh kumar wrote:\n> Mail server in ST has recently changed and now we have Microsoft\n> exchange server. We are using thunderbird as mail client.\n> What we observed with this server is that patch are broken now while\n> sending as well as receiving. Tabs are replaced by spaces and may\n> be some other too which we haven't observed.\n>\n> Has anybody found a solution to this kind of issues? Are there any\n> workarounds possible?\n\nSame in Nokia. I wrote a script to fix exchange's crap, but I also\nnoticed some quoted-printable mails didn't get converted, so the\neasiest would be to tell git to always send quoted-printable.\n\ngit folks: any chance of getting that feature to git send-email?\n\n-- \nFelipe Contreras\n"},{"id":"147722","messageId":"4C624AE1.30504@st.com","threadId":"24701","inReplyTo":"AANLkTinxwRFLUibJECm0c3_oL5mYRkmscsw-xXgAHSTe@mail.gmail.com","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"viresh kumar","fromEmail":"viresh.kumar@st.com","sentAt":"2010-08-11T07:01:53Z","receivedAt":"2010-08-11T07:01:53Z","isPatch":false,"sender":{"key":"viresh.kumar@st.com","avatar":null},"body":"On 8/11/2010 3:34 AM, Felipe Contreras wrote:\n> On Mon, Aug 9, 2010 at 9:07 AM, viresh kumar wrote:\n>> > Mail server in ST has recently changed and now we have Microsoft\n>> > exchange server. We are using thunderbird as mail client.\n>> > What we observed with this server is that patch are broken now while\n>> > sending as well as receiving. Tabs are replaced by spaces and may\n>> > be some other too which we haven't observed.\n>> >\n>> > Has anybody found a solution to this kind of issues? Are there any\n>> > workarounds possible?\n> Same in Nokia. I wrote a script to fix exchange's crap, but I also\n> noticed some quoted-printable mails didn't get converted, so the\n> easiest would be to tell git to always send quoted-printable.\n> \n\nHi Guys\n\nThe situation has changed now.\nWe are informed that SP2 is already in place in ST and mail client is not\ndoing any tampering.\n\nWhen i send a mail using git send-email then it receives fine on\noutlook but on thunderbird, tabs are converted to spaces.\n\nThis doesn't happen with every patch on thunderbird, but only a few.\nAnd observation is that it happens only with big patches.\n(more than 500 lines)\n\nAny idea, how to solve issue now on thunderbird??\n\nviresh.\n"},{"id":"147787","messageId":"4C62C5BD.3020808@mnsu.edu","threadId":"24701","inReplyTo":"4C624AE1.30504@st.com","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"Jeffrey Hundstad","fromEmail":"jeffrey.hundstad@mnsu.edu","sentAt":"2010-08-11T15:46:05Z","receivedAt":"2010-08-11T15:46:05Z","isPatch":false,"sender":{"key":"jeffrey.hundstad@mnsu.edu","avatar":null},"body":"On 08/11/2010 02:01 AM, viresh kumar wrote:\n > When i send a mail using git send-email then it receives fine on\n > outlook but on thunderbird, tabs are converted to spaces.\n >\n > This doesn't happen with every patch on thunderbird, but only a few.\n > And observation is that it happens only with big patches.\n > (more than 500 lines)\n >\n > Any idea, how to solve issue now on thunderbird??\n\nHello,\n\nExchange 2010 does not handle IMAP \"chunking\" (partial message transfer) \ncorrectly. Any request after about 1 megabyte of total message size \nwill fail.\n\nThunderbird uses this \"chunking\" feature to give you a status update \nwhile downloading large messages. The IMAP statements are of this type:\n11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)\n\nWhen the 20480 is larger than 1MB Exchange \"claims\" there is no more. \nSigh....\n\nFortunately you can disable this feature. To disable this in \nThunderbird you can go to the Advanced configuration and disable the \nfollowing feature, by setting it to false:\nmail.server.default.fetch_by_chunks\n\n\n-- \nJeffrey Hundstad\n"},{"id":"147790","messageId":"1281542305.5107.11.camel@localhost","threadId":"24701","inReplyTo":"4C62C5BD.3020808@mnsu.edu","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2010-08-11T15:58:25Z","receivedAt":"2010-08-11T15:58:25Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2010-08-11 at 10:46 -0500, Jeffrey Hundstad wrote:\n> Exchange 2010 does not handle IMAP \"chunking\" (partial message transfer) \n> correctly. Any request after about 1 megabyte of total message size \n> will fail.\n> \n> Thunderbird uses this \"chunking\" feature to give you a status update \n> while downloading large messages. The IMAP statements are of this type:\n> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)\n> \n> When the 20480 is larger than 1MB Exchange \"claims\" there is no more. \n> Sigh.... \n\nI think the problem is not with the fetching -- the problem is that\nExchange lies about RFC822.SIZE before the IMAP client even starts to\nfetch the message. It reports a size which is smaller than the actual\nsize of the message, thus leading to truncated fetches.\n\nIn Evolution we have a workaround -- we don't just stop when we get to\nthe reported RFC822.SIZE; we continue fetching more chunks until the\nserver actually stops giving us any more. It's not as efficient (because\nwe fall back to having only one more chunk outstanding at a time rather\nthan the normal three in parallel), but at least it works around this\nbrokenness of Exchange.\n\nhttp://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"147791","messageId":"4C62CCF2.5040206@mnsu.edu","threadId":"24701","inReplyTo":"1281542305.5107.11.camel@localhost","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"Jeffrey Hundstad","fromEmail":"jeffrey.hundstad@mnsu.edu","sentAt":"2010-08-11T16:16:50Z","receivedAt":"2010-08-11T16:16:50Z","isPatch":false,"sender":{"key":"jeffrey.hundstad@mnsu.edu","avatar":null},"body":"On 08/11/2010 10:58 AM, David Woodhouse wrote:\n > On Wed, 2010-08-11 at 10:46 -0500, Jeffrey Hundstad wrote:\n >> Exchange 2010 does not handle IMAP \"chunking\" (partial message transfer)\n >> correctly. Any request after about 1 megabyte of total message size\n >> will fail.\n >>\n >> Thunderbird uses this \"chunking\" feature to give you a status update\n >> while downloading large messages. The IMAP statements are of this type:\n >> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)\n >>\n >> When the 20480 is larger than 1MB Exchange \"claims\" there is no more.\n >> Sigh....\n >\n > I think the problem is not with the fetching -- the problem is that\n > Exchange lies about RFC822.SIZE before the IMAP client even starts to\n > fetch the message. It reports a size which is smaller than the actual\n > size of the message, thus leading to truncated fetches.\n >\n > In Evolution we have a workaround -- we don't just stop when we get to\n > the reported RFC822.SIZE; we continue fetching more chunks until the\n > server actually stops giving us any more. It's not as efficient (because\n > we fall back to having only one more chunk outstanding at a time rather\n > than the normal three in parallel), but at least it works around this\n > brokenness of Exchange.\n >\n > http://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064\n >\n\nIn either case it can be used successfully by disabling \nmail.server.default.fetch_by_chunks in Thunderbird.\n\n-- \nJeffrey Hundstad\n"},{"id":"147792","messageId":"AANLkTi=9xVdfXJXpkNPUMahc7AsbxjVbZFSxeBrzvbmS@mail.gmail.com","threadId":"24701","inReplyTo":"1281542305.5107.11.camel@localhost","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-08-11T16:18:02Z","receivedAt":"2010-08-11T16:18:02Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Aug 11, 2010 at 11:58 AM, David Woodhouse wrote:\n> In Evolution we have a workaround -- we don't just stop when we get to\n> the reported RFC822.SIZE; we continue fetching more chunks until the\n> server actually stops giving us any more. It's not as efficient (because\n> we fall back to having only one more chunk outstanding at a time rather\n> than the normal three in parallel), but at least it works around this\n> brokenness of Exchange.\n>\n> http://git.gnome.org/browse/evolution-data-server/commit/?id=9714c064\n\nOut of curiosity, why fall back to one chunk at a time? It seems to\nme that IMAP should be able to still support multiple outstanding\nrequests in that case, but you'd just get errors on the latter chunks.\n\nIt is just that there was no point optimizing the workaround case?\n\nHave fun,\n\nAvery\n"},{"id":"147793","messageId":"1281544234.5107.25.camel@localhost","threadId":"24701","inReplyTo":"AANLkTi=9xVdfXJXpkNPUMahc7AsbxjVbZFSxeBrzvbmS@mail.gmail.com","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2010-08-11T16:30:34Z","receivedAt":"2010-08-11T16:30:34Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2010-08-11 at 12:18 -0400, Avery Pennarun wrote:\n> \n> Out of curiosity, why fall back to one chunk at a time? It seems to\n> me that IMAP should be able to still support multiple outstanding\n> requests in that case, but you'd just get errors on the latter chunks.\n> \n> It is just that there was no point optimizing the workaround case?\n\nThere wasn't a lot of point in optimising it.\n\nThe current logic, shown in the patch I referenced, is to keep fetching\nnew chunks while the stream position matches the end of the previous\nchunk we attempted to fetch.\n\nTo handle multiple outstanding requests, especially if they can be\nsatisfied out-of-order, would have been more complex because the stream\nposition (in the 'really_fetched' variable) wouldn't necessarily match\nanything interesting. We'd have to keep more state, and the whole thing\nwould get a lot more intrusive.\n\nAlso, for the common case where the server isn't broken and the mail\nsize happens not to fall on a chunk boundary, the current implementation\nresults in no extra fetch requests. Doing otherwise would either mean\nextra fetch requests even for this common case, or would mean even more\ncomplexity to 'catch up' by issuing additional fetch requests as soon as\nwe realise the server lied about RFC822.SIZE (which is when we receive\nthe last chunk, and it runs over the size we expected).\n\nIt may be that there's a neat and simple way to handle all of the above,\nand if so then patches would be welcome -- but personally, I just\ncouldn't be bothered to think too hard about it. There were more\npressing matters to attend to, like implementing QRESYNC support.\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"147796","messageId":"AANLkTi=6hXj_a1X-HwYWvWt4_pBto_OQgkWE3VsDmEsJ@mail.gmail.com","threadId":"24701","inReplyTo":"1281544234.5107.25.camel@localhost","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-08-11T16:39:53Z","receivedAt":"2010-08-11T16:39:53Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Aug 11, 2010 at 12:30 PM, David Woodhouse wrote:\n> On Wed, 2010-08-11 at 12:18 -0400, Avery Pennarun wrote:\n>> Out of curiosity, why fall back to one chunk at a time?  It seems to\n>> me that IMAP should be able to still support multiple outstanding\n>> requests in that case, but you'd just get errors on the latter chunks.\n>>\n>> It is just that there was no point optimizing the workaround case?\n>\n> There wasn't a lot of point in optimising it.\n\nSay no more :)\n\nI code on some IMAP clients occasionally and I just wanted to make\nsure I wasn't missing something important.\n\nThanks!\n\nAvery\n"},{"id":"147866","messageId":"4C637B63.1060404@st.com","threadId":"24701","inReplyTo":"4C62C5BD.3020808@mnsu.edu","subject":"Re: Query: Patches break with Microsoft exchange server.","fromName":"viresh kumar","fromEmail":"viresh.kumar@st.com","sentAt":"2010-08-12T04:41:07Z","receivedAt":"2010-08-12T04:41:07Z","isPatch":false,"sender":{"key":"viresh.kumar@st.com","avatar":null},"body":" On 8/11/2010 9:16 PM, Jeffrey Hundstad wrote:\n> Hello,\n>\n> Exchange 2010 does not handle IMAP \"chunking\" (partial message transfer) \n> correctly. Any request after about 1 megabyte of total message size \n> will fail.\n>\n> Thunderbird uses this \"chunking\" feature to give you a status update \n> while downloading large messages. The IMAP statements are of this type:\n> 11 UID fetch 244477 (UID RFC822.SIZE BODY[]<20480.12288>)\n>\n> When the 20480 is larger than 1MB Exchange \"claims\" there is no more. \n> Sigh....\n>\n> Fortunately you can disable this feature. To disable this in \n> Thunderbird you can go to the Advanced configuration and disable the \n> following feature, by setting it to false:\n> mail.server.default.fetch_by_chunks\nJeffrey,\n\nI tried this but problem is still there.\n\nviresh.\n"}]}