On Mon, Apr 24, 2017 at 03:20:45PM +0200, Florian Lombard wrote:
> Here are the patch I worked on when having sync issues with Exchange
> (online).
>
thanks. i'm not going to apply any part of this patch verbatim, but some
parts of it are worth serious consideration, and somebody may feel
adventurous enough to use your changes as-is.
> Common cfg section:
>
> * Either skip or fix messages with lines more than xxx bytes
> (typically no more than 9900 bytes with exchange)
> MaxLineLength xxx (in bytes)
> CutLongLines yes|no (fix or skip message)
>
as mentioned before, i'm concerned about the "sledge hammer" approach of
hard-cutting the lines, because that falsifies the messages' content,
which may very well render them unreadable (if it's not plain text).
meanwhile i found that this should at least not invalidate possibly
present signatures, simply because the respective standards require
complete normalization of the contents before signing - specifically to
avoid the problem.
still, a cleaner approach would be encapsulating the message in a MIME
structure. i found in the imapsync FAQ that "reformime -r7" would do
that (i'm not suggesting to use that, but it should serve as a good
example).
i'd be interested in samples of such messages with excessively long
lines to assess what the "target audience" actually is. i would expect
that messages which already are MIME-encoded would not have this
problem. but then, a sloppily encoded multipart text+html mail could
very well be broken as well.
> * Allow to rescan all mails from a folder, ignoring the last sync
> latest message pulled (usefull when playing with my new settings)
> IgnoreMaxPulledUid yes|no
>
that seems to be overkill to me given that it's a workaround and can be
easily achieved by hacking the sync state files, for example by sed'ing
them.
i suppose you implemented this to resume syncing after implementing the
line length workaround?
> * Skip messages with raw binary content (bytes < 0x20 except CR/LF/TAB)
> SkipBinaryContent yes|no
>
i know that i suggested that this might be a problem, but i don't
remember whether you reported actual instances of that.
anyway, the treatment should be the same as for messages with excesively
long lines - MIME-encoding (presumably as quoted-printable).
> * Allow to delete non empty folders on slave (when you are sure about
> what you're doing)
> DeleteNonEmpty yes|no
>
i'll consider this.
my biggest concern is that some transient error would falsify the
mailbox list and thus cause the folders to be nuked. similary, a
permanent change in the server configuration would have that effect.
arguably, either wouldn't be so bad as such, as it would destroy only
the replica. however, it would be important to verify that the replica
does not contain any unpropagated mails (as opposed to any mails at all,
as is done currently).
> Drivers cfg section (imap only):
>
> * Suppress Keyword not supported warnings
> IgnoreKeywordWarnings yes|no
>
i wonder why a server would bleat about not supporting an optional
feature when it can (and probably does) announce that in a "civilized"
way, too. did these responses appear to be correlated with specific
messages, or did they always come when opening any mailbox?
> diff --git a/src/drv_imap.c b/src/drv_imap.c
> index e24c7d8..10da0cb 100644
> --- a/src/drv_imap.c
> +++ b/src/drv_imap.c
> @@ -1416,6 +1419,16 @@ imap_socket_read( void *aux )
> resp = RESP_NO;
> if (cmdp->param.failok)
> goto doresp;
> + } else if (!strcmp( "BAD", arg )) {
> + resp = RESP_NO;
> + warn( "Warning: IMAP command '%s' returned an
> error: %s %s\n",
> + starts_with( cmdp->cmd, -1, "LOGIN", 5
> ) ?
> + "LOGIN <user> <pass>" :
> + starts_with( cmdp->cmd, -1,
> "AUTHENTICATE PLAIN", 18 ) ?
> + "AUTHENTICATE PLAIN
> <authdata>" :
> + cmdp->cmd,
> + arg, cmd ? cmd : "" );
> + goto doresp;
> } else /*if (!strcmp( "BAD", arg ))*/
> resp = RESP_CANCEL;
>
this hunk downgrades tagged BAD responses to warnings and suppresses the
subsequent client-side connection drop.
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.
i suppose you implemented this as a workaround before you identified the
line length issue?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
