It's frustrating not being able to send email for my hobby projects even if I follow all the rules and have the correct headers. I enjoyed reading jeremyevan's post on self hosting email, but it's only for receive and not send https://code.jeremyevans.net/2021-07-29-running-my-own-email...
The Future of Email
111–120 of 217 posts
Re: The Future of Email
#112I love fastmail, I switched from Proton a couple years ago after deciding the trade offs to have encrypted email were not worth it, since even if I fully trust Proton, most emails come from or go to AWS, Outlook, or Gmail anyway. I have been extremely happy with the service. Fairly priced, very fast even with a huge inbox, and they don’t add unnecessary features or bloat. I thought I would use my OS’s mail apps but t…
I'm using Fastmail for more than 9 years. Especially since they added offline support to their app, there's nothing left why I would even remotely consider leaving them.
What about the fact it’s a US-based product so you’re under forced Five Eyes data collection?
Re: The Future of Email
#113I read this article and was surprised when I reached the end because the whole thing felt like it was setting the stage for some announcement or new thing. But nothing came..? Forgive me if I'm being thick but what was the takeaway?
Re: The Future of Email
#114Earlier quoted context omitted.
Those "message centers" aren't just about security, they're also about compliance. For example, insurance companies need to be HIPAA-compliant which requires that they can only send health-related info to other HIPAA-compliant systems, which means signing a BAA (a contract) with those other systems. There's no way to do that with email (your insurance company can't sign a contract with every potential email host in t…
Somehow they mail letters with info. Encrypted email wouldn’t require a BAA.
I'm not a lawyer, but I'm currently working on getting my company HIPAA-compliant, so I know more than the average person about this.
My understanding is that there's a thing called the "conduit exception" which basically says that if data is transiently passing through a channel and it's not being looked at, it's ok. But wherever the data lands must be HIPAA-compliant.
This seems crazy to me, but that's how it works I think. For example, if you encrypt PHI and store it in AWS without signing a BAA with them, that's a HIPAA violation, even though the data is encrypted and Amazon can't see it. But if you send encrypted data through AWS without actually storing it, that's fine.
Mail is specifically mentioned as a thing that qualifies for the conduit exception. I'm not totally clear why it isn't a HIPAA violation the moment it arrives at a destination (it's not in-transit at that point, and it's potentially not in the possession of the intended recipient either), but it seems pretty well accepted that it's not.
All that to say: I think encrypted email would still require a BAA because it's being stored, not just transmitted.
Re: The Future of Email
#115I love fastmail, I switched from Proton a couple years ago after deciding the trade offs to have encrypted email were not worth it, since even if I fully trust Proton, most emails come from or go to AWS, Outlook, or Gmail anyway. I have been extremely happy with the service. Fairly priced, very fast even with a huge inbox, and they don’t add unnecessary features or bloat. I thought I would use my OS’s mail apps but t…
What were the tradeoffs with Proton?
for me there were two:
no caldav support so I couldn't get my next appointment as a widget on my phone. Similarly, your contacts in proton are trapped there and cannot sync with any other system (such as your phone...)
limited quantity of aliases compared to fastmail. this is actually a really sticky feature with fm from what I've been seeing. I would have to rename a bunch of accounts or switch to using a catchall to transfer out.
Re: The Future of Email
#116Earlier quoted context omitted.
Those "message centers" aren't just about security, they're also about compliance. For example, insurance companies need to be HIPAA-compliant which requires that they can only send health-related info to other HIPAA-compliant systems, which means signing a BAA (a contract) with those other systems. There's no way to do that with email (your insurance company can't sign a contract with every potential email host in t…
Somehow they mail letters with info. Encrypted email wouldn’t require a BAA.
It's a crime to open someone else's mail and generally speaking the post office does a pretty good job of reliable delivery. Even if an address is a bit wrong/corrupted, it can likely be delivered just from the name and the zipcode.
Email is a lot harder. The older SMTP standard sends emails unencrypted so there's a possibility of a MITM reading the email. But also addresses if you get them wrong can end up in the wrong hands. For example, if someone sends an email to cogman10, I'll get it, but if they go to cogman1O I won't get it. A lot of the nuance of how secure and when it's secure gets erased by auditors to just "email is insecure".
Re: The Future of Email
#117What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform. I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through genera…
> They're widely understood
I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.
They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.
To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.
If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.
Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.
A shockingly high number of companies have no idea of the concept of the envelope address.
Re: The Future of Email
#118Earlier quoted context omitted.
Somehow they mail letters with info. Encrypted email wouldn’t require a BAA.
I'm not a lawyer, but I'm currently working on getting my company HIPAA-compliant, so I know more than the average person about this. My understanding is that there's a thing called the "conduit exception" which basically says that if data is transiently passing through a channel and it's not being looked at, it's ok. But wherever the data lands must be HIPAA-compliant. This seems crazy to me, but that's how it works…
Honestly, I think it's just because it's a crime to open someone else's mail. For whatever reason that sort of policy isn't extended to encrypted data in the cloud.
It was a law written in the 90s, it should be updated and modernized.
Re: The Future of Email
#119Everybody who has a Fastmail e-mail in their profile here on HN has received several targeted phishing mails with senders who are registered with @fastmail accounts that sound official. And Fastmail doesn't seem to do much about it.
It's absolutely the worst part of using Fastmail, that they don't clean up in their own house.
Re: The Future of Email
#120pgp exists, sheesh