Special handling of SMS/MMS Gateways

I’ve been using Delta.Chat for chatting with people that only use SMS/MMS. For the most part it works well, but a lot of it is left up to the whims of their providers’ SMS/MMS Gateways. Some gateways attach the message from the SMS/MMS side as a txt file annoyingly, others don’t keep the subject (breaking groups), Verizon’s puts the message as both the body and the subject doubling the message on Delta.Chat, etc.

Since the gateways are publicly listed, would Delta.Chat be able to have rules specifically for those gateways? Like have the text displayed from the attached txt file instead of the body of the email from the gateways that put the message into a txt file, another rule of only displaying the body of the message from the Verizon gateway, one for having group chats be based on what addresses are included in the group instead of the subject if any members of the group are using a SMS/MMS gateway, etc.?

I know it shouldn’t be the responsibility of the team or community to compensate for the bad quirks of the SMS/MMS gateways, but it would make it a lot easier to use. I’d be up for figuring out and listing what quirks the different gateways have.

Creating rules specific to each gateway might be a maintenance quagmire. Providers have no standard WRT gateways that they are under any obligation comply with over time, and so provider-specific features might break at any time.

Changing the way that Delta.Chat globally handles very small text file attachments - from any origin - is probably a more sustainable approach where Verizon SMS is concerned, without any really glaring downsides other than the work itself needed to implement the feature.

The group chat feature for other providers is more tangled, and would probably necessitate a domain-aware toggle somewhere in the settings to switch from subject-based threading to some other method, perhaps the one you suggest. It might also be that group chats simply aren’t viable in this channel.

we already have provider specific settings in our provider database.
how many estimated providers are there? could you get some sample .eml files for tests?
I haven’t discussed this with the team, but it would help to get a better feel of the scope of this proposal.

Also what domains do they use for sender? are these services detectable by their email domain or can also normal emails be received from these addresses?

Also SMS is not that widely used anymore where I live as it is in the USA, but I can imagine that it would be really useful for you guys if much communication still happens over sms.

But even if the team would disagree there is always the option of making a soft-fork of deltachat that has this feature.

this could be solved easily, Delta Chat core can detect that the subject is the same as the body and then instead of displaying “SUBJECT – BODY” display just “BODY” cc @link2xt

1 Like

where?

Creating rules specific to each gateway might be a maintenance quagmire. Providers have no standard WRT gateways that they are under any obligation comply with over time, and so provider-specific features might break at any time.

True, though, from what I’ve seen, they haven’t changed much in years. Though, others have suggested solutions here that would probably be better than having rules for specific gateways anyway, including your suggestion on how it can handle txt files

I’ll have to take a look at the documentation around the .eml files.
All the domains I know of are listed on the wikipedia page:

The domains accept any email as far as I can tell, as long as it’s
properly addressed to a number.

I was referencing the wikipedia page I linked in my initial post. If
that isn’t good enough, I don’t know of any other place that has an up-
to-date list.

1 Like