Hi @forwardemail , thanks for providing this much information and quickly addressing the concerns. I didn’t know about your e-mail services until recently. I have created an account and started using it, and I must say I really like it. IMHO, it’s much better than mailbox.org.
I have a couple of concerns that I would like to bring to your attention:
SMTP submission is by default disabled. You claim to be a full-fledged e-mail provider, and not just an e-mail forwarding service, however, this approach does more bad than good in making people believe that you’re not just an e-mail forwarding service. However, I do understand why it’s important for you and people who use your service to have reputable IP addresses for e-mail deliverability.
The fact that SMTP submission is disabled by default is not mentioned anywhere that can be easily seen before/during the registration process. I only found out about it when I tried to send an e-mail, and the server threw an error about it. Maybe you could be more open/transparent about this BEFORE or DURING people make an account and pay?
I have uploaded my openpgp public key to your service for an e-mail alias of my domain, and activated the option for encrypting incoming e-mails using that public key. It works very well. However, that e-mail alias also forwards incoming e-mails to another e-mail address, and those forwarded e-mails are not encrypted using my public key. Is this by design? IT would make much more sense if you can also encrypt those forwarded e-mails, too.
Thanks a lot for providing such a great quality service at an affordable price!
Hi there @arandomduck - apologies for the unexpected delay in our reply.
We have plans to automate this (e.g. if the domain has an A record and working website or if previous domains added by the same user have been approved – then auto-approve). It is noted on all necessary pages that we do a manual review process. Typically we approve in 2-4 hours during the week or quicker (usually within 30 minutes). On the weekends it might take a bit longer, but we will grow over time to expedite this to be as near instant as possible. We’re focused on the most pressing/urgent/priority items right now, and any time a SMTP approval request comes through it is marked priority by default for our support team. Here is an example section where we state there’s an approval process: https://forwardemail.net/en/guides/send-email-with-custom-domain-smtp#smtp-instructions:~:text=Important%3A%20Please%20note,get%20marked%20as%20spam.
Yes! Forwarding will have OpenPGP/WKD support soon, we’re in the midst of consolidating some code (re-using the same functions for outbound SMTP/MX) so this should happen very soon this year. Most likely within the next month. The code for that is actually already completed! We have a few other things to do before we can confidently deploy this.
Appreciate your kind words, and we’re here to help if you need anything. Feel free to join our Matrix channel and directly DM / @ mention us there too for faster responses.
The other big issue is one that has been brought up multiple times, and that’s how emails are stored into the persistent database for the recipient mailbox. The IMAP password is encrypted in memory and not stored, but it is decrypted several times (using the exact same key from above it seems) meaning an admin is able to access the full mailbox as long as a session is active (+ the temporary mailbox as mentioned in the previous part.)
Both of these issues can be resolved by manually setting up a public key, but by default a mailbox cannot be considered secure.
There were several other areas in the code that looked like they could be a problem, but I do not want to make accusations I cannot back up without investing tens of hours of my free time. Especially when that first look told me I should stay away unless I want to trust the other parts are miraculously perfectly fine.
That said, I still can’t help but think it’s a shame because the value proposition is great. But the pushy (seemingly solo) team and the dangerously below average code quality are a bad sign that should prevent the inclusion on this site.
(Only tangentially related is also the fact that the author has tried surprisingly hard to remove their previous alias for some reason, only thing I could really find there is that they made an app called spontaneous at some point Spontaneous - Hangout with Friends & Family Nearby)
@mountainofmeat well, as with everything, this is no black&white type of thing…
Its not that whole codebase is bad. Not at all. There are some places where code is, maybe not excellent, but good quality. Although I agree, some 85% of code is just well below, not even average, its well below acceptance of any serious project.
Believe me, there are places in codebase, that, quite literally, ask for DDoS, MiTM or similar. Its so bad.
Dont get me wrong: I fully understand and support the idea behind such service. Its just the code quality that speaks volumes.
Your first look was perfectly right: this code is basically dangerous for production use.
As I said earlier: I clearly see what this project try to accomplish.
Exactly this. May I add that, by including FE within PG’s proposals, it will be PG that is at loss. Not FE.
======
Just a fun fact: Ive followed link from your post and see what Ive found oh man, thats ridicoulous…
Code quality isn’t a hard determinate if a product is bad. Programmers could spend endless time making “good” code and never get anything useful done. The only code quality that really matters is if they correctly implement cryptographically secure and privacy respecting code. The rest is just part of the usual SDLC.
Yeah I’m not making a big fuss about bad UX or something, I am concerned about the general security practices of this project as they seem subpar at best.
As mentioned previously there’s multiple parts of the code (besides the ones I explicitly mentioned while talking about mailboxes) that seem sketchy and like they could be abused by an attacker, but I didn’t go into that because I do not want to make claims I can’t back up easily.
I haven’t looked at the codebase to validate that claim. I’m not equipped too either. I’d have to wait for an audit to come to truly have confidence in their E2EE, so our general sentiment is in alignment.
I looked at a couple of the endpoints, but mostly focusing on how mailboxes work. They seem to work as I described, with a single encryption key shared across the entire server, which is also used to encrypt your IMAP(?) password in memory, which in turn is used to access your database. It is decrypted on the server side, so while you are connected it is technically possible to read all of your emails. I am not sure what best practice is for emails, but I would have assumed that you would want to derive a key or only keep a hash around (but I’m neither a security professional nor do I maintain an email service).
Some areas also looked like they might not be sanitized right but to make sure I’d have to look at all the libraries they maintain in addition to forwardemail.
As said, tens of hours of effort when that initial look was good enough to convince me it’s dangerous.
Ideally you want every piece of data that is transmitted out of mailserver to be encrypted (encryption in transit) as well as when you’re not logged in (at rest).
Sorry, you’re right. They do offer encrypting inbound individual messages with PGP if you set it up. Them saying they offer E2EE is a bit of a stretch IMO since you need to bring your own pgp capable client and manage your own keys but oh well. I guess they technically offer it.
The design we were talking about with sqlite etc, is for at rest encryption. So I assumed that was what you were talking about. What isn’t properly implemented about the optional pgp encryption of the message itself?
No, they do not. Implementing half-baked feature does not entitles you to say you offer it.
So, all they do is they tell lies. Say whatever, this is what it is sadly.
If I was them, I wouldn’t claim to offer it either tbh. I would think it’s better to be clear and say their main feature set is at rest encryption, just because it gets confusing otherwise. But then, I’m not in marketing for a good reason.
I’m pretty sure the pgp support at mailbox.org works in the same way, doesn’t it? It’s just that they also have a client that supports it, while forwardemail is offering a clientless solution.
oh man, thats ridicoulous…