Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is my fear. It's not really the running or configuring that scares me, it's the unceremonious bouncing/filtering at the other end.

I have run some mailers (postfix) for some clients who didn't want to spring for a MAAS provider, I would to my knowledge, set up everything correctly with SPF, DMARC, DKIM, stuff would still land in the spam folder half the time.

Maybe still my mistake, maybe over eager receivers, maybe my hosts were just in a bad net block.

And this was just for low volume transactional stuff, they would add manual "not spam" rules which is OK for them receiving sub-LOB notices but really put me off trying to run my life out of a self hosted machine.

I saw someone post the Helm the other day, which is an interesting idea of having on-prem storage with an off-site dns/sig layer. Still kind of beholden to another service though - and I personally don't want to host my mail in my house but on a VPS. Did make me wonder about how viable a low cost "we just provide the DNS stuff" mailer service would be or if that exists.

https://thehelm.com/products/helm-personal-server-v2



> Maybe still my mistake, maybe over eager receivers, maybe my hosts were just in a bad net block.

A common problem with new mail setups is the receiving end marking your messages down because the domain is newly registered, as this is seen (correctly in some cases) as a potential spam flag. Nothing you can do about that one except double-check you SPF & DKIM config and wait.

One of many gotchas with hosting your own mail. I still consider it to have been with doing so all these years.


There is also a half-way solution which is to run your own mail server for inbound traffic and use a mail delivery company to relay the outbound mail.

This gives you full control of receiving emails (for the online identity part) and gmail can't lock you out of your life with no recourse. But you don't need to deal with outbound email handling which is a bit more work.


Bouncing on the other end has nothing to do with running your own mail domain. In e-mail, sending and receiving are decoupled. Some people use the same local mail server to do both: to relay outgoing mail and to receive. But these are independent functions, and you don't have to send mail through your server. You can configure your mail client(s) with the SMTP credentials from you mail provider (such as your ISP). That's used for sending. For receiving, you connect to your own server via IMAP4.

Basically your sending side (if you choose to) can be essentially unrelated to your self-hosted mail receiving infrastructure except in the small fact of using your sending identity in the From: headers of your e-mails: you@yourdomain.com.


Doesn't that depend on my ISP running basically an open relay, if I'm trying to mail from me@hn.com and they only provide me@isp.net? Always figured they'd just dump the request with a "i don't know you".


No because relays can be closed, and usually are. Your ISP's SMTP server requires authentication, using the credentials they gave you, and almost certainly uses TLS also.

Your me@isp.net address (or perhaps the me part of it) is used for authenticating, along with the password. It will likely be used as your envelope address when sending; the SMTP command will be MAIL from: me@isp.net, though there could be flexibility there to accept other sending envelope identities.

In any case, your mail's From: header will have the me@hn.com.

If the ISP were to filter on the From: addresses after receiving the content of the e-mail, you'd have to negotiate something with them.


> using the credentials they gave you, and almost certainly uses TLS also

Ah yes, doh.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: