Felz

You're not adjusting for inflation, which they are. Still, I have no idea where they're getting their numbers, which seem comically wrong.

Accounting for inflation, house prices have soared by 118% since 1965, despite the fact that income has only increased by 15%.

They use the median for that, which seems to have actually increased by 60%:

https://web.stanford.edu/class/polisci120a/immigration/Media...

I'm not sure why nobody else seems to have brought this up- it's a serious flaw in the article.

It sounds like a more realistic motivation for that would be to reduce the risk of failure- if the primary team flubbed the project, the secondary team would still be an option. (Such a system would also give you an opportunity to judge how effective either team was.)

Awful thing to do to engineers, but you can understand why management would do it and why they wouldn't want to demoralize the secondary team by telling them.

Just me- check the about page. (It is registered as a company too.)

They are still useful. One of DKIM or SPF is required to send emails on a custom domain. Both are recommended.

https://purelymail.com/docs/companyPolicy#bus

Also, I generally don't stop the service for maintenance, unless I need to upgrade the database engine.

Yes.

Yea, this to an extent. Honestly I thought people wouldn't need more than $50 too, maybe I was wrong there.

Rate limits, feedback loops, and we scan outgoing mail through SpamAssassin. In practice we've only had password breaches causing spam, nothing intentional.

Long run it'd probably get deprecated, short to medium run it'd be fine: https://purelymail.com/docs/companyPolicy#bus

1. I don't know if it's the social media kiss of death at work, but I'm getting lots of SSL errors trying to load your site. It's a crap-shoot whether it works or not right now.

Hard to say for sure. None of the servers really went above 15% average CPU and I don't think they maxed out net, and the health checker for HTTPS didn't have any problems. I'll doublecheck.

On the subject of migration, I'll make a note to add a FAQ for that, thanks.

Hm, no idea what would've gone wrong in your case. It sounds like something kept closing the websocket used to provide page interactivity or something?

For the trial hashwall, the browser just does some heavy computations. I guess I should add a warning there, it's probably does have battery impact if you're using a phone for whatever reason.

I'll make a note on the UI elements. Honestly hadn't thought about the punycode usecase, good catch.

That's partly intentional! Hopefully it scares away the users who expect perfection, and they can be better handled by a glossier service.

(Also I'm just genuinely mediocre at design, and kind of personally prefer less frills anyway.)

The E2E will help so long as you're sending email to other users of the same service, yeah. For most cases, it's probably not a huge upgrade from stored encrypted; the bulk of damage in email leaks would be from accumulated emails from the past.

The reason I don't recommend using it if you're super paranoid is because it'd be easy to mess up, and it comes with quite significant holes- e.g. subjects aren't E2E in Protonmail. Best to use a protocol designed for E2E from the ground up.

https://protonmail.com/support/knowledge-base/does-protonmai...

No, but I will. Thanks for giving me a term to research!

Marketing emails are actually against the terms of service, although there are grey areas- like a user personally reaches out to offer people a service, and some occasionally end up marked as spam. If the rate is low enough, it might be acceptable.

I'll make a note to make that language stronger.

Yea, they say as much in the data privacy FAQ. I think my recommendation is that if you're worried about being explicitly targeted by state actors, don't use email. (Not even Protonmail.)

If you're worried about general data hoovering, AWS would probably need to implement very sophisticated introspection into what your machines are doing to break the SSL on SMTPS, and courts might not be sympathetic to that. I expect state actors would find it easier and more convenient to just hoover from big providers like Gmail instead.

You can have as many domains/users as you want. (Unless it's like five billion and breaks the service or something.)

Generally phone access is third party through IMAP. On Android I personally use K-9 mail, but you can use anything that supports IMAP anywhere, which is a pretty good number of options for any platform.

Yea, I do plan on adding in JMAP. It's so much nicer than IMAP, I really do hope it can overcome the adoption hump.

Cool! I'll make a note of it on my task list (I think I still have the old task on there too, which is nothing against SaaShub, I was preoccupied).

Depends on what you mean. Inbound email is checked for authentication (SPF, DKIM, DMARC, etc) as part of the spam filter. For outbound email, we ask you to set up at least one of SPF or DKIM before you can send.

Sum total of my marketing efforts: One time I mentioned it in HN comments on a post about Fastmail, mostly because I was going to make a comment about owning your own email domain anyway.

I am usually the classic "engineer who neglects marketing" archetype. Maybe at some point I'll overcome that.

Yes, we have catchalls. We don't restrict how you route anything under your domain, and you can send from any email address you own.

We do have CardDAV support, and hope to develop CalDAV soon :)

In general yes I do contribute to open source, although there's not too much to contribute back to open source _yet_, so the main contribution has just filing Roundcube bugs. (The main mailserver code has diverged too much from Apache James to really be useful.)

Some of the libraries I wrote are open sourced and on my Github account, e.g. the web framework: https://github.com/ScottPeterJohnson/shade

I think SpamAssassin (plus curated greylisting) does a decent job most of the time, although I'm starting to see weird issues with spurious DNSWL tests that pass through pretty spammy mail.

In the long run I'm probably going to replace the Bayesian part of SpamAssassin with something custom, simply because operationally it's painful and I think neural nets are closer to state of the art.

1. Basically what nine_k said. It's kind of a trivial point most of the time- honestly might be a bit overpriced right now.

2. Not at the moment- IPV6 support is a little dicier for mailservers because the scarcer IPV4 address is often used as a antispam signal.

I actually haven't had huge problems with Google (yet). I'm not sure why.

Hash-based proof of work: https://github.com/ScottPeterJohnson/hashwall

Same idea as: https://en.wikipedia.org/wiki/Hashcash

Similar idea to cryptocurrencies.

I actually get asked about this semi-frequently. Probably nobody could replace me as a _developer_ on Purelymail, but I've been training my brother to handle extended maintenance and to have handover credentials if anything happens to me personally. (This might be in the FAQ?)