Interesting article in german telecommunication newsletter showing a problem in DC

Good, it surprises me that deltachat aggregates prompts for the same sender.

The article did.

If you’re concerned about user support, why aren’t you even more interested in thinking through the options to prevent future spam from bothering users. Email-chat spam will come up in deltachat, if it is possible. It even seems to have happened in the article by an unknown contact manually adding a public address to a deltachat group.

the article was worried about spam in classic email client not in Delta Chat (they were worried about people using Delta Chat to send spam) the case they describe was that some user using Delta Chat, added they email address (one they check using classic email clients) and that they were no able to leave the group, which anyway would happen if an annoying user write that emails in a classic email app, they can’t avoid people sending emails to them, they just have to blacklist that user, this is not an issue introduced by Delta Chat, it is just how email works currently

1 Like

So, that actually is exactly the case of an unknown user spamming an address using email-chat headers.

Of course deltachat can’t do anything about classic clients. (They usually suffer from spam.)

But deltachat can prevent such spam to show up in the messenger’s chat, by restricting the full reachability to messages from known addresses, by default. (And having the options outlined above.)

That could be build into deltachat:

Support for creating “relay groups” in deltachat, and therefore becoming an admin of them.

In such groups the admin would send out messages to the group using BCC, and all members can technically only respond to the admin(s). But if this group is a full relay group, instead of just a news feed, the admins’ deltachat instance(s) could automatically BCC-forward the replies and messages received from a valid member, to all members.

If the deltachat instances of the members could deduplicate the messages locally, the relay group could even support multiple admins and relay-instances (for redundancy and fallback).

Back to the topic of the article.
Its interesting in my personal opinion, but its also a bit misleading to read.
My comment/thoughts on it:

A link to unsubscribe/leave a group: Where should this link lead to? (dc has own no servers) the only option I could think of would be a mailto link that lets you sent a predefined message that dc clients could recognize and remove you from the group. But I’m not sure whether mailto links work in all email clients. (The point is that the most people that see a link probably think it leads to a website)

That point about spammers is not a real point: even plain Thunderbird or a simple php script is better suited for spamming.

The next funny point is “The privacy is broken, because you can see email addresses” - For email you need email addresses, it’s not possible to hide email addresses when you have a normal group (for mailing lists and channels its another topic the latter one would use bcc, but there you can’t write in the group. Also both are not implemented at time of writing, for progress on those see New feature: Group Types)
Also you can get an anonymous email addresses dedicated only for your deltachat account, so nobody can spam you on your main email email-address.

I continue in german:
“Außerdem fehlte in den Mails die gesetz­lich vorge­schrie­bene Abmel­demög­lich­keit (Opt-out) bei dem Grup­penver­sand” - Soweit ich weiss gilt das nur fuer newsletter und mailinglisten.
Naja sehen wir dass ganze “Datenschleuder” gerede mal als hilfe schrei nach den newsletter features :wink:

Fazit:
Der Artikel ist missverstaendlich, weil suggeriert Gruppen seien unsicher und bedenklich, dabei meint er nur die Gruppen, die als Newsletter verwendet werden.

1 Like

I would consider all relevant points, that the article may touch, to see where deltachat may suffer a neglect. Even beyond their literal understanding.

2 Likes

Great Summary @testbird :+1:

Hello, potential new user here.
I want to introduce DC at my workplace and my kids school to replace whattsapp. And i have the power to do so.
But:

  1. The shools secretary has to be able to send infos/newsletters to a group consisting of all parents, not revealing the individual emailadresses to every member of the group, and all answers go only to the secretary, not the group.
  2. The teachers should be able to send to a group without revealing the mailadresses of the members, but all answers are visible to all group members.

These requirements fit to this discussion, i wanted to add this real life scenario to it.

hi @PaulBemter

first of all, welcome aboard!

to the questions: both are solvable by some server-side newsletter software that is configured accordingly.

  • the first point seems to be rather simple - a newsletter that sends out a normal, individual mail for each recipient, for the recipients in delta chat, this appears as a 1:1 chat then, the list of all recipients is never sent out, answers just go to the email address in From:-header

  • for the second point, in addition, answers from recipients have to be resent by the server to all group members by impersonating the sender. also this should be doable.

changes in delta chat are not needed for both points.

im am not an expert in newsletter software, however, i know there are solutions out there that will fit :slight_smile:

btw, i think this open standard, to do whatever is required in a given situation, based on open standards and existing solutions, is one of the biggest advantages of Delta Chat compared to most other messengers.

Thank you, r10s.
But these solutions happen outside of DC.
While other messengers do have a broadcast function integrated, and show members of a group by name only (but this last I am not sure of…).
I order to be better than whattsapp DC has to be just as easy while revealing less.

Hi, I’m not sure if this works with your server.

But I know in GMX it’s an option to create a allocator list (german:Verteiler).

This list get’s a name like all.parents@gmx.net.

If you send your message to this address every member of this list get’s a single mail.

I think a list like this can maintained better then via DC.

And via DC you can create still “normal Groups” or even “veryfied groups” (where nobody can added who is not veryfied yet.)as school class groups.

But still, I agree.
DC is missing a broadcast function and it’s already requested by me.
See post above.

1 Like

Just a idea for your second case:

If you create a server sided list as I mentioned before and give everybody the right to reply to this address it should work.

So you would have a anonymous group.
Or do I think in the wrong direction?

Note that with a standard email distribution list, I think these would end up in separately created per sender chats.

And standard email list servers won’t work either, see email list servers still not supported.
So @cracker0dks do you maybe have a pointer for a working free software “newsletter” server solution?

The only solution that could be made “easy to use”, without having to become a server admin, seems to be the BCC (relay) groups.

I have not yet tested it.
It’s just a raw idea :wink:

@PaulBemter As you seem to be wanting to show deltachat to new casual users, hopefully this can help you to know some pitfalls beforehand.

“Without having to become a server admin” is the point. The whish for broadcast functionality already came up before (see link), i should have posted there i guess.

Thank you testbird!
I was not aware that, once i have a persons email as contact in DC, ALL emails from this emailaddress are shown ONLY in DC!
If thats the case, this is a killer.
This could only be circumvented by creating a new emailadress solely for DC use.
I know this is no big deal and would be the best anyway, but this is already too much asked for from the casual user. Unfortunatedly, but think of your cousin, aunt, neighbour…
I have to test this next week.

Well, as you seem to already have noticed very quickly, separate accounts are not as good as it may appear first, they are actually detrimental to the basic idea of avoiding separate “silo” spaces.

These are just a hand full of usability issues, but they need and can be solved best within deltachat.

Thank you (to you and all the developers of DetlaChat) for making an independent and universal messenger!
Reading through the forum I got confused though.
Many posts sound like DC is about making a mailhandler with chat-interface.
But I think the idea was to make a messenger, like but better than whatsapp, signal and so on, based on the existing email infrastructure.
Therefore there is no need to see regular mails in DC for example, as it was suggested somewhere in the Forum.
I have several Emailprograms on several devices which do this expertly and comfortably. No need for another one.
I fear that the development of DC might be slowed down by focusing on making it another Mailprogramm, instead of making it a messenger.
This is just my opinion as a simple user.
But, maybe, simple users are the target group for DC, so i thought this opinion could be useful.

For example, interacting with email list servers, but foremost the major feature to be able to chat with every existing email address requires some extent of email compatibility.

If you look at the changelog and commits, unfortunately, development has taken up many new other things than fixing the hand full of already half-working, long-pending basic usability issues.