*** this is is an *untested* rebase; originally submitted against 1.3.
*** wip/unchecked-remove contains an alternative approach.
patch by Florian Lombard <f.lombard@montmirail.com>
============
> 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).
Well, when you are sure about your settings, this can be usefull, as my
users where renaming folders while I was working on the sync.
At start I was logging to the mailbox, deleted the folder, and syncing
again.
*** this is is an *untested* rebase; originally submitted against 1.3
patch by Florian Lombard <f.lombard@montmirail.com>:
============
> 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?
Well, "exchange online", that sums it all ...
Tied to specific messages, I guess it happened when there was a word
between bracket in the message subject (no debug log of that).
Happends only one time, when the message is synced.
*** 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).
*** this is is an *untested* rebase; originally submitted against 1.3.
*** options are not properly scope-dependent.
*** long lines cutting when there's CR/LF conversion is unsupported
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)
100% of those messages where having bad html code without line breaks.
Non binary attachments where always correctly line wrapped.
It was either poorly done html signatures or even javascript (yeah,
inside an email !)
So I wasn't worried about the integrity of those messages, which where
already breaking the rules, but I needed the contents (messages from
customers we needed to keep)
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>:
============
my response:
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).
remove items:
- the "Unidentified socket error" should be gone since 7ba7be111
- imap_commit_cmds() is implemented since cfaa4848d
- we will never use MULTIAPPEND and FETCH BODY with multiple messages,
as that would significantly complicate matters for no tangible benefit
... and add some new thoughts.
the idea to use strings of colons for quoting patterns doesn't work, as
colons in "regular" patterns could not be quoted.
that is, Path not ending with a slash.
pedantically, this is a bugfix, as the manual already suggested that
this is possible (and at least one user got the hint, though he was
disappointed).
the IMAP driver already supports this.
it was never documented, and i can't really think of a case where
someone would actually want it, as the MUA side of things would be just
weird. additionally, the case of Path being Inbox+'/' did not work
anyway. will reconsider and fix the latter case if someone complains.
reverts 98bd2b11.
there is no need to call maildir_list_{path,inbox}() from
maildir_list_recurse(), as maildir_list_store() will do that anyway -
if it's actually requested, that is. this means that this removes the
implicit listing when Inbox is nested into Path, or vice versa. this is
actually correct, as the Patterns matching would throw away the non-
requested boxes anyway.
this finally makes us compliant with IMAP4rev1. how fitting that the
meanwhile released IMAP4rev2 demoted UTF-7 to legacy status ...
based on a patch by Georgy Kibardin <georgy@kibardin.name>.
the new one isn't an exhaustive set anymore, but a delta to the default
(or previous setting). this has the advantage that new versions aren't
automatically disabled anymore as soon as mbsync learns about them if
the user has a setting they fail to adjust.
report them as errors (not warnings), let them cause a non-zero exit
code, and in the case of trashing, prevent the subsequent expunge. the
exception are messages that just disappeared below our feet.
the purpose of these checks is preventing triggering more driver calls,
while immediate followups to already completed calls should be still
made.
note that some of the checks are strictly speaking redundant, as
chaining into a next phase will return immediately anyway when the
other side isn't ready yet. but we keep them for clarity.
this is only a partial solution for reporting changes, but it's
adequate if the goal is merely triggering a bulk action, like
re-indexing the local store.
inspired by patches posted by Yuri D'Elia <wavexx@thregr.org>.
seconds are too coarse for what we intend. technically, centisecs would
be sufficient (and more honest, given that we prefer coarse timers,
which have only tick precision), but that's a somewhat untypical unit.
in the spirit of being liberal about what we accept.
this completely re-structures the header processing loop, with the nice
side effect of eliminating the gotos.
REFMAIL: 87bkyzhoov.fsf@curie.anarc.at
... instead of reporting conversion errors directly in copy_msg_convert().
this makes it easier to autotest properly.
this reverts bc15e571 in spirit, sidestepping the problem it tried to
solve instead.
don't print the status, as the user doesn't really care whether it's
NO or BAD. more importantly, "NO LOGIN failed" is a rather misleading
thing to report.
replace the "DOM-like" model with a "streaming" model, i.e., the tokens
are now immediately processed by stateful callbacks as they are found.
this avoids plenty of allocations and copies (though not of the message
contents, yet).
- short literals are now printed even with only -Dn.
this ensures that we see all parts of, for example, LIST responses.
we use xprintf() for that, so we don't mess up the -Dn output in case
the literal contains something unexpected (we don't care with -DN).
- omitted bytes are now indicated.
- missing trailing newlines are now "pretty-printed".
- long literals are now printed in chunks as we receive them. this
makes the output messier, but it's necessary for an upcoming change,
and, on the upside, we'll get better indication when the transfer
gets stuck in the middle of a message.
this introduces a "commit" callback to the xprintf kernel, to avoid
pointlessly assembling a temporary output string prior to printing it.
one could lift the buffer limitations by introducing a "segment"
callback instead, but that would slow down xvasprintf() due to the
higher callback rate, for no good reason.
so far we shifted down the buffered data only when we ran out of space.
however, that may cause chopping up the actual socket read, which is a
bad trade-off with avoiding a moderate-sized memmove. so try to keep
enough space for the anticipated read size.
note that this ignores the zlib path, as that always does full-size
socket reads into z_buf, and saving inflate() calls seems pointless.
Oswald Buddenhagen