I am able to receive, but not send unencrypted messages. So I can subscribe to newsletters that only email me. The wording used in the privacy page on the websites for these servers mislead me into believing that they will receive un-encrypted messages, if they only can’t be sent.
Actual behavior
I am also unable to receive un-encrypted messages. I cannot use chatmail email addresses to receive newsletters or verify accounts.
Steps to reproduce the problem
Create a chatmail account with Delta Chat on a public chatmail server such as nine.testrun.org or tarpit.fun
Go into settings > advanced > Password and Account to get the email address (the difficulty of obtaining the email address is a separate issue)
Attempt to send an email from a traditional email server (GMail, Protonmail, Riseup) to your Delta Chat email
Screen snapshots
Debug logs
Logs
<!--
If applicable, debug logs can be copied from within the Delta Chat app:
Open the _Settings_ menu -> _About_ -> _version number|Info_.
Alternatively from the Android system log:
` adb logcat -v time -s DeltaChat `
This log contains private data (e.g. mail address, provider information) which shall be removed or anonymised prior to posting.
-->
Chatmail servers used to receive unencrypted mails, but that is no longer the default. I guess the documentation hasn’t caught up. If you have suggestions for clarifying edits, they might be useful.
There are some websites that offer forwarding addresses; some also offer PGP encryption. Does any one know of one that offers Autocrypt, so it could forward plaintext messages to a Chatmail account? That would enable subscriptions etc..
If you have suggestions for clarifying edits, they might be useful.
Change “prohibits sending out un-encrypted messages” to “prohibits sending out or receiving un-encrypted messages” or “prohibits all un-encrypted messages” or “prohibits sending or receiving of all unencrypted messages”
Great, that is clear and concrete. I’d recategorize this thread as a feature request, then (which you can do if you “edit” the first message). The devs are a bit busy just now but will eventually review it.Thank you for reporting this!
I find it a shame that these use cases are no longer supported. When chatmail was first released, it had amazing potential to be used not only for chatting but also receiving newsletters or even as an address in online contact forms without worrying about your address getting leaked to spammers or having your identity tracked across the web. The inability to start unencrypted conversations was a sensible way to prevent abuse by spammers and in my opinion this struck the right balance.
The new restrictions have dampened my initial enthusiasm as it seems, like Sandra mentioned in another thread on a related subject, that Delta Chat is moving away from compatibility with the wider email world. While chatmail is still useful for chatting, it is now more of a closed bubble that prohibits use cases like receiving newsletters, which I find a bit disappointing as it limits the full potential of chatmail..
hell no, no, chatmail operators are not paying servers so you can subscribe to unencrypted newsletters while at the same time they have to write complex GDPR compliant privacy policies, there are other services for that, and you can setup your own email server as well, what you say about “closed bubble” is also nonsense, it is called “security” and “encryption”, the chatmail servers are only enforcing encryption, as long as it is encrypted, the email can come from any classic email server etc. the way it should be, all emails should be encrypted without the providers having access to it, chatmail is making a great work here at increasing the number of encrypted emails in the email ecosystem, in fact we need more of that bubble to expand
this is a feature, not a bug, that you can’t receive unencrypted also mean you can’t receive spam or fishing, the text just should be updated to say that all messages should be encrypted
chatmail operators would not pay more for the server because of unencrypted newsletters and most don’t write privacy policy but use existing templates.
The original reason for rejecting unencrypted incoming emails since Reject unencrypted incoming mail by hpk42 · Pull Request #538 · chatmail/relay · GitHub is to make sure chatmail relays don’t store unencrypted emails at any time. This is prioritizing the needs of chatmail operators, even though may be less convenient for the users because they cannot use chatmail for disposable addresses to register on the websites.
You can create a disposable address anywhere else and then us that account with Delta Chat. In my case, the web hosting company that hosts my website allows me to create as many regular mail addresses as I need.
Delta chat offers free secure mail and that’s a lot. If someone needs non secure communications, any server would work with the delta chat app, even Gmail.
Indeed I would be surprised if newsletters which are sent with low frequency, mostly just text, and immediately deleted from the server once downloaded created any noticeable overhead for the server.
This makes sense and it’s important to consider the needs of chatmail operators. Are the restrictions on unencrypted email “baked in” or are they easy for operators to disable? I noticed that half of the relays listed publicly are outside the EU and therefore they should not legally be subject to GDPR.
The restrictions are a good thing for operators who need to make sure everything is encrypted on the server, but if there are other operators who don’t mind having some unencrypted messages on the server and want to provide more convenience for their users, it would also be nice to have this option in my opinion.
I agree.
This is true, there are other options. However chatmail was easier to use and provided more privacy than most other options, for example you need to register a lot of pesonal information just to use a Gmail account. If there is no possibility for chatmail to support use cases like newsletters, that’s fine, and we can look for other options, but if there is also support for these use cases (when the operators are fine with this), then that would be the icing on the cake.
Many freemium operators offer instant forwarding from free random disposable addresses to a real address (meaning mails are only very transiently on their servers). Some let you upload a public key, and then they will encrypt the message before forwarding it (meaning it is only very transiently unencrypted or on their servers).
At least one lets you reply to mails you receive via the same proxy route (the message shows up as “from” the disposable address, hiding the real address, and the first-hop encryption is stripped so the recipient gets plaintext). This would in theory allow you to participate in members-only mailing lists.
Obviously the docs should reflect the status quo, but we seem to be discussing the functionaslity too.
How costly would it be for the server to encrypt incoming unencrypted mail with a subkey before storage? Or relay and delete it immediately if the recipient is online and they can push it?
Or, on the simple side, could the server setup ask the user their jurisdiction, and offer a jurisdiction-specific default config?
It’s not simple. What if I’m citizen of Hakzastan with living address in Urkaine but currently traveling the Europe? What if law is changes in one of the states? (and it changes constanlly). You want to open a can of (lawer) worms here…
Also imagine I’m chatmail operator. If all the mail on it is encrypted - it’s much cooler for me: no spam, no abuse complaints, no one can say I read some mails that I shouldn’t read, and in case law enforcement will ask questions or grab the hardware - I’m not the weakest link in your privacy.
I think this usually goes by the jurisdiction of the server. Unless you are an American corporation; most countries don’t try to control computers beyond their borders. Though you may be personally liable in your jurisdiction of citizenship or residence or transit for things done online while elsewhere.
There are countries that pressure people overseas whom they consider their nationals, but they use extra-legal means, like blackmail and threats.
Chatmail’s defaults cannot comply with the laws of every jurisdiction in the world (I think some ban encryption). But accomodating more than one is possible.
How about encrypting incoming messages before storage?
