This is mostly needed to fix flaky
tests/test_something.py::test_is_sending_finished
by making sure that is_sending_finished() return false
once we got an event that message was sent.
This removes the last usages of the deprecated `is_chatmail` and
no `XCHATMAIL` IMAP capability is read anymore.
UIs are not using it for a longer time anymore.
The self-reporting statistics now set `is_chatmail` field to
`true`: all transports have relay-typical metadata
`false`: at least one doesn't
`null`: we don't know
BREAKING CHANGE: `is_chatmail` is no longer a known config key.
don't use `is_chatmail` for determining whether to delete messages on the server:
whether a downloaded message may be dropped from the relay
depends on whether another device still needs it (BccSelf)
and on whether plaintext mail is allowed (ForceEncryption).
Also adds tests and docs to respective functions,
clarifying background fetching behaviour and the `ACCOUNTS_BACKGROUND_FETCH_DONE` event,
that came up in questions/discussions with UI devs lately.
mark_seen=True is the default and translates to fetching BODY
of the message. mark_seen=False translates to fetching BODY.PEEK
that is described in IETF RFC 3501 as
"An alternate form of BODY[<section>] that does not implicitly set the \Seen flag."
It is unexpected unless you know this detail of IMAP protocol already,
but this is not going to be fixed in imap_tools: <https://github.com/ikvk/imap_tools/issues/179>
"addr" is already deprecated and its default value was using "configured_addr".
We want to get rid of "configured_addr" too, but users should at least
not access it through deprecated config.
"Inconsistent key state" referred to acpeerstates table row
with different Autocrypt and verified keys.
Since v2 and introduction of key contacts it is not possible for a contact
to have inconsistent key state, so this translates to having
two contacts with the same email address but different keys.
Core no longer tracks verification, so the API has nothing left
to report and UIs should drop their checkmark and "Introduced by" code.
BREAKING CHANGE: dc_contact_is_verified() and dc_contact_get_verifier_id() are removed.
BREAKING CHANGE: the JSON-RPC Contact object loses the `isVerified` and `verifierId` fields. A bot reading `snapshot.is_verified` now gets an `AttributeError` at runtime.
BREAKING CHANGE: the Python bindings lose `Contact.is_verified()` and `Contact.get_verifier()`.
BREAKING CHANGE: DC_STR_CONTACT_VERIFIED (35) is removed, so UIs should stop registering a translation for it. A stock id core does not know is logged and otherwise ignored, so an un-updated client keeps working.
Since V2 a contact is its key, there is no address-to-key binding left to verify.
The JSONRPC and FFI APIs are unchanged and report nothing as verified.
BREAKING CHANGE: the statistics JSON sent to the self-reporting-bot on Android changes: Contacts have `encrypted` instead of `verified` and lose `transitive_chain` properties and message stats have `encrypted` instead of `verified` and `unverified_encrypted`, and securejoin invites lose `already_verified`. The collecting bot stores incoming reports verbatim but analysis will have to make sense of older and newer reports.
Headers like From and Autocrypt are now added late,
right before sending the message over SMTP.
This way we advertise the latest list of transports
and use the correct From address in the encrypted part
even for messages queued while being offline.
BCC-self recipients are also added late.
For unencrypted messages we only want to send a copy
to the sending address, but we don't know the sending address
when queueing the message.
Adding bcc-self recipients when dequeuing the message
also makes it possible to send copies to updated list of relays.
This is similar to mimefactory::Encryption,
but does not have email addresses for asymmetrically encrypted messages.
Queued messages don't need email addresses for public keys.
Addresses are only needed to render Autocrypt-Gossip headers.
this PR adds a hint about how to reset a QR code.
the API is as-is, just now, a refactoring here is also unwanted. the
jsonrpc documentation needs to improved in general, this is known, and
also not done by this PR
closes#7985
---------
Co-authored-by: adb <asieldbenitez@gmail.com>
A second background_fetch() while one is already running returned
without emitting the event, and the FFI returned 1 for it,
so a UI waiting for an event hangs dc_get_next_event().
Emit the event in any case, so waiting for it is safe.
With I/O stopped, `background_fetch()` connected only to the transport of `configured_addr`
and we now instead fan out to all transports in a controlled loop.
If a first transport finished fetching new messages
cancel all other attempts and return.
This is meant to address the problem that amzd described
where a profile with one functioning and one hanging transport,
shows the first notification, then hangs 15 seconds waiting for the hanging transport.
meanwhile a second NSE arrives and dies, and the second message is not notified
or only generically.
Also drop the quota check from this background fetch path:
its result is in-memory only, discarded when the iOS notification service exits,
and the regular scheduler fetching refreshes it every 60s anyway.
Moreover, quota errors/running full is pretty rare
since relays generally automatically stay under quota these days.
It's another round trip for each transport of each profile and simply not necessary.
Also adds previously missing online tests.
this PR introduces a better quality of image recoding, consuming max.
900k instead of 500k (average is much less). the PR roughly doubles the
number of pixels sent in an image.
the old 1280px were set 8 years ago,
data and storage has improved since then,
so it is reasonable to double the number if pixels used for sending an
image.
this will be a quality boost for many images,
while not resulting in a doubled size for all of them; many images will
only be a little larger in bytes, see test.
we could always go higher, of course, but it comes at costs of relay
storage and data, so we stay conservative, even in that increase.
the "worse quality" setting is not adapted on purpose, there we really
stay at the end of what is bearable :)
cc @adbenitez
---------
Co-authored-by: l <link2xt@testrun.org>
Main change is the removal of the comparison of Chat-Disposition-Notification-To
to the From header for incoming messages.
Removed code that was settting WantsMdn for outgoing messages
is a leftover not cleaned up in ade39fe026
We do not actually use WantsMdn for outgoing messages.
Event string getters returned Rust-allocated pointers that dc_str_unref()
frees with libc. This breaks with custom Rust allocators, so allocate the
strings with strdup() instead.
BREAKING CHANGE: get_webxdc_blob() may fail to load icon.png or icon.jpg if image dimensions are too large.
The issue is discovered by https://github.com/Sergei768
