search

deltachat / deltachat-core-rust

Delta Chat Rust Core library, used by Android/iOS/desktop apps, bindings and bots 📧
https://delta.chat/en/contribute
Other
679 stars 86 forks source link

Move bounce messages to Delta Chat folder #4427

Closed link2xt closed 1 year ago

link2xt commented 1 year ago

When an NDN (bounce message) is received in response to a Delta Chat message, Delta Chat processes NDN, but the NDN stays in the Inbox.

If user has "move to Delta Chat" enabled and chats in a group where someone has full inbox or the other reason for NDNs, Inbox is going to be cluttered with NDNs. Then the user opens webmail and finds tens of NDNs in the inbox filling the whole screen.

cc @brabo

Septias commented 1 year ago

Should NDNs be moved to the DC-folder or should they just be removed? Anyway, I don't really understand why they are not being moved as they should easily be picked up by

https://github.com/deltachat/deltachat-core-rust/blob/502ec361ec80660f988a6dece081d56f66cafad9/src/imap.rs#L1090-L1104C21

link2xt commented 1 year ago

Should be moved to DC folder, there can be multiple DC clients that want to read the message.

The message may not be moved because target points to inbox, as decided by needs_move_to_mvbox.

Septias commented 1 year ago

I suggest closing this issue without any action because it is too cumbersome to solve. The first problem is that different mail servers handle NDNs differently (see https://github.com/deltachat/deltachat-core-rust/pull/4834#issuecomment-1780865204) so it is hard to get a solution that works for all providers equally well. The second approach which was elaborated in #4834 was to use the message parts to find the message which caused the NDN. The problem with this approach is that at the moment message removal and moves are handled in the imap-cycle which does not have extracted message parts. If we want to move messages based on parts, we would have to create a new move/removal logic only for this purpose because (https://github.com/deltachat/deltachat-core-rust/blob/84a4b5f1e6bc947a76da92886af3f88c253ad1a5/src/imap.rs#L1094) is highly specific and can't be reused for this case. To add this much logic for just an edge case seems overkill imo and will only worsen code quality and predictability. Receiving NDNs also has an easy fix: remove said person from a group. So it is not like this is a really bad problem.

Septias commented 1 year ago

While writing the above comment a pretty neat heuristic came to my mind: We can scan the whole message body whether it contains any occurrence of Chat-version: 1. Whether the original message has its own part or is pasted in the message body doesn't matter then. We can just move the ndn is such a case. Together with the check for report-type=delivery-status and the HeaderDef::ChatDispositionNotificationTo check this should not produce too many false positives.

link2xt commented 1 year ago

I suggest closing this issue without any action because it is too cumbersome to solve.

I am ok with just closing it, normally there are not that many NDNs. In case of normal email account user can read them and try to fix, and in case of dedicated account no need to move mails to a separate folder anyway.

Septias commented 1 year ago

Nice