[FEATURE REQUEST] Mailclient: Use unambiguous imap id in imap communication

/e/OS Smartphone Operating System Request a Feature
1

When communicating with an imap server, the application sends a so called imap id identifying itself.
This feature did not get much attention in the past, but since it has gotten clear that some companies, like MS, store user credentials, some organizations have taken action. We do not allow those clients anymore and identify them by imap id.

That’s where my feature request comes in. I do not use /e/, ony of our students does and he got attention, because the mail client shipped with e uses the imap id “mail”. Doesn’t really get more ambiguous than this…

My request therefore is, change the imap id into something more unambiguous, so we sysadmins and mailadmins can keep the trash out and the good clients in. Otherwise they might get caught in the crossfire :wink:

Extract from dovecot log for clarity:

/e/ client:

Feb 06 14:34:27 imap(username)<1264930><58cho7xxxU3V/>: Info: ID sent: name=Mail
Feb 06 15:41:02 imap(username)<1278498><3NJAkxxCU3V/>: Info: ID sent: name=Mail
Feb 06 16:50:15 imap(username)<1292330><37XUxxxCU3V/>: Info: ID sent: name=Mail

some other clients:

Dec 17 19:53:21 imap-login: Info: ID sent: name=com.android.email, os=android, os-version=9; HUAWEIANE-L22, vendor=HUAWEI, x-android-device-model=ANE-LX2, AGUID=IO0fRub8WNMnIc2gBykw/EHsE64=: user=<>, rip=xxx, lip=xxx, TLS, session=<hm2+xxxVLxXoyT7>
Dec 15 14:58:17 imap(username)<31376><b4/EyowM6iSCU3aV>: Info: ID sent: name=K-9 Mail
Dec 19 18:15:37 imap-login: Info: ID sent: name=Gmail, version=6.0.231127.1784698: user=<>, rip=xxx, lip=xxx, TLS, session=<oWnfAxxxeH2ET>
Dec 27 22:19:33 imap-login: Info: ID sent: name=Mac OS X Notes, version=4.9 (2010), os=Mac OS X, os-version=12.6.1 (21G217), vendor=Apple Inc.: user=<>, rip=xxx, lip=xxx, TLS, session=<Yc73WoQNOsaCU4ij>
Jan 04 21:20:18 imap(username)<3709><RpvBxxxUIlyfH9>: Info: ID sent: name=Outlook-iOS/2.0, version=4.2347.1 24832406 prod, vendor=Microsoft Corporation
2

The constant is defined in a build.gradle.kts and if the client sends it is actually configurable (example screenshot).

/e/Mail wouldn’t be less ambigous for the unitiated, that project name has this handicap. In the end, the crafty sysadmin found this forum.

What ID would you propose? android appid “foundation.e.mail” or gitlab repo url?

3

If found the forum by asking the user what client he is using (the username was the only clue i had)…

I don’t mind what id to use. It should be something unique. foundation.e.mail would be fine but /e/mail would work too. It’s not the goal to make the sysadmin easily detect which client it is, i only care of distinguishing it from other clients.

4

here you go - https://gitlab.e.foundation/e/os/mail/-/merge_requests/158

I have another MR there getting the thumbs-down, so depends if this gets merged. I think it’s not enough info bits to easily find the code repo. I think taking it up with thundernest/k9 to create a more elaborate client-id (vendor/x-repo-url) and proposing that could find more acceptance. There’s also a security side to exposing used apps and versions, not all remotes are equal.

Interesting case with stealin’ Outlook as to what the rfc forbids and what admins should do - https://www.rfc-editor.org/rfc/rfc2971

Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only […]

Servers MUST NOT deny access to or refuse service for a client based on information from the ID command.

1 Like