Live data from Hacker News

Poste.io – Complete Mail Server

poste.io

201–210 of 247 posts

Re: Poste.io – Complete Mail Server

#201

Earlier quoted context omitted.

Their rationale is probably because those two don't scale very well when you want to make their efforts count, whether bcrypt's hunger for CPU or Argon2's hunger for CPU and/or RAM. Bcrypt is very capable at bogging things down when you have lots of users authenticating very frequently, which is often the case with a POP3 server. A mere 100 e-mail clients authenticating every 2 minutes on average to check for new mai…

I'm wondering, if pop/IMAP auth is so costly, why POP3/IMAP community not allow user to get session token and auth with it? Like JWT or anything with similar security properties. Both protocols are easily extensible...

It's only costly if the software (or its administrators) decides that it has to be. This particular product's approach (5000 rounds of salted SHA512) is not very costly, nor is it inherently insecure.

Re: Poste.io – Complete Mail Server

#202

I feel like this solution is optimizing the wrong problem. The bulk of work with managing a mail server (these days) isn't software setup and admin. On the receiving side, it's all the work dealing with abuse and attacks. On the sending side -- and this is the tough one -- it's getting sites to accept your email. When I finally gave up managing my own mail server (about two years ago), I found that about every six mo…

> These days I'm very happy to pay somebody else to run email services using my provided domains.

I was in a similar boat, though I bailed much longer ago than you. I think "Big Email" is happy to let enough spam flourish in the world so that it presents enough of an excuse to tighten the screws to make it effectively impossible to run your own server... just so that more and more mail goes through their servers to be mined for personal data. That's why I don't use Gmail any more, but it wouldn't shock me to find out that Apple is doing something with my email data too.

Re: Poste.io – Complete Mail Server

#203

Earlier quoted context omitted.

> The _real_ problem is reliably getting your 100% legit mail into your consenting recipients' inboxes It's amazing that having someone in your address book isn't enough in many cases. Like, why?

That would demand maintaining an address book. Most mails I receive are from services which I have never written to, and I don't see a reason to extra maintain their data when I already have their mails.

For sure. I’m contemplating a scenario I’ve had multiple times “No I didn’t get it” “Okay let me try again, did you check spam?” “Yeah” “Maybe add me to your address book” “Nope still nothing”

Re: Poste.io – Complete Mail Server

#205
post #179
post #56

Earlier quoted context omitted.

> Last year I moved my mail to an old fashioned shared webhosting account at Hetzner. Very happy with it! How exactly is that solving the problem? If anyone does something remotely spammy from that ip, your mails are spam again too. And you probably got lucky that the ip you're sitting on was warm and trusted to begin with. You didn't really find a solution, the problem simply hasn't occurred yet for you or you are n…

I think you misunderstand. You cannot have a mail service on shared webhosting. It’s like 1999: Upload PHP using FTP, the end. Instead, the hosting provider will operate a mail service for you, much like Microsoft 365, G Suite and the like. They will also take care of the IP reputation, SPF, DKIM and all.

Maybe they do, but I would be surprised seing managed email sending in Hetzner's portfolio as part of shared web hosting. It's just not what that company typically has to offer, that's why I expected they just provide you the infrastructure, but ip reputation and so on is your problem. Taking care of IP reputation and successful delivery is a massive undertaking, especially if you let customers send whatever they want.

However, I dunno why people only mention the cloud providers, while services like MailChimp, Sendgrid and others offer this for mass emails and companies like fastmail for personal users. The cloud isn't really necessary at all.

Re: Poste.io – Complete Mail Server

#206

I feel like this solution is optimizing the wrong problem. The bulk of work with managing a mail server (these days) isn't software setup and admin. On the receiving side, it's all the work dealing with abuse and attacks. On the sending side -- and this is the tough one -- it's getting sites to accept your email. When I finally gave up managing my own mail server (about two years ago), I found that about every six mo…

THIS. Spam is a solved problem, thanks to SPF and DKIM. But despite doing all the right things, Microsoft and Google continuously block and rate-limit delivery. Case in point: we deliver 20,000 booking confirmation emails every day, all requested by users and not spam. We have perfect Postmaster Tools metrics: absolutely zero reported spam, 100% IP reputation, high domain reputation, zero feedback loop spam, 100% enc…

Spam is one of the most difficult content classification challenges for the past 20+ years.

There are approaches that work well, on a small scale, but "solved" is a step too far.

Re: Poste.io – Complete Mail Server

#207

Earlier quoted context omitted.

THIS. Spam is a solved problem, thanks to SPF and DKIM. But despite doing all the right things, Microsoft and Google continuously block and rate-limit delivery. Case in point: we deliver 20,000 booking confirmation emails every day, all requested by users and not spam. We have perfect Postmaster Tools metrics: absolutely zero reported spam, 100% IP reputation, high domain reputation, zero feedback loop spam, 100% enc…

How is spam related to SPF and DKIM? Those prevent forgery, but if a spammer actually owns a domain, they can send you whatever they want. That's where the majority of spam comes from, so it's far from a solved problem.

A lot of spammers forge, requiring SPF/DKIM does help a bit. But yeah, not a solution.

Re: Poste.io – Complete Mail Server

#208
post #129

Earlier quoted context omitted.

I've been doing it for well over 20 years now. Ingress - out of the box rspamd is pretty decent and it is rather configurable. Egress - DNS (A,AAAA, PTR), (E)HELO, SPF, DKIM, DMARC. "IP Reputation". There are absolutely no shortcuts and yet most of the problems I diagnose regarding email delivery will find a missing PTR record or a miss-configured (or non configured) HELO. You cannot be lazy when it comes to email. S…

> Egress - DNS (A,AAAA, PTR), (E)HELO, SPF, DKIM, DMARC. "IP Reputation". Any insight into why this is a giant ball of complexity? I’ve had to setup spf, dkim, dmarc a couple times now and man… design by committee?

They solve different things. Email is very old so obviously things are going to be tack-on rather than baked-in.

The standards are fine in terms of achieving their goal, the hard part is getting the ecosystem to follow and make everyone's life easier.

Re: Poste.io – Complete Mail Server

#209

Earlier quoted context omitted.

At least they are hashing and not storing encrypted passwords. But even a baby framework with may be 10s of deployments have switched to bcrypt, etc. Im not sure why they're boasting about SHA512. But I am a little lost on the RFC thing. Could you enlighten me. I thought they were standard ports for legacy,TLS, and SSL ports.

tldr; 465 is obsolete,you should not use it; 25 is for relaying mail between servers; 587 is the default mail submission port today.

No, it is not obsolete, quite contrary actually. See RFC8314.

The implicit TLS submission port got deprecated for a brief time, but it's no longer deprecated.

Explicit TLS is a terrible idea and for that reason it's recommended to provide implicit TLS (submissions).

Re: Poste.io – Complete Mail Server

#210
post #75

Earlier quoted context omitted.

ARC is what you need, it a similar signing as DKIM, but resigns a message. https://en.m.wikipedia.org/wiki/Authenticated_Received_Chain

Interesting. I see a gotcha though: > Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited,[3] so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices. Is there any documentation on how GMail and Hotmail onboard a ARC-using domain? Their documentation is very... sparse.

The same way they're gathering intel on domain/IP trustworthyness.
Post reply on HN