From 52870a0a5c9c433d08cd27d36ca8fd776f9319ed Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <ossi@users.sf.net>
Date: Sat, 5 Aug 2017 19:52:52 +0200
Subject: [PATCH] *** workaround exchange being unhapply about messages with
 binary content

*** this is is an *untested* rebase; originally submitted against 1.3

Those where bogus messages with the raw attachment in binary but with
base 64 headers correctly set.
Near 100% (if not 100%) of those where in the sent folder and are
probably the result of gmail + buggy email client (but you can still
open the attachment with gmail !)

this is a possible fix for https://sourceforge.net/p/isync/bugs/22/ and
a lot of related reports.

patch by Florian Lombard <f.lombard@montmirail.com>:

============

the treatment should be the same as for messages with excesively long
lines - MIME-encoding (presumably as quoted-printable).
---
 src/config.c       |  2 ++
 src/drv_imap.c     |  9 ++++++++-
 src/sync.h         |  1 +
 src/sync_msg_cvt.c | 12 ++++++++++++
 4 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/config.c b/src/config.c
index 4e66cbf..fc502bf 100644
--- a/src/config.c
+++ b/src/config.c
@@ -263,6 +263,8 @@ getopt_helper( conffile_t *cfile, int *cops, channel_conf_t *conf )
 		conf->max_line_len = parse_int( cfile );
 	} else if (!strcasecmp( "CutLongLines", cfile->cmd )) {
 		conf->cut_lines = parse_bool( cfile );
+	} else if (!strcasecmp( "SkipBinaryContent", cfile->cmd )) {
+		conf->skip_binary_content = parse_bool( cfile );
 	} else if (!strcasecmp( "MaxMessages", cfile->cmd )) {
 		conf->max_messages = parse_int( cfile );
 	} else if (!strcasecmp( "ExpireSide", cfile->cmd )) {
diff --git a/src/drv_imap.c b/src/drv_imap.c
index ad95e3d..e5c3a07 100644
--- a/src/drv_imap.c
+++ b/src/drv_imap.c
@@ -1926,7 +1926,14 @@ imap_socket_read( void *aux )
 						resp = RESP_NO;
 						// Fall through - we still complain
 					} else {
-						resp = RESP_CANCEL;
+						//resp = RESP_CANCEL;
+						// Ignore BAD Error 10 (or 11) when SkipBinaryContent is not used.
+						// this doesn't seem like a terribly good idea to me - this server response
+						// indicates that the client (allegedly) did something wrong. that may mean
+						// that the subsequent command stream will be interpreted as garbage, which
+						// may have unpredictable effects. it just isn't safe to continue at this
+						// point.
+						resp = RESP_NO;
 					}
 				}
 				error( "IMAP command '%s' returned an error: %s\n",
diff --git a/src/sync.h b/src/sync.h
index a551824..2b13da2 100644
--- a/src/sync.h
+++ b/src/sync.h
@@ -62,6 +62,7 @@ typedef struct channel_conf {
 	char use_internal_date;
 	uint max_line_len;
 	char cut_lines;
+	char skip_binary_content; /* for master only */
 } channel_conf_t;
 
 typedef struct group_conf {
diff --git a/src/sync_msg_cvt.c b/src/sync_msg_cvt.c
index 5cb2938..b96ec2a 100644
--- a/src/sync_msg_cvt.c
+++ b/src/sync_msg_cvt.c
@@ -106,6 +106,18 @@ copy_msg_convert( int in_cr, int out_cr, copy_vars_t *vars )
 				leftLen -= curLineLen;
 			}
 		}
+		if (global_conf.skip_binary_content) {
+			while (idx < in_len) {
+				uchar c = in_buf[idx++];
+				if (c < 0x20 && c != '\r' && c != '\n' && c != '\t') {
+					/* binary content, skip */
+					debug( "Incorrect byte %u at offset %u/%u\n", c, idx, in_len );
+					free( in_buf );
+					return "contains raw binary";
+				}
+			}
+			idx = 0;
+		}
 		for (;;) {
 			uint start = idx;
 			uint line_cr = 0;