Re: Error severity and "unexpected BYE response"

[Greg H. <gr...@hu...>]

(Originally forgot to reply to the list, so sending there.)

Oswald Buddenhagen wrote:

> On Wed, Jan 25, 2017 at 07:09:20PM -0800, Greg Hurrell wrote:
> 
> > Additionally, any tips for how I could find out what this troubling
> > message with UID 6304 is and permanently eradicate it?
> > 
> what makes you think that the number has anything to do with uids? and
> why do you think something sent to the server would be a client-side
> uid?
> in fact, you didn't even get the right message, as the error refers to
> the command continuation request above it. you can verify that by
> setting PipelineDepth 1.
> don't try to second-guess the debug output for a protocol you clearly
> didn't learn anything about, and even more, don't act upon these guesses
> (how many messages did you delete?).

Thanks for the tip about PipelineDepth. That is helpful in making the
debug output more coherent. As for why I thought the UID might be
helpful, I'd done a bunch of searching and found this:

  https://sourceforge.net/p/isync/mailman/message/32925111/

Which led me to believe that I'd be able to find some kind of useful
identifier in the debug output, but as you point out, I don't fully
understand the protocol, and it was hard to find anything meaningful. So
I proceeded to make guesses. Obviously, I visually inspected the
candidate messages before deleting them to make sure that they weren't
anything worth preserving.

> you're looking for a message you recently sent, which is about 150k in
> size. it probably contains badly encoded binary data, maybe a null
> character. in that case, your MUA (or whatever created the message)
> would be broken.

Thanks for the lead. Using this tip, I was able to do the following:

  find . -size +145k -and -size -155k -exec file {} \;

This showed a bunch of messages claiming to be ASCII, which I verified
to be correctly encoded with:

  find . -size +145k -and -size -155k \
    -exec iconv -f ASCII -t UTF-8 {} \; > /dev/null

But there were a few suspicious ones that claimed to be "data". They
were all junky newsletters, so I deleted them locally and on the server,
and now the sync completes successfully.

There were 3 in all, all in my Gmail "All Mail" folder: 1 in "cur" and 2
in "new". Perhaps I should have deleted them one by one to isolate which
one (or ones) was (or were) at fault, but I just got rid of them all at
once.

Thanks for your help.

-Greg