Does Fastmail offer automatic PGP encryption with bring-you-own keys? That’s the benefit I am referencing, not just IMAP, and I never referenced custom domains.
I’m sorry but IMAP app passwords by design are a 2FA bypass. This doesn’t seem that insane of a default and certainly not a vulnerability. If someone has access to an app password they already have access to all your emails. Sure they get a little more by resetting 2FA, I would personally disable it, and it is a less secure configuration, but it’s not a vulnerability.
When? Demonstrate this.
Again, when?
Private key for what? In plain text or encrypted with passphrase? What does this mean?
OK? I would be surprised if they by default made it so you couldn’t log into IMAP with your main password just because you used an app password elsewhere.
Let me stop you there, Privacy Guides doesn’t make recommendations for business use last I checked.
You’re getting off track, this was supposed to be a list of their countless security and privacy mistakes, remember?
That is not a security or privacy issue
That is not mailbox’s fault in any way, and usually this is a blanket ban on uncommon email providers, I doubt they specifically banned mailbox, they probably have an allow list.
This is proven false by testing on this very forum. Mailbox will reject your use of another users’ custom domain.
Again, this is not a security of privacy issue
Not a security or privacy issue….
I don’t think the privacy community can afford to disregard every product with an arrogant lead developer, even if it’s not ideal.
I’m sorry but IMAP app passwords by design are a 2FA bypass. This doesn’t seem that insane of a default and certainly not a vulnerability. If someone has access to an app password they already have access to all your emails. Sure they get a little more by resetting 2FA, I would personally disable it, and it is a less secure configuration, but it’s not a vulnerability.
It definitely is a vulnerability. A IMAP app password should NEVER be able to reset the whole authentication chain and gain complete access. By definition it is ONLY there to read E-Mails, not to write e-mails and certainly not to bypass all authentication measures, lock the user out and gain complete control over an account. And I definitely see a big difference between snooping in my mailbox and gaining complete access and locking me out.
When? Demonstrate this.
Again, when?
Private key for what? In plain text or encrypted with passphrase? What does this mean?
OK? I would be surprised if they by default made it so you couldn’t log into IMAP with your main password just because you used an app password elsewhere.
It defeats the entire purpose of having app passwords which is isolation.
Let me stop you there, Privacy Guides doesn’t make recommendations for business use last I checked.
Agree, but nevertheless, this point again shows that mailbox does not understand security. This is not a problem regarding the specific problem for business users, it is a problem about mailboxes underlying understanding about such topics. They again and again show such major problems, why should you be able to trust them in other topics..
You’re getting off track, this was supposed to be a list of their countless security and privacy mistakes, remember?
That is not a security or privacy issue
Again, this is not a security of privacy issue
Not a security or privacy issue….
You should not ONLY consider security and privacy without also considering features that make a huge impact on how you can use the service day-to-day.
It comes down to this:
If privacy guides dismisses the proposal to remove mailbox then there is nothing I can do about it and I will stop populating this thread.
But I really don’t understand this at all:
How can anyone read this thread with all its arguments and sources that prove that mailbox in its current state is a mess, that it had multiple vulnerabilities that showed they don’t understand security, that it lacks so many features and still say “Yep, this is the service I trust as the central access point to almost all of my online accounts and the central way of my online communication“
Uh, no? I know for shortness we’ve been calling them IMAP app passwords but they’re obviously also used for SMTP to send from the same email client, also you are obviously intended to be able to use them to organize mail. You have a fundamental misunderstanding if you think app passwords anywhere have ever been exclusively read-only.
They don’t store you PGP key in plain text on their servers. You are lying. I don’t read German but even if I take you at your word that your link says exactly what you claim it does, it is almost a decade old and predates Privacy Guides’ very existence and is clearly no longer relevant.
No? You can still use isolated app passwords, obviously. Having the option to continue using your normal password to gain access to your email in the event you are not willing or able to generate a new app password doesn’t hurt your use of app passwords elsewhere.
Why? Everyone has preferences, if the service works and otherwise meets the criteria I don’t see why it should be removed because someone wants a feature it doesn’t have. Not everyone needs or wants those features.
Probably because they are not you and have a different threat model where any concerns you raised are not an issue to them. Shockingly, people have different requirements of an email service, and mailbox still meets the criteria to be recommended by PG AFAIK so I am at a loss for why it would be removed because a few decided they don’t like it.
Here are the concerns you raised and hypothetical cases where it wouldn’t matter to someone, for explanatory purposes.
Inbound spam not flagged because of not strictly following a DMARC policy → You can just add your own sieve filter to move emails to junk when they don’t pass DKIM or SPF. This is probably the best thing to do even if DMARC was followed strictly as it doesn’t really help the issue of spoofed emails being received because you have no control over the DMARC policy of the spoofed sender and they might have it set to p=none, in which case you’d receive the email anyway if DMARC is being followed strictly.
Lock out via password reset from app password → If you only use custom domains and have an email backup system setup you don’t really need to care about losing access to your account because you can just point your domains to a new one. The only things to be concerned about are things that would already be possible with just the app password itself (reading emails, impersonation). If you don’t want to risk being locked out anyway, turn this off. Also, how is someone getting your app password before your normal password anyway? It’s also interesting your concern is getting locked out of your account, considering that’s what this feature prevents. This seems like a reasonable default for most people who would probably be more likely to be locked out by losing access to their second factor or primary password than by having an app password compromised. I would turn it off, personally, but I understand the trade offs they are contending with and why they ended up where they did.
I don’t see any other outstanding issues.
I’m not really a huge fan of mailbox, I really only like that they can do automatic encryption with a bring your own keys setup, but I think the arguments for removing it are really arbitrary and don’t seem to be for lack of meeting a minimum requirement or anything. My arguments in their defense are more about the precedent we set if we remove it for the reasons given, which again seem pretty arbitrary, even if I sympathize to some extent with default settings they have being undesirable to me personally (which I do, I just also understand why they set them that way and I don’t think their decision is entirely unreasonable).
If we want go change the minimum requirements, that seems more reasonable, but I don’t know that I would agree with what they would need to be to remove mailbox and I also still don’t love the idea of changing minimum requirements specifically so that a recommended service no longer meets them. Still, it would make more sense than removing them without those changes, IMO.
It is. 2FA is used to secure access using two factors. In this case knowledge and possession. Having only one of them is not sufficient to gain access. Mailboxes IMAP reset bypasses this by allowing to gain access only with knowledge. This is a flaw that could be exploited by attacker so a vulnerability.
Uh, no? I know for shortness we’ve been calling them IMAP app passwords but they’re obviously also used for SMTP to send from the same email client, also you are obviously intended to be able to use them to organize mail. You have a fundamental misunderstanding if you think app passwords anywhere have ever been exclusively read-only.
Yes I’ll give you that point. Technically speaking sending is done via SMTP and not IMAP but since in most cases its the same application password, you are correct that my sentence “ONLY there to read E-mails” is wrong.
So let me correct myself by saying “By definition it is not there to change account settings that allow gaining full control through bypassing enabled 2FA”.
it is relevant because it adds to the argument that they are careless regarding security.
And BTW: I did not lie. You asked me “What are the ‘dozens’ of mistakes Mailbox has made?” and I answered with a list of mistakes the made. This point above may be old, but its still one of the mistakes mailbox has made.
crazy to say its because some don’t like them. Like there isn’t a whole list of objective and proven arguments and its all just personal opinion…
And again: if privacyguides keeps recommending the service I can deal with it. I have nothing to gain by having mailbox removed. I just give my opinion and provide sources, because a recommendation should not be made/removed by personal opinions but based on facts. And IMHO the disadvantages of the service are bigger than its advantages.
Well, I disagree with a lot of what you said even in this post but in the interest of not spamming the thread and because it seems we’re both in the position where we disagree on some principles but don’t actually care too much about the outcome, I will leave it be so others can give their thoughts. Happy to discuss more in DMs and summarize here after if you want to just out of interest in the conversation, though.
It was a nice ride. Very compelling arguments and civilized (to a certain degree) discussion between two great thinkers and their opinions about a single email provider impression when both are, to some extension, detached from deep feelings about the tool in question. I’m honest impressed and appreciate this engagement.
In a nutshell: A backend issue left a paid mailbox account unusable for over a week. Support reacted too slowly, communicated poorly, and ultimately caused permanent data loss due to expired backups. Attempts to resolve the issue created further errors and erased support history.
When do we get more feedback from the privacy guides team?
The list of reasons to remove the service gets longer and longer. Its just a matter of time (and in the last months it happened quite a lot) until mailbox shows yet again that they have so many problems behind the curtain.
It looks like this issue has been fixed now (the problem discussed here: https://news.ycombinator.com/item?id=30224906). I was not able to send from my own domain on an account that is not part of a family or does not have an assigned email address in that domain.
SPF, DKIM, and DMARC can help, but the receiving server also needs to be configured correctly. Most servers will just mark emails as spam, but some (or if you self-host one) can reject spoofed emails.
For example, DMARC tells the recipient server what to do with emails when SPF or DKIM fail validation. (The test at dmarcian.com can guide you to set it to “reject” if you want full protection.) But this is only half the picture. For instance, Stalwart allows relaxed, strict, or disabled DMARC policies. A relaxed policy will only enforce rules if an email fails or passes, otherwise it just marks it as spam. A strict policy will reject anything that doesn’t pass verification.
So yes, you can tell the recipient server what to do with emails from your domain, but ultimately it depends on how that server is configured.