don't prevent creating contacts without keys

[hpk42]

#3177 introduced a dialogue to prevent chatmail-profiles from creating chats when there is no key.
However, chatmail servers have "passthrough_recipients" and there is a pending PR to allow to message users on an XMPP bridge (not encrypted), see deltachat/chatmail#408

Effectively, even if it's a chatmail profile, you may still succeed sending out an unencrypted message but the dialogue prevents even trying it, arguably a bug in dc/chatmail interaction.

To keep things simple, it seems best to drop the #3177 "a-priori" dialogue. There already is a "tap more" system message when a message fails to get sent because of missing encryption, which shows the dialogue, so we don't need to per-emptively
do it.

The more complex alternative is to implement some protocol between chatmail-server and core to tell about "unencrypted" addresses and to query that from the UI to determine if to show the dialogue, but that seems hardly worth it.

[adbenitez]

question is how will user add the contacts anyways, because for chatmail there is no classic "add contact manually" option

[adbenitez]

should we also add back the "add contact manually" option for chatmail?

[hpk42]

In the xmpp-bridge case i guess the bridge will first send a message to you, you accept the contact, and then you can mail back (unencrypted, only TLS) but indeed, there wouldn't be any manual contact-email addition in the app then IISIC.

However, it's questionable that DC decides to not even try adding a contact without knowing of a chatmail servers configuration. I'd surely like to try avoid "add contact manually" back -- that seems a bit much just for these relative corner cases.

Maybe we also rather don't do deltachat/chatmail#408 and maybe remove passthrough_recipients instead -- but then you can not message the privacy contact from the policy, for example.

[adbenitez]

In the xmpp-bridge case i guess it will first send a message to you, you accept the contact, and then you can mail back (unencrypted, only TLS) but indeed,

this already works today, the dialog is only about some of the rare cases of remaining ways of starting a chat with an email address, mainly mailto links and clicking addresses in received messages

I created a tentative PR reverting #3177 at #3365