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.
No, the work of all teams except the pre-selected real one was discarded and never passed on for evaluation. If you wanted to do it for real you would do it up front and ask them all to try different approaches and have rendevous points to compare and evaluate and exchange findings. I suspect that would be much better morale for all teams involved, but would require management to give up on their "chosen" team, and put some real effort into this, which they were not willing to do (and before you ask, yes, the "backup" team suggested this and got rejected, and then got the fuck out)
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 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?)
And of course it would be even more crazy for them to refuse a request e.g. by the FBI or NSA. I'm sure they respect SLAs as much as OnePlus, Huawei & co don't share data with Chinese government.
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.
> 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.)
Protonmail (and Tutanota, which I went with) both offer E2E encrypted email via open-source client apps, so they should be fine even against state actors if you use their encryption. In the case of Tutanota, this has even been tested in court.
Of course, if you use them to send or receive plain ol' unencrypted email, this largely goes out of the window regardless of the provider.
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.
Tutanota went with a different tradeoff so they have E2E encryption of subject lines etc. Downside is that they can't support other clients, which is why I wouldn't have even considered them if the apps hadn't been open source.
They also have a pseudo-workaround for using E2E with external users - if I send a secure message to foo@bar.com, I can encrypt it with a pre-shared password and their mail will get a link to a web "mailbox" where they can enter that password to decrypt the message. Clunky, but I wouldn't know how to do better.
I personally feel that calling Proton Mail or Tutanota end-to-end encrypted is sort of misleading. Sure, they may have the contents of your mailbox encrypted but in transit they can see your email in plain text and so can the recipient's mail server. If you desire E2EE I highly recommend using GPG or Signal.
I don't know about the Protonmail UX, but the Tutanota apps at least make it very clear when sending an email whether you're using E2E or just plain unencrypted mail. (If you leave it on E2E and try to email a non-Tutanota account, it will ask you for a pre-shared password with which to encrypt the message.)
Great work, and as somebody who self hosted my own email from 2013 to 2021, I don’t envy you. What broke me down was Google starting to spam my emails that were replies to conversations that I did not start — even with a stellar domain reputation and DKIM, SPF, reverse DNS, greylisting, everything set up right.
I hope you have personal contacts on the Gmail team at Google, much as I’d like for this to be a joke.
I had this exact same problem. When I finally got hold of someone who worked for Google (via a friend of a friend on a mailing list) and with the ability to check whatever their logs were claiming, I was informed that my domain's reputation was "too recent" or something like that.
My domain is a year older than Google itself and has been in continuous use for e-mail that whole time. The IP addresses it is on haven't changed in a decade. But that didn't matter. DKIM, SPF, DMARC, forward and reverse matching DNS, exactly four users who do not send spam under penalty of being buried under legal solicitations for green cards, and all the rest didn't help. Randomly getting sent to /dev/null for no good reason. And not enough traffic to qualify me to use their Postmaster utilities.
Three years ago I gave up and ported to Fastmail with a tear in my eye for the days when even the smallest net on the Internet could be a full participant.
Same here - I HAD to move over to Fastmail because like GP I'd respond to email enquiries from GMail addresses and then never hear back. After weeks of this, someone finally phoned up to complain about my poor customer service. This despite also having an old and apparently well set-up domain.
I lost a lot of business back then. Thanks, Google.
I have a legacy GSuite account. Google filters email from Facebook and Microsoft sometimes. Hell, I think I might have even seen them filter their own mail once.
It’s a clown show. The opaque filters are just an excuse to engage in anti-competitive behavior IMO.
To be fair Facebook used to send an enormous amount of spam emails, at least to me. Years ago when I used it somewhat regularly they used to constantly shuffle their contact preferences and the effect was that I was constantly opted back in to an insane amount of emails. Eventually I just started marking them as spam until Gmail blocked everything they send. I've seen family Email addresses fairly recently full of Facebook junk too so I assume they still default to sending a lot.
I really enjoyed the whole process of running my own mail setups, configuring Postfix or OpenSMTPd to do clever aliases and transports, setting up CARP failover relays, managing DNS records, experimenting with different SPAM-filtering techniques, SSL, IMAP, mailing lists, the works. It taught me a lot about networking and security and everything a good sysadmin should know.
I find it sad that that‘s pretty much a waste of time now for most use cases.
FTR, directed at those who valiantly continue to self-host mail/SMTP: Greylisting is not sound any more in this day and age, because the largest mail services will rarely, if ever, use the same MTA instance to retry delivery upon a soft bounce.
The good news is that if you have postfix, using postscreen with an informed choice of blocklists is enough to deal with 99%+ of inbound spam. You can strap in rspamd or spamassassin/amavis behind that, but it's mostly not needed.
The inbound-mail-problems are largely solved, but surefire delivery to other parties is a matter of IPaddr/domain reputation, properly implementing relevant standards, and luck.
If you're interested in learning more about (including, but not limited to, self-hosting) email, the #email channel on the libera.chat IRC network is a great resource to ask questions.
> FTR, directed at those who valiantly continue to self-host mail/SMTP: Greylisting is not sound any more in this day and age, because the largest mail services will rarely, if ever, use the same MTA instance to retry delivery upon a soft bounce.
I had this issue with SendGrid years ago: long story short, after discussing with support and eventually an engineer it turns out they weren't just looking at the status codes, but at the status messages. I don't recall the exact patterns they used, but they will retry if the message matches a fixed set patterns, and otherwise it would just discard it.
There was some back-and-forth over this, because our customer just had greylisting with the "wrong" error message. To be fair, they did turn it off for a few hours and took the conversation serious (none of this "we have passed it along", never to be heard from again) but they got back to us they turned it back on again "because the queues got too large". I mean .... okay.... Seems rather curious to break a fundamental aspect of email because "muh queues". Not having to worry about this sort of stuff is exactly why we're using SendGrid in the first place :-/
My experiences with MailGun were also not exactly stellar. At the time at least, these people literally did not understand how encodings worked and would mangle e.g. Greek or Hebrew emails in ISO-8869-7 or -8. Why? Well, turns out that "emails should be in ASCII or UTF-8 and there is no way for us to know which encoding is used". Ehh ... there is literally a header telling you... I sent a nice detailed email explaining this: no reply. Some follow-ups over the course of a few weeks: no reply. A not-so-nice snarky email inquiring whether the entire MailGun team was suffering from a horrible debilitating disease and if there was anything I could do to help: "well, we just didn't know what else to do as there is no way to solve this"...
I'm hardly an "email purist"; I understand there are practical concerns and the RFC isn't a stone tablet from the mountain. But this was just ridiculous. There are a bunch of other cases both SendGrid and MailGun are actually quite bad at.
Dealing with email providers is always a frustrating experience.
> All or part of the IP address of the SMTP client can be optionally ignored by DCC clients as far as the greylist triple is concerned. This feature may be useful for legitimate mail systems that shuffle messages among SMTP clients between retransmissions. See the dccm and dccd man pages.
It doesn't quite sound like it does a job of 100% "same email, same sender, different mx in same domain" -but I suspect it works well enough in practice?
> Usually the DCC greylist system requires that an almost identical copy of the message be retransmitted during the embargo. If weak-body is present, any message with the same triple of sender IP address, sender mail address, and target mail address ends the em-bargo, even if the body of the message differs.
> If weak-IP is present, all mail from an SMTP client at an IP address is accept after any message from the same IP address has been ac-cepted.
I can't recall what I used for greylisting last -possibly greylistd.
Anyway, the smart play these days might be to whitelist/greylist via SPF - I'm not sure if spammers (of the variant caught by greylists) generally have SPF?
My experience has been cyclical, as long as you stick to IPv4 with good SPF and your reverse DNS works it will work 95% of the time. The remaining 5% appears to be completely random however.
It’s possible that my issue was too low a traffic to ‘hold onto’ my score with Gmail, since it was one domain and one email address. With some luck you should be able to have enough traffic to avoid that. Best of luck.
> To activate a trial account, you will need a reasonably modern browser and a phone number that can receive SMS texts.
It makes no mention of the use of a "hashwall" ... It gives no indication of what the user's browser is going to do ... Just a progress meter with a note saying it will take about 3 minutes.
This feels fishy. Especially if a user doesn't know how to get into the developer console, find out what's running etc.
Just completed my signup. I am going to check if the domain that failed to work with forwardemail.net[1] will work with your service.
If it does, then I'll say goodbye to my $36 and hello to your service.
Update: While setting up, I noticed:
- Ownership record content in `code.codebox` does not fit in the content area and extends entirely too far to the right. I had to inspect and copy out of developer tools.
- In general, UI elements seem not properly aligned, contained.
These are not deal breakers to me. The site might actually benefit from going more old school. Trying to fit everything in a narrow box with large font sizes and padding is hard.
Update: I had already clicked on CloudFlare instructions. It's the friendly stuff that has the problems I mention above. The actual information at the bottom of the page is actually displayed the way I would have expected.
Update: After creating the DNS records, I noticed the checks were still failing. So, I replaced the actual IDN in the textbox with punycode and the DNS checks worked. It would be a better user experience if the punycode conversion step was handled by the UI.
Update: Created a new user on the custom domain. Login box does not accept IDN either but the email composer does show the from address using IDN instead of punycode.
Update: I was able to exchange email with a Gmail user. Did not go to SPAM. But, in my reply, Gmail did give a scary warning about the IDN. To be clear, there is nothing the email provider can do about that :-)
I'll try out a few more custom domains and very, very likely switch. Thank you and good luck.
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.
> For the trial hashwall, the browser just does some heavy computations.
Yeah, I figured that out, but someone else might think you are trying mine some *coin or something. I am not sure if I would mind it if you did, but it would be good to tell up front what you are doing. It does seem to be a much better than recaptcha.
The fact that it works is good enough for me. I am going fiddle a little more before I sign up, but it looks like this is fills my needs.
I clicked for a trial... after a while I entered my phone, received an SMS, and no indication of what to do with the code I received. No place to enter the code in the web page, nothing.
Second attempt, and I got a place to put the code. Then, while I was filling up the registration data, the page refreshed and started all over.
Third attempt finally worked...
Not the best on-boarding experience, but hey it really is cheap!
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?
I'm sorry if I missed it, but do you do catchall email service for custom domains? My current email provider (https://mailbox.org) limits email aliases per price plan, the most basic that I currently use allows for 3 + a free root@ and webmaster@. I'd probably be convinced to go through the hassle and switch providers if your service provides an improvement over this limit.
Thats good to know. Apparently my current provider allows for those as well, but honestly the proposal "just email, nothing else" might be attractive enough to try your service anyways.
You can use x3 domains with catch-all. Just add each one as "@domain.tld" and setup mx/spf/dkim/dmarc as usual. Then the domain will receive with catch-all. However, prepare to be spammed, as many spammers figure that "mail@domain.tld" are always available, so that one will frequently receive spams.
If you need more than three domains, try Migadu(not affiliated, just happy customer), they have no formal limits to their "micro" plan and is cheaper than FastMail. Migadu also allows adding alias domains(something I haven't seen anywhere), basically if you have a mailbox like "merlinscholz@domain.tld" you can attach some more domains as alias, like "@domain2.tld" "@domainx.tld" and those will all receive/send/operate as the same "merlinscholz@domain.tld". Neat feature I haven't found yet on other services.
Same price for 2GB + Custom Domain + 3 sending Aliases + Catchall + Contacts and Calender Sync + Web Client + hosting in Germany for the old Mailbox.org plan is still the better offfering for me privately as I regularily clean up my Mail + like having calender and contacts integrated.
But 10€/ month for unlimited storage and users is definitely a good offer, too.
I just want to thanks for the service, I just need email for my personal stuffs and after hassles with self-hosted solution I gave up. The pricing is on point, I'm relying on the free Protonmail and their asking price is too high to me so I signed up for purelymail.
I have a local maildir[1] account in Evolution. Each of my (IMAP) mail accounts is set so the "archive" command moves the message to a folder under the maildir account (if you're using Evolution, this can be configured under "Defaults" in the account properties for each IMAP account). Anything worth keeping from any of my IMAP mail accounts is archived to the local maildir, everything else is deleted.
The local maildir account is searchable like any other mailbox (I have about 10,000 messages going back to 2003). Syncthing[2] is configured to sync the maildir directory for backup and sync.
I keep everything remote, so that every client gets the whole corpus. For now, that means that indexing is done with notmuch whose command line I use for search... Not as good as a webmail's UI but it puts search results as a maildir so I can open them from any IMAP client as a special folder.
Thunderbird has "local" accounts, you can move emails there and have them removed from your imap server. You can also export emails to .eml files, throw them wherever you like and grep for contents if you like.
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.)
Hey cool - glad to see James being used as well. Hopefully the JMAP support that Linagora have worked on will mean that you can bring JMAP eventually too.
I hope you don't find the pain of diverging from the mainline to be too great. We kind of cheated there with Fastmail and Cyrus IMAP by merging all our changes back to the mainline, since there wasn't much other development happening.
Awesome - do keep in touch while you're doing it. We have some documentation up at jmap.io but of course seeing the challenges that people face as they try to implement is always good for improving the documentation for the next round.
(We're also working on JMAP for calendars and for contacts over in the IETF working groups - hoping to publish Calendars by the end of this year)
Good job, Scott! This is Stan from SaaSHub. I'll be featuring Purelymail on next week's newsletter of SaaSHub. It's a good moment to verify the listing and improve the details.
I think Gmail really shines at this. It's one of the reason I was thinking of switching to Hey email also, though after reading Hey's reviews I've decided not to. So anyway, would love some comments from users or you about how good you are at separating the wheat from the chaff.
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.
What provisions are in place to prevent someone from opening an account, use it to spam and then putting your IP block on a shitlist with large email providers like Gmail?
Rate limits, feedback loops, and we scan outgoing mail through SpamAssassin. In practice we've only had password breaches causing spam, nothing intentional.
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.
2. Seeing this post, I posted this: https://news.ycombinator.com/item?id=27711124. If you don't already (did I miss it?) it might be worth tossing up a page or an item in your FAQ teaching people about how they can go about migrating their email address to another/your service. I don't know how easy/hard it is (hence my AskHN post), but the perception is that it's nigh impossible to do.
> 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.
>You cannot have more than $50 in credit at any time.
Just curious, why a $50 limit? I'm the weird kind of guy who likes to pay years in advance. If possible, please consider raising this limit to $100 or even $200.
One thing is not very clear: how many custom domains can I have? Can I use 30 domains with 2 users each (random number, but i do need 3 domains).
How is the mailbox on phone? My major problem with email hosting is the lack of a decent mailbox service that's available on. Windows, android, linux that's either. One-time-purchase or open source. A monthly fee is fine if for unlimited users (I have a family)
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.
I looked at your About, Security and Privacy pages. I see that you're using AWS, but which region/country/jurisdiction is that located in? Is it safe to presume that since the company is an LLC, the company as well as the AWS country are the U.S.?
Good luck with CalDAV - it's pretty hairy! I do recommend joining CalConnect if you have the budget for it - you get access to a lot of experts there. Or at least show up to the calsify mailing list at IETF, we're pretty friendly there too. The edge cases in Calendaring are a right pain.
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.
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.
Dan's work pushed the adoption of BCP38, segmentation of authoritative and recursive resolvers, and better source port randomization. Entirely new mitigations were developed like 0x20, source address randomization, and double response detection.
Additional mitigations started to come in to play after that to make it both impractical, detectable, and improbable. It's just shy of impossible now, and in the very unusual scenarios where it's possible, it's so easily detectable.
I've been using a reactive websockets over HTML in Kotlin implementation that I wrote myself, and it's been the least unpleasant web development experience I've ever had. There really is a huge advantage when you don't have to marshal/unmarshal/validate a request for a simple callback on a button, and page loads can be much faster.
That said, there is more operational complexity (though given my site is relatively small, not much yet). State that lives with the server dies with the server, so deployments can take longer if client sessions live for a while.
> 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.