| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This was reported at Red Hat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=910252
To have this fully working, users should edit the account and save
the changes (even when not done any) by clicking the OK button
in the account editor, thus the source will receive its extension
and the next start the account will be recognized and auto-updated.
|
| |
|
|
|
|
|
|
|
| |
Zarafa server with disabled SSL v2 rejects connection when
SSL v2 compatible hello is sent, thus disabled this by default.
After all, SSL v3 should be used in general these days anyway.
Use environment variable CAMEL_SSL_V2_HELLO=1 in case your server
requires the old behavior.
|
| |
|
|
|
|
|
|
| |
GTK+ uses (G_PRIORITY_HIGH_IDLE + 20) for redrawing operations, which is
actually a slightly lower priority than G_PRIORITY_HIGH_IDLE. Therefore
for our purpose, G_PRIORITY_HIGH_IDLE is sufficient.
(cherry picked from commit 820dcf6cfc43265c6376f15d983381c3087a5d20)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit b6f0db12e7b2505b08ac0683c1d0d28d4a050ef3.
The commit contains not a single comment as to why these custom priority
values are being used. The rationale needs to be documented in the code,
either at each call point or preferably at a centralized priority value
definition.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I recently added a Gmane (NNTP) account and have only a few newsgroup
subscriptions. Yet when I quit Evolution, Camel tries to synchronize
all 13,872 newsgroups which literally takes days to complete.
This adds a CAMEL_STORE_FOLDER_INFO_SUBSCRIBED flag to the request for
a folder info tree while synchronizing + expunging.
Note, CamelIMAPXStore will ignore the CAMEL_STORE_FOLDER_INFO_SUBSCRIBED
flag if its "use-subscriptions" setting is FALSE, which is what we want.
(cherry picked from commit 48b9d17d16be9f0ecb6066036cc83d08b3cca817)
|
| |
|
|
| |
(cherry picked from commit ad1b7cd145c5fa5443556c17ba6e9d701c531bb7)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial revert of the hack for bug 551788, which decreased the
TCP read/write timeout from 4 minutes to 1 minute.
This causes IMAP IDLE connections to timeout prematurely if the server
sends untagged keep-alive messages at an interval greater than 1 minute.
Dovecot's "imap_idle_notify_interval" setting defaults to 2 minutes.
Reset the TCP read/write timeout back to 4 minutes.
(cherry picked from commit 4fee41524a90b2d4bf24705261e6f47b211fb86c)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Entering a wrong password, Evolution would fail to send messages using SMTP with the following error.
Bad authentication response from server.
The log file of the mail server – Exim 4 in this case – contains the following error.
cram_md5_server authenticator failed for myhost.example.org ([10.10.10.10]) [xx.xxx.xxx.xxx]: 535 Incorrect authentication data (set_id=joey)
Looking at the code after the rewrite in
commit 68c269a66bd484768b9c1517e7dc2dd30f682485
Author: Matthew Barnes <mbarnes@redhat.com>
Date: Sat Oct 15 09:51:35 2011 -0400
smtp: Adapt to Camel's new authentication API.
present since git tag EVOLUTION_DATA_SERVER_3_3_1, accidentally changed the logic not acting correctly, when receiving a 535 authentication error response and therefore was overridden by the next code block and the variable `result` changed to `CAMEL_AUTHENTICATION_ERROR` instead of `CAMEL_AUTHENTICATION_REJECTED`, which resulted in the situation where the password was not reset and therefore the user not asked to reenter it.
Changing the logic, so the variable is not overridden successfully fixes the issue.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
For uid->len = 318320, timing the loop yields:
g_list_append(): 60+ seconds
g_list_prepend(): 0.3 seconds
(cherry picked from commit ffd4d6931fd5af8624610825dd026139a6926a38)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
For some reason we were calling camel_stream_write_string() without
passing a GError, and on failure setting a very generic error message
and losing potentially useful information about the actual error.
(cherry picked from commit 3ea35694702692ad17895e5751146127606e591d)
|
| |
|
|
| |
(cherry picked from commit 52f87cba60b4d65a3d91718c25afc66d34db7db5)
|
| |
|
|
|
|
| |
There was no error handling at all on the write-to-stream operations.
(cherry picked from commit b46171b645a7e120fc25d627d84f07bea964d17c)
|
| |
|
|
|
|
|
|
| |
The function is failable and takes a GError, yet returns void. This
is how GErrors pile up. Return a boolean and add the necessary error
checks where the function is called.
(cherry picked from commit 687ac881cf58df2e01dc509c007321f758b0c9d2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
imapx_stop_idle() returned a boolean but TRUE had an ambiguous
interpretation. It either meant the DONE command was sent or an I/O
error occurred. Define a new enum type (CamelIMAPXIdleStopResult) to
resolve the ambiguity.
Also imapx_command_idle_stop() returned a boolean but FALSE had an
ambiguous interpretation. It either meant an I/O error occurred, or
there was no available CamelIMAPXStream from which to issue the DONE
command. Resolve the ambiguity by forcing callers to explicitly pass
in a CamelIMAPXStream (and a GCancellable, while we're at it).
(cherry picked from commit 21a5722a814e91e7224978e26ce86c751f6fe017)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
These functions were never meant to be exported. The "static" keyword
seems to have been omitted by accident. Can't find any evidence of them
being called from outside camel-imapx-server.c, so just make them static.
(cherry picked from commit 8a77efaa3f94ec1a6aa4743c72e1a0b34163e8b8)
|
| |
|
|
|
|
| |
One argument per line.
(cherry picked from commit bc4f85db1f4efabe6c991fdccec00209a5b8c863)
|
| |
|
|
|
|
|
| |
Normally I throw away all disabled-with-no-explanation-why code chunks,
but in this case they all seem related, so clarify that in the code.
(cherry picked from commit 0fa4740592cf6aa06a552e4b8af724083e35f404)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
camel_provider_register() should automatically set up the module and
provider hash tables if needed instead of aborting, but the problem
is the GOnce function that sets up these hash tables also calls
camel_provider_register().
Break this cycle by moving the bulk of camel_provider_register() to a
new internal function (provider_register_internal) and calling it from
the GOnce function (provider_setup).
The public camel_provider_register() function is then simply:
g_once (&setup_once, provider_setup, NULL);
provider_register_internal (provider);
(cherry picked from commit e4160726f897de9f2e697f8df319f68c2f39d6f2)
|
| |
|
|
|
|
|
| |
Check that the IMAPX stream is non-NULL before unreferencing it during
failure cleanup.
(cherry picked from commit 19da4b91667003095871d771667fbcee0faa9959)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
