I was just about to ask about this and see you mentioned it earlier here. Are you still thinking about doing this?
And on the paid plans, your automatic PGP encryption only works with email mailboxes you store, and not for forwarding aliases right?
1 Like
As mentioned in this comment we have been evaluating design approaches to support this. After much consideration, our approach is tentatively going to re-use our existing encryption and decryption helper methods and allow you to convert jonah@domain.com to an encrypted hex string, such as 1b92ca5176ba3cd8-d800d486bf5bcac5c01a23b97d3151f9 (behind a logged in page of our website to prevent bot abuse). Then instead of forward-email=jonah@domain.com you would put forward-email-encrypted=1b92ca5176ba3cd8-d800d486bf5bcac5c01a23b97d3151f9.
Another thought we had was to use a public PGP key, e.g. one for support@forwardemail.net to use the openpgp library to encrypt and then encode in base64 a forwarding configuration, e.g. forward-email=jonah@domain.com. However the problem with that is the encoding from armor to base64 results in quite a lengthy string. Some DNS providers such as AWS Route 53 limit you to 255 max characters for TXT entry, and then that requires you to split it up with spaces, quotes, and it becomes a mess. Itās hard to use, not easy to debug, and a pain to maintain (often much more of a pain than simply upgrading to our $3/mo plan). The only plus side of having base64 is that we could use the validator.js library, e.g. validator.isBase64(str) and not force you to use forward-email-encryption= prefix, and instead just use forward-email=somelengthybase64string.
This is trivial to publish the page/tool to allow you to do this, and it is also trivial to integrate it into the forwarding backend, however there are a lot of edge cases (e.g. we have a feature that lets you import plaintext TXT forwarding configurations if you happen to upgrade, weād need to update our docs in the FAQ to mention this, and so many more edge cases). Weāre trying to wrap up CalDAV (calendar) issues/TODOās right now, so hopefully by the end of this week we could look into making this happen.
At the end of the day, weāre still the only provider that is 100% open-source and offer standard SMTP, IMAP, POP3, and CalDAV. Nobody else comes even close to this. Others (like Proton, Skiff, and Tuta) all advertise as open-source, but their back-ends are completely closed-source. That alone should have us included in this list along with the fact that we already have 430,000+ domains on our service (which no other service on PG comes close to).
2 Likes
Oh I quoted the wrong comment. My second question was actually supposed to be: Do you have plans to support automatic PGP encryption of forwarded emails? Like you receive an email, encrypt it with the personās public key, and then forward it to their mailbox. (Nothing to do with the TXT records)
It looks like you only support automatic incoming PGP encryption for mailboxes you host, unless Iām missing something. Just want to confirm that is indeed the case.
Correct. We donāt modify messages that are forwarded right now as any modification of the body could break DKIM signatures and cause messages to fail DMARC and DKIM alignment. It is on our roadmap to explore this in the future, but as of now the only encryption done is if you have uploaded your public key and the message is not already encrypted when it is attempted to be stored in your IMAP mailbox, then we will encrypt it for you with your provided key.
2 Likes
@forwardemail this might be a dumb question but I canāt find the answer on your site after searching for a bit. Where are you located? The only hint I found was the governing law section of your terms of service.
We are a 
US-based company as youāve already discovered and mentioned above:
Hey and hereās my honest experience so far with forwardemail (1 week user).
So Iāve been with tutanota for quite a while (on the grandfathered 1 eur plan, still active today), but last year decided to search for alternatives (they, rightfully so probably, decided not to give/include any other development improvements/perks to these former premium accounts, such as not counting attached domain aliases in the included 5). This, plus the refusal to include/show at least the sender in the android email app before opening the app, made me searching for alternatives.
Proton was too expensive for me, so naturally there came skiff. We all know how that ended, so I kept searching.
Looked into migado, which for my needs was enough with the smallest plan, but found out there was no encryption at rest. Then I was about to settle for mailbox, but read somewhere here that they use the account password for imap login, which made it a no go for me.
So I came across forwardemail. Found this thread actually. So I liked what I read.
Signed up with them but since I long had any interaction with imap clients, I forgot and I unknowngly reached the limit of 30 connections in my betterbird and fairemail clients (had multiple folders).
I angrily (I guess) contacted support, arguing that their service doesnāt even cover basic email like imap, and that I am unable to use my email and that I probably want a refund. I was quickly replied that I will be doubled my connection limits. In hindsight I really didnāt need this, I simply edited the folders in fairemail to poll instead of sync (except for inbox).
I also setup my pgp with my domains, so everything seems sleek so far, and support has been great. They seem to actively develop/introduce things, now working on caldav.
Found one visual bug on the web panel (ugly looking page when a long regex was used), which was fixed the same hour I reported it.
Found another bug with the passkey login not working at my end (when using yubikey) which I reported yesterday. I donāt know if itās actually a bug, or if I do something wrong 
This has been my experience, I really like the active involvement and quick support.
I give them a thumb up so far, and will stick around as their customer
3 Likes
Could you perhaps describe the UI or share screenshot of it ?
As for the UI, what you see in their website pages is what you get in your web account.
Nothing fancy and sleek like say skiff have/had, but at least a clean interface. Could use a future revamp, for sure.
What I also appreciate is that they added the api integration with Bitwarden (I use selfhosted vaultwarden and it works also) and I can create randon aliases on the fly in the extension directly. Pretty nice.
3 Likes
I suggest setting up your own BTCPay server and not pay to fees to privacy invasive services like BitPay and Coinpayments. A lot of services use it like IVPN etc, really great and it is open source.
These are the coins they support:
1 Like
Also you should setup monero as well
1 Like
@Outfield7070 thank you for the screenshot. Do you still use Forward ?
For the later comments, letās talk about crytpo in another thread
Unfortunately no, Iāve decided to cancel my account and was quickly refunded.
Even though it ticks most of the boxes, it felt (imho) not ready for the prime time.
Maybe I came at the wrong time (they were actively updating things, so basic email via betterbird and fairemail had a lot of hiccups in the imap department), so I am no longer a client of forwardemail.
It is really promising and I may retest it in the future, also I need to take my hat off to the amazing support both on email and on matrix.
Iāve gone back to my good olā tutanota premium + duckduckgo bitwarden aliases. Basic email needs without issues.
Off topic, but Iām wondering if forward mail has concerns about big tech stealing your code, offering it as a SaaS, and not contributing back (perfectly legal technically). I.E. Amazon hosting ElasticSearch (ES), ES unhappy about that fact and switches to AGPL, then Amazon forks and maintains their own version now. Might be a loss if big tech decides to take off with your work.
No response needed, I just donāt want to see the work on an open source project be digested into big tech and become fragmented.
1 Like
if that was a concern, why not go agpl from the start? but i guess it achieves similar things to this business source license. the main difference is that it is considered an oss license while bsl isnāt
Iād also agree - AGPL might make the most sense to prevent random companies from not contributing back.
Iām not sure how what to make of this answer in the FAQ:
Will you ever increase prices?
No. Prices will never increase. Unlike other companies, we will never shutdown our service either.
Although itās appealing, the use of the word āneverā-- in both sentences-- seems surprising. What techniques could they use to maintain the company, service and pricing in perpetuity? It might help to elaborate on these techniques in the FAQ.
Or maybe the second sentence is very carefully worded about who will not shutdown the service?
I donāt know the median lifespan of a technology service provider, but it would be interesting to know how it will outlive us all.
Under what conditions would you believe these two sentences in the FAQ?
A. The FAQ were to outline a multi-decade business plan showing prices fixed and service continuing indefinitely
B. The founding documents of the company were to enshrine a requirement for any future acquisitions to maintain the service (at current pricing)
C. Never
2 Likes
Itās unrealistic for any service to maintain the same price over an extended period of time due to inflation. I think a better response to this in the FAQ would not simply contain blanket statements about the serviceās future price and ownership. The response should be updated to show proof that future prices will remain the same adjusted for inflation and that the company will not be acquired/merged. Ideally, this would be in the form of legally binding agreements that are enforceable by judicial precedent. Otherwise, the FAQ should be edited to clarify the lack of evidence behind the response.
2 Likes
Mullvad has demonstrated that a company can keep its pricing the same even for an extended period of time, as it hasnāt changed its pricing since its launch in 2009.
3 Likes
Right, but never covers a time period far longer than 15 years, which is the point I think weāre trying to get across. To be fair, a track record like that in the case of Mullvad is something a company can and should advertise, itās just blanket statements like āneverā which undermine their credibility. I think it would be far more productive to advertise such a background if they have one (I havenāt looked into them super closely) and detail their plans in case something does happen. In the case of Forward Email, their core product being based on bringing your own domain helps a lot as you already have that in place to simply point to another email provider if they shut down or increase their prices beyond what you can afford.
3 Likes