1 Dec
2020
1 Dec
'20
11:35 p.m.
Hello,
I've been experiencing a strange problem with delta for quite a while
now: even though I've selected the option to *send* so called "read
receipts" I am not receiving them since at least June or so.
The strange thing is that instead my client(s) *do* send out receipt
upon on read events!
Initially I've attributed the thing to
https://github.com/deltachat/deltachat-core-rust/issues/1610 but seen
that the bug seems long gone, I suspect something else is going on.
To dig a little deeper I need some extra info: I've looked at some
messages and it seems libdelta sends out an extra
"Disposition-Notification" header only to *non* delta chat clients.
How the "receiptiviness" if you allow me term :) is negotiated between
clients? Does libdelta send some extra info only upon change setting
events?
I should probably add that I've also experienced a really bad upgrade
back in August because F-Droid did bump the version to a major one
after months and the process did not went well, no messages were
received and I had to resort by making a backup, and importing the
thing after an installation from the Play Store.
Do libdelta checks data integrity/correct format before importing? I
don't think this is the cause but am wondering if the backup was
"somehow" corrupt.
Thanks.
--
Marco
CONFIDENTALITY NOTICE:
The information contained in this message as well as the attached
file(s) is confidential/privileged and is only intended for the person
to whom it is addressed. If the reader of this message is not the
intended recipient or the employee or agent responsible for delivering
the message to the intended recipient, or you have received this
communication in error, please be aware that any dissemination,
distribution or duplication is strictly prohibited, and can be illegal.
Please notify us immediately and delete all copies from your mailbox and
other archives. Thank you
------------------------------------------------------------------------
In ottemperanza con il nuovo Regolamento Europeo GDPR n. 679/2016, le
informazioni contenute in questo messaggio sono riservate e
confidenziali. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora Lei non fosse la persona a cui il presente messaggio è
destinato, La invitiamo ad eliminarlo dal Suo Sistema ed a distruggere
le varie copie o stampe, dandocene gentilmente comunicazione. Ogni
utilizzo improprio è contrario ai principi del nuovo Regolamento Europeo
GDPR n. 679/2016.
2 Dec
2 Dec
8:55 a.m.
Welcome to Delta Chat!
A read receipt should be sent if both chat partners have enabled it in
the settings.
However, not to confuse the user with hundreds of read receipts, Delta
Chat automatically marks them as seen and moves them to the "DeltaChat"
folder in your mailbox, so have a look there.
Read messages then get two checkmarks, just as you know it from other
messengers.
Does this explain the confusion?
On 02.12.20 00:35, Marco Vittorini Orgeas wrote:
Hello,
I've been experiencing a strange problem with delta for quite a while
now: even though I've selected the option to *send* so called "read
receipts" I am not receiving them since at least June or so.
The strange thing is that instead my client(s) *do* send out receipt
upon on read events!
Initially I've attributed the thing to
https://github.com/deltachat/deltachat-core-rust/issues/1610 but seen
that the bug seems long gone, I suspect something else is going on.
To dig a little deeper I need some extra info: I've looked at some
messages and it seems libdelta sends out an extra
"Disposition-Notification" header only to *non* delta chat clients.
How the "receiptiviness" if you allow me term :) is negotiated between
clients? Does libdelta send some extra info only upon change setting
events?
I should probably add that I've also experienced a really bad upgrade
back in August because F-Droid did bump the version to a major one
after months and the process did not went well, no messages were
received and I had to resort by making a backup, and importing the
thing after an installation from the Play Store.
Do libdelta checks data integrity/correct format before importing? I
don't think this is the cause but am wondering if the backup was
"somehow" corrupt.
Thanks.
11:27 a.m.
On Wed, 2 Dec 2020 09:55:06 +0100
Hocuri <hocuri(a)gmx.de> wrote:
Welcome to Delta Chat!
A read receipt should be sent if both chat partners have enabled it in
the settings.
As said, this is not the case, they are one way and only my side
apparently does not receive them.
--
Marco
CONFIDENTALITY NOTICE:
The information contained in this message as well as the attached
file(s) is confidential/privileged and is only intended for the person
to whom it is addressed. If the reader of this message is not the
intended recipient or the employee or agent responsible for delivering
the message to the intended recipient, or you have received this
communication in error, please be aware that any dissemination,
distribution or duplication is strictly prohibited, and can be illegal.
Please notify us immediately and delete all copies from your mailbox and
other archives. Thank you
------------------------------------------------------------------------
In ottemperanza con il nuovo Regolamento Europeo GDPR n. 679/2016, le
informazioni contenute in questo messaggio sono riservate e
confidenziali. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora Lei non fosse la persona a cui il presente messaggio è
destinato, La invitiamo ad eliminarlo dal Suo Sistema ed a distruggere
le varie copie o stampe, dandocene gentilmente comunicazione. Ogni
utilizzo improprio è contrario ai principi del nuovo Regolamento Europeo
GDPR n. 679/2016.
2:03 p.m.
The strange thing is that instead my client(s) *do*
send out receipt
upon on read events!
How have you determined it? The read receipts you send out are not saved
in your mailboxes. Other users get double tick for the messages you sent
in 1:1 chat?
Initially I've attributed the thing to
https://github.com/deltachat/deltachat-core-rust/issues/1610 but seen
that the bug seems long gone, I suspect something else is going on.
This bug is not gone, rather closed as WONTFIX. DC uses non-standard
Chat-Disposition-Notification-To rather than standard
Disposition-Notification-To header for reasons mentioned there.
To dig a little deeper I need some extra info:
I've looked at some
messages and it seems libdelta sends out an extra
"Disposition-Notification" header only to *non* delta chat clients.
DC should sent Chat-Disposition-Notification-To header in outgoing
messages. Check that it is true.
How the "receiptiviness" if you allow me
term :) is negotiated between
clients? Does libdelta send some extra info only upon change setting
events?
The logic is simple: Chat-Disposition-Notification-To header is sent out
in every normal (not read receipt itself) message if read receipt
setting is enabled.
If a message with Chat-Disposition-Notification-To header is received,
it is marked as a message "read receipt requested". When you read it,
your client will send out a read receipt if the setting for read
receipts is enabled.
I should probably add that I've also experienced a
really bad upgrade
back in August because F-Droid did bump the version to a major one
after months and the process did not went well, no messages were
received and I had to resort by making a backup, and importing the
thing after an installation from the Play Store.
Do libdelta checks data integrity/correct format before importing? I
don't think this is the cause but am wondering if the backup was
"somehow" corrupt.
Make sure not to use lower version than the one you exported backup
from, as there is no version check on importing, downgrade is allowed.
But this should not be the cause in your case.
3 Dec
3 Dec
11:28 a.m.
On Wed, 2 Dec 2020 17:03:21 +0300
Alexander Krotov <ilabdsf(a)gmail.com> wrote:
The bug report was opened after this discussion
https://support.delta.chat/t/delta-chat-not-sending-read-receipts-any-more/…
which originally described a problem very similar to the one I'm
experiencing.
Then somebody else stepped in and kind of derailed the discussion by
opening an issue to take in consideration standard MUAs.
I'll file another report if the need arises.
The import was done into on a much bigger version of the android client.
Afterwards I also added the desktop version to the mix by importing the
backup.
As I experience the problem with both I wonder if my DB is somehow
corrupted.
Anything else I could check in this direction for further
investigation?
--
Marco
CONFIDENTALITY NOTICE:
The information contained in this message as well as the attached
file(s) is confidential/privileged and is only intended for the person
to whom it is addressed. If the reader of this message is not the
intended recipient or the employee or agent responsible for delivering
the message to the intended recipient, or you have received this
communication in error, please be aware that any dissemination,
distribution or duplication is strictly prohibited, and can be illegal.
Please notify us immediately and delete all copies from your mailbox and
other archives. Thank you
------------------------------------------------------------------------
In ottemperanza con il nuovo Regolamento Europeo GDPR n. 679/2016, le
informazioni contenute in questo messaggio sono riservate e
confidenziali. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora Lei non fosse la persona a cui il presente messaggio è
destinato, La invitiamo ad eliminarlo dal Suo Sistema ed a distruggere
le varie copie o stampe, dandocene gentilmente comunicazione. Ogni
utilizzo improprio è contrario ai principi del nuovo Regolamento Europeo
GDPR n. 679/2016.
saved in your mailboxes. Other users get double tick
for the messages
you sent in 1:1 chat?
That and in addition I see an extra SMTP send transaction in the MTA log
after I read a message.
Initially
I've attributed the thing to
https://github.com/deltachat/deltachat-core-rust/issues/1610 but
seen that the bug seems long gone, I suspect something else is
going on.
This bug is not gone, rather closed as WONTFIX. DC uses non-standard
Chat-Disposition-Notification-To rather than standard
Disposition-Notification-To header for reasons mentioned there.
DC should sent Chat-Disposition-Notification-To header in outgoing
messages. Check that it is true.
As already said, I confirm that this happens *only* for outbound
messages towards regular MUA contacts.
I don't see any "Chat-Disposition-Notification-To" header inside
outbound *and* inbound messages between myself and DeltaChat confirmed
contacts despite the relative setting being turned on.
The logic is simple: Chat-Disposition-Notification-To
header is sent
out in every normal (not read receipt itself) message if read receipt
setting is enabled.
If a message with Chat-Disposition-Notification-To header is received,
it is marked as a message "read receipt requested". When you read it,
your client will send out a read receipt if the setting for read
receipts is enabled.
If that's the case, i.e.: libdelta just uses a custom
disposition header, and reacts to it, then I could be hitting a bug.
Strangest thing is my delta clients still send receipts even in absence
of it.
I should
probably add that I've also experienced a really bad
upgrade back in August because F-Droid did bump the version to a
major one after months and the process did not went well, no
messages were received and I had to resort by making a backup, and
importing the thing after an installation from the Play Store.
Do libdelta checks data integrity/correct format before importing? I
don't think this is the cause but am wondering if the backup was
"somehow" corrupt.
Make sure not to use lower version than the one you exported backup
from, as there is no version check on importing, downgrade is allowed.
But this should not be the cause in your case.
6 Dec
6 Dec
2:56 p.m.
On Thu, 3 Dec 2020 12:28:36 +0100
Marco Vittorini Orgeas <marco(a)vittorini.org> wrote:
Anything else I could check in this direction for further
investigation?
Are there any willing developers on this list to exchange some messages
with my delta account and confirm the problem ?
--
Marco
CONFIDENTALITY NOTICE:
The information contained in this message as well as the attached
file(s) is confidential/privileged and is only intended for the person
to whom it is addressed. If the reader of this message is not the
intended recipient or the employee or agent responsible for delivering
the message to the intended recipient, or you have received this
communication in error, please be aware that any dissemination,
distribution or duplication is strictly prohibited, and can be illegal.
Please notify us immediately and delete all copies from your mailbox and
other archives. Thank you
------------------------------------------------------------------------
In ottemperanza con il nuovo Regolamento Europeo GDPR n. 679/2016, le
informazioni contenute in questo messaggio sono riservate e
confidenziali. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora Lei non fosse la persona a cui il presente messaggio è
destinato, La invitiamo ad eliminarlo dal Suo Sistema ed a distruggere
le varie copie o stampe, dandocene gentilmente comunicazione. Ogni
utilizzo improprio è contrario ai principi del nuovo Regolamento Europeo
GDPR n. 679/2016.
1476
days inactive
1481
days old
6 comments
3 participants
participants (3)
-
Alexander Krotov -
Hocuri -
Marco Vittorini Orgeas