iequidoo

> I still don't understand why vc-request is special. I thought it's a good heuristic because vc-request means that it's a new contact, not the existing one changed its address....

> With AEAP it is unclear what should happen if we have two contacts with the same key in a verified group and then someone writes to this group with...

> With AEAP it is unclear what should happen if we have two contacts with the same key in a verified group and then someone writes to this group with...

There's no sense to hide large messages with not yet checked signatures in protected chats, if it's an attack then there's a server allowing From forgery, but then such a...

So, for the From name it is implemented, as suggested, only for verified chats, but To display names are protected for all encrypted emails as compatibility seems less critical here....

I think this is underimplemented now. Names are not revealed in verified chats, but during verification (i.e. SecureJoin) they are still sent unencrypted. Going to fix this

> We can implement "Legacy Display Element" from the new standard https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/, then there is no need to wait for Thunderbird and K-9 (aka Thunderbird for Android) to support it....

It happened also to me a couple of times, but i didn't understand the reason. In the log it looks like `ac2` doesn't receive the `vg-member-added` message

Apparently it arrives immediately, but we still have some race in IMAP handling: https://github.com/deltachat/deltachat-core-rust/actions/runs/7630255470/job/20797452090?pr=5209 After IO has been restarted, `vg-member-added` is received and the debug assertion fired.

As far as i can tell from the log, there's a race in `Session::idle()` somewhere between the call to `self.server_sent_unsolicited_exists(context)` and `handle.wait_with_timeout(IDLE_TIMEOUT)`. So, either it's a problem in `async_imap` not...