"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.
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.
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.
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
This Final-Recipient was not set to the correct value anyway.
We could query the database and find out via `imap` table
which transport we have received the message on,
but it is not worth the effort as the field is not practically used
and cannot be relied on as old versions still send incorrect value.
This removes one call to get_primary_self_addr()
to make it easier to remove the concept of the "primary"
address eventually.
According to
<https://datatracker.ietf.org/doc/html/rfc8098#section-3.2.3>
Original-Recipient field values in MDNs MUST NOT be included
if the information about original recipient is not available.
Original recipient may be obtained from ORCPT parameter
of SMTP envelope or from Original-Recipient header
which MTAs are expected to convert Original-Recipient to.
The way we have been using Original-Recipient field is not correct.
Technically we should look for Original-Recipient header
on the message when downloading it from IMAP
and then copy the value into MDN,
but simply assuming it is never there is more correct
than always assuming it is the same as our current address.
I also grepped for Original-Recipient
and removed it together with Reporting-UA from the tests.
Orignal-Recipient is now only left in NDN (bounce messages) test data,
there it is correct as this field is added by MTAs
that have direct access to ORCPT parameter.
It is safe to import any keys into the keychain.
Keys can anyway be imported from vCards
and Autocrypt headers without any checks.
These checks are from the time before we had key-contacts
and maintained Autocrypt `peerstates` table.
Also marked functions that are not used outside as pub(crate).
Some functions like get_filesuffix_lc() are still used
by deltachat-repl, so the whole module cannot be made private.
Removing a relay now takes effect immediately:
- the profile stops fetching and advertising it,
- secondary devices immediately apply the removal through the transport sync,
Upgrading removes unpublished relays and triggers keyupdates.
BREAKING CHANGE: set_transport_unpublished() is removed: UIs call delete_transport() when the user removes a relay.
BREAKING CHANGE: list_transports_ex() and the TransportListEntry type are removed: use list_transports().
BREAKING CHANGE: delete_transport() no longer refuses to remove the primary transport: it refuses only to remove the last one and re-elects the sending transport as needed.
BREAKING CHANGE: TransportsModified is now also emitted on the device modifying the transports, not only on devices applying the synced change.
Deprecated: DC_STR_PHASING_OUT
`relay_addrs()` fell back to the contact address even when it is empty,
which happens for key-contacts created from a sync message or for the
self-contact, putting an empty string into the SMTP recipient list.
When the published relay list changes, key-contacts are informed with an
unsigned message carrying the re-signed key, encrypted to a chunk of contacts
at a time. It is shaped like a receipt notification naming no message, so that
cores which know nothing about keyupdates trash it as well.
See the src/keyupdate.rs module docs for the design.
An unsigned message carries no intended recipient fingerprints,
so recipients of an encrypted unsigned message
learn nothing about other recipients from the PGP packets.
No functional changes:
Add a relay_addrs helper, share the protected headers and self-key rendering
of non-chat messages, and move insert_into_smtp from securejoin to smtp.
It is not clear if old versions stored SELF avatar in parameters
or if it happened due to a bug, but if it happens,
we can safely delete the avatar.
get_profile_image_ext() is refactored to make it
not try to load avatars for any special contacts.
Closes https://github.com/chatmail/core/issues/8576.
The diff might look big, but it's only two things:
- move `can_call_me` one scope up
- replace `emit_incoming_msg` with `emit_msg_event`
with `important = can_call_me`
I decided not to completely unify the `important` logic
with the other occurrence of `emit_msg_event()`
as I suggested in the issue yet.
That IMO should still be considered, but let's start simple.
Note that there is #7840 which may be closed by #7955,
which will basically supersede this MR.
I think, however, that it's OK to merge this one,
and then that one can just revert this one, including tests,
and rebase on top of the revert.
I have an old profile which has ProfileImage param
set on the reserved SELF contact. When I deleted
an avatar from the profile, very old profile image
showed up in the settings in Delta Chat Desktop instead,
which can be "deleted" again without any result.
This fix is to return `None` early from get_profile_image_ext
for self contact without trying to load the parameter.
Fallthrough to loading params was likely there
since keycontacts and grey avatars for address contacts
introduction in 416131b4a2
.execute() was returning the number of rows, so usually 1.
.insert() is returning the row ID.
In most cases it does not matter because the result is checked with .is_empty(),
but send_msg_sync() actually uses the row IDs.
Authentication failures may happen because of internal server errors.
Device message saying "Please check if the email address and the password are correct"
was written for classic email setups when the user knows the password.
For users of chatmail relays this message is not actionable,
but still appears when relay fails to check the password.
Changes filenames used in the db backups and key exports,
preferring fingerprint over the email address.
Part of: #8572
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
this is meant to help configuration event consumers (Python, UIs)
to not hang waiting for configuration outcomes.
One test case is added that fails on main.
This did not affect actual message deletion,
because select_expired_messages already takes timestamp_rcvd
into account and does not delete system messages
that say "Messages are end-to-end encrypted" too early.
So it is a minor bug as estimate_deletion_cnt
is meant to only roughly estimate the number of messages
to be deleted. Still, there were no tests before,
so now estimate_deletion_cnt is tested.
Address inside the KML is not used anywhere,
and we are moving away from "primary" relay notation (and thus also
identifying contacts by email address).
Part of: #8572
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
chatmail relays (filtermail) expect {vc,vg}-request
messages to be multipart/mixed with a single part.
Messages had this structure
before commit e0494b0b37
so we need to keep it for compatibility.
`version_string` is meant to be displayed by UI, and comes from the
wire.
therefore, as a general precaution, ensure a string that is
regarded as a typical version string. all versions in scope are
currently v123.456.789-shortsuffix, where suffix is a-z and mostly
unused in production. that is the base. we can adapt if there is really
a need, but not for theoretical version strings. as we do not stop
processing, things are not bad even if we missed a valid usecase herr.
moreover, if `version_string` is empty, we skip the candidate - as we
cannot display something useful to the user. that little bit of care is
expected from relays :)
