>they were seen collecting people's usernames and passwords and using those logins to read people's messages from their own servers almost a decade ago
To be fair microsoft's outlook ios and android clients does the same thing with external providers (like if you used it with fastmail). It is a common practice and something to be aware of when choosing an email app.
EDIT: I'm specifically answering this comment. As for the submission, that was incredibly stupid for them to do in 2023. At this point it should only be opt-in to turn encryption off, not a default.
I had an alert about 9 months ago that someone might have accessed my hotmail, I went to check the previous logins and did see some from places in SE Asia but from months ago.
Mixed in were many logins from an IP address owned by the Microsoft campus at times when I would have been asleep. The account is a backup, and I don't have that mailbox attached to any apps. I emailed their security team asking what was going on but never got a response. After changing the password all the access was stopped. Though I should go back and re-check.
Collecting credentials and reading mail from server is standard practice across hosts of email clients, since it’s the only way to get push notification working. If you don’t trust their server you probably shouldn’t use their client anyway.
Apps can't just send notifications? If I had a mail client installed, couldn't the app just periodically connect to my mail server using my internet connection, see new mail was available, and then pop up a notification so I'd know?
That seems much more secure than having a third party collecting my passwords so they can connect to my mail server from their network using my password just to see if any new mail is there, read the messages, then send a notification to my phone to let me know about them.
I'm perfectly happy to trust Thunderbird enough to configure it to check my mailbox, but I wouldn't feel as comfortable handing my login information directly to Mozilla so that they can log into my mailbox whenever they feel like it. I guess Mozilla could push an update that collects my stored login credentials and do that anyway, but if they did I think there would be a lot of folks who'd protest.
> If I had a mail client installed, couldn't the app just periodically connect to my mail server, see new mail was available, and then pop up a notification so I'd know?
Desktop mail clients do. Phone mail clients can’t, so you either check on a server, or don’t get notifications on time.
Mobile platforms seem a bit broken. Timer/alarm apps seem to be able to take actions and notify on a regular schedule, it is specifically scheduled network activity that's restricted?
yes mobile OSes will delay and group background activity especially if it involves network access. But we're talking minutes, not hours of delay... Some phones are very aggressive and the app will need to show a persistent notification to keep background polling working, though.
I've never used a mobile client that used a third party to monitor a mailbox, they all do polling as you suggest. I'm not sure the man in the middle approach it's as common as OP is implying here (for non-first party clients).
It's debatable whether those are considered push notifications. On one hand, it's pushing the notifications from one program on the device to another. On the other hand, it isn't pushing remotely from a server to the device.
Those are not push notifications, but the push part isn’t the goal, notifications are. The point here is you simply can’t poll on a reliable schedule on mobile devices, so push is the way.
Mail polling doesn't require accuracy. The OS won't delay your polling timer more than 10 minutes in the most aggressive cases, which is perfectly fine.
I'm sure the third party you share your email just to get push notifications with isn't monitoring your mailbox to the second either...
They probably are. If they connect via IMAP, they can use the IDLE and/or the NOTIFICATION command to get notifications of new messages arriving. This is generally as prompt as it gets; the server doesn’t wait much before sending the notifications.
Given the shoddy "battery saving" behavior of various Android vendors, probably not. I have a phone collecting dust that was so bad in this regard that no matter of tuning and disabling battery optimizations would get notifications to work in all apps.
They can but consider this: How would they know to send them?
If you are adding a provider only locally there's no way for the app to know to generate a notification if it doesn't have an IMAP idle connection open constantly or scheduled polling. If the app is shipped by the email provider (like gmail app for ios using a gmail account) they can send pushes without leaving connection open or polling.
The point of having your details with the app developer is that their servers will remain always connected to your email provierr and generate pushes that will go over Apple or Google's push network.
I can see it making sense if you're already using the mail servers of the company that made the app (gmail for example) since they already have unrestricted access to your login info and mailbox anyway.
I guess otherwise I'd rather it be my phone regularly polling my mail server over my connection than a third party regularly polling it using theirs. I can see it being a popular option for folks on expensive/very limited data plans though. It doesn't take a ton of bandwidth to poll a mail server, but checking every 5-10 minutes it could add up.
iOS does that, maybe, but Android doesn’t. The mail client I use on my Android phone notifies me in a timely fashion when new mail arrives, often in less than a second. It just uses IMAP’s IDLE command to wait for new mail. If the connection drops it can just open a new one.
Does it occur to you that there are so many different variants of Android and they all do their own thing regarding background processes? It is so complicated that you can find websites like this https://dontkillmyapp.com/
That’s a fair point; I hadn’t realized how bad certain brands could be. The last Samsung phone I owned was from about 10 years ago, and it worked just fine. I replaced it with a Google Pixel last year when the 3G networks started getting shut down, and it works great too.
BlackBerry was doing this 20 years ago. That's how their push email service (BIS) worked.
And yes I still lament the loss of the blinking red LED, a victim of phone makers today treating devices as if they were a piece of jewelry as opposed to the utilitarian tools they really are.
Interestingly, this is another security issue with STARTTLS. The whole concept of first establishing an unencrypted connection and only then upgrading to encryption is fragile in multiple ways.
Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).
Thank you for writing this, I use it as a reference when explaining the difference STARTTLS and implicit TLS and why people should choose one over the other.
Another nice one is that implicit TLS is SNI routable (and thus much easier to route) -- this is the main reason for me, and I wish the standard had been updated to encourage more people to try 465 (or have a way to specify port in DNS records for example). Huge missed opportunity.
It's not just explicit vs. implicit TLS that's an issue with MUAs. Assuming good implicit TLS configuration there's still no proper way to harden such connections against an active MITM - we don't have an usable MUA-STS standard.