Flag providers that leak IP addresses of SMTP users in Received header

[link2xt]

Some providers like Gmail leak IP addresses in Received headers: https://ylukem.com/blog/apple-mail-leaks-your-ip-address

Posteo, mailbox.org, mailo, yandex, outlook, fastmail, riseup and systemli do not leak IP address as far as I see from my mail archives.

Also all Mailcow and chatmail instances do not leak the IP.

Leaking providers: Gmail, web.de, 163.com, gmx.net.
icloud leaked in the past but this has since changed, need to be checked again.

[missytake]

Should we also show this information in-app?

IP address leakage isn't related to onboarding, so while it is a warning, the PREPARE flag doesn't really fit. Should we add a WARNING flag beside that?

When I think about it - how useful is an IP address for the email recipient (and their server) anyway? It can't be pinned down to a postal address by non-state attackers; and they don't need to look at the email headers to get the IP address, they can just ask those providers as they log them certainly. It can mostly be used for tracking, which is not nice, but doesn't warrant for a visible warning.

[bkil]

As mentioned on chat before we created this issue, anyone can easily track others by consulting a geoip database. Even when the location is only accurate up to street or town, it can leak information about the sender such as when and where they work, study, whether they are having an affair, whether they are lying, etc. Describing this as "not nice" is an understatement.

No modern communication network is expected to leak client IP to every other client. Even most popular IRC networks started offering free cloaks to every user in the past decades to mitigate this. It is a valid user expectation and it must be present with huge red letters if this expectation will not hold when using a communications app.

[hpk42]

I guess if the provider-db provides a flag for client-IP-leaking providers then anyone who onboards with such a leaky provider could get a warning as a device message. Maybe better Delta Chat could do a self-send-message test after onboarding and see if the IP-address is present and warn about it. Maybe better than maintaining flags in provider-db and more comprehensive (i.e. pointing people with self-hosted e-mail to the problem which can be easily fixed with Postfix servers).

…

On Mon, Jan 06, 2025 at 01:43 -0800, Thomas Nagy wrote: As mentioned on chat before we created this issue, anyone can easily track others by consulting a geoip database. Even when the location is only accurate up to street or town, it can leak information about the sender such as when and where they work, study, whether they are having an affair, whether they are lying, etc. Describing this as "not nice" is an understatement. No modern communication network is expected to leak client IP to every other client. Even most popular IRC networks started offering free cloaks to every user in the past decades to mitigate this. It is a valid user expectation and it must be present with huge red letters if this expectation will not hold when using a communications app. -- Reply to this email directly or view it on GitHub: #313 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[bkil]

I agree that such a self test after installation would be beneficial.

So would collecting and publishing its results in a public chart (such as one generated using provider-db)!

[hpk42]

well, collecting self-test results to some server is an entirely different thing (privacy-wise). Delta Chat developers/servers don't know a list of e-mail addresses or domains from users.

…

On Mon, Jan 06, 2025 at 11:18 -0800, Thomas Nagy wrote: I agree that such a self test after installation would be beneficial. So would collecting and publishing its results in a public chart (such as one generated using provider-db)! -- Reply to this email directly or view it on GitHub: #313 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[bkil]

No self-test result would be automatically collected. A user could file an issue or PR on this repo just as before.

The app may check its built-in cache of the last published list first and only ask the user to submit an update if no (recent) information is present in the published chart about the given provider.

[r10s]

closing stale discussion.

discussions better go to https://support.delta.chat - or already today, one can create a PR with before_login_hint, if we regard a flag as really needed.

as focus is clearly chatmail these days, it is unlikely that we put much effort on adding more fields/buerocracy to the provider-db, esp. as it should land in the apps - very few ppl do go to the index page and see which provider is "best" - where already few ppl use their existent provider to log in. it seems better to work what we have.