UIs should use display name everywhere and avoid displaying email addresses.
BREAKING CHANGE: dc_contact_get_name_n_addr() CFFI is removed
BREAKING CHANGE: JSON-RPC contact objects don't have nameAndAddr field anymore
No changes except that smtp::is_queue_empty is renamed into smtp::queue::is_empty,
mimefactory::QueuedEncryption is renamed into smtp::queue::Encryption
and mimefactory::QueueSideEffects is renamed to smtp::queue::SideEffects.
mimefactory module does not know anything about smtp2 table anymore.
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.
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.
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.
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.
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.
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.
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.
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.
This is mostly a reaction in response to
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/
I don't know when exactly
`cargo clippy` and similar commands (check, build, run etc.)
may update dependencies
and it does not look like they actively pull
the package index and update yanked crates.
We also keep the lockfile updated all the time
by checking in CI.
Still, all commands better use --locked as a precaution.
This replaces independent data structures
which allowed invalid state of having both the public keys
and the shared secret, or having a shared secret
but not encrypting the message because encryption_pubkeys
was None instead of Some(Vec::new()).
Creating QR code or sending a message will still fail
with a shorter error, but no info message will be created anymore.
Most users should have migrated the channels by recreating them by now.
This change is needed for moving loading of the shared secret
to earlier stages of message preparation,
otherwise mimefactory will have to create these info messages
when loading the message into memory.
Unencrypted messages are no longer sent as multipart/mixed
with Message-ID header duplicated inside.
This was useful as non-standard protection
against servers that rewrite the Message-ID,
but now most messages are sent encrypted
and for them standard RFC 9788 header protection
works the same way.
There is currently no place to document up to date SQL schema.
New database is initialized with src/sql/tables.sql
and then updated by migrations,
So tracking down how some column is used requires grepping the code,
looking for a migration adding it and corresponding commits.
Co-Authored-By: biørn <r10s@b44t.com>
The chat is always going to be encrypted, this is enough.
We actually do mark the contact as verified,
but the meaning of this verification is unclear
and we don't even display it visibly in the chat anymore.
This value is not used for any logic
except the disappearing messages timer rollback prevention.
It is unlikely that non-chat clients
participate in chats with disappearing messages,
and the case was not tested anyway.
This change separates rendering into two separate steps:
1. Rendering of the message payload without the From, Date and Autocrypt headers.
2. Adding the From, Date and Autocrypt headers and possibly encrypting the message.
The goal is to have serializable result of the first step
that can be persisted in the database and sent later with any email address.
This way it will be possible to send queued messages over any relay.
This will make it possible not to remove all messages from the queue
when the sending relay is changed.
Currently changing `configured_addr` deletes everything from `smtp` table.
This change is however only a refactoring and does not implement any features.
Otherwise users may add up to 5 relays, but 2 oldest relays
are actually ignored.
Having the maximum number of published relays
and the number of relays used the same between all clients
makes the order of relays in the key irrelevant.
We may even remove sorting by `add_timestamp`
from `get_all_self_addrs()` in the future.
EventThread is created in Account.__init__,
but the thread start may be scheduled later.
If the thread only cals dc_get_event_emitter()
after some events have been emitted,
EventThread will never capture such events
and the tests will timeout waiting for the event.
This happened in CI on a Linux runner
with test_markseen_invalid_message_ids
timing out waiting for DC_EVENT_MSGS_CHANGED
right after sending a message.
The lint is reasonable, but without some work
to bring the future sizes way below the limit,
this lint is frequently triggered in unrelated PRs
that just add some local variables to async functions
or extend some structure that is passed on the stack.
Largest change is in the FFI crate.
With 2024 (but not 2021) edition unsafe code
inside unsafe functions should be marked separately
so we can mark exactly the code that is unsafe.
Some CFFI functions even have no unsafe code inside.
Most interesting change is that .strdup()
functions are not marked as unsafe anymore.
They are allocating memory and return raw pointers,
but there is nothing unsafe about it.
Only using the returned raw pointers is unsafe.
This way calls to .strdup() don't have to be marked
with unsafe{} blocks.
Enabling brotli does not add new dependencies,
we have it already.
Documentation at <https://docs.rs/rustls/0.23.42/rustls/compress/>
recommends enabling at least brotli.
zlib feature is not enabled as it pulls in duplicate zlib-rs 0.6.6
zlib was even never supported in Chromium (while brotli is).
It might still be interesting to enable it in the future
because it seems to be the only option supported by OpenSSL
and there may be servers that support zlib but not brotli.
RFC 8879 specifies zstd as well, but there is no feature to enable it yet.
This also brings back explicit TLS 1.2 feature that was reverted.
We don't want TLS 1.2 support to be accidentally dropped
if no dependencies explicitly require it anymore.
https://docs.npmjs.com/trusted-publishers recommends node-version 24
and not updating npm separately, this change copies the recommended configuration.
Also update node version to 24 in non-release workflows, version 18 is EOL.
There is a version 26 already, but 24 is LTS.
Also disable cache for release pipelines.
Before this change "Err" case spams the logs with
"Failed to download message rfc724_mid=...: IMAP location for ... post-message is unknown."
logged by every transports when the message is not available on any transport.
link2xt
