I am aware of what it entails regarding IP "cleaning", setting a reverse record, SPF and DKIM. Just looking for tips on the software stack side.
This even works if you want a mostly-free setup: you have MX forwarding via some provider (Cloudflare, your registrar, etc) going to a personal address, and SES operates as your outbound SPF that works with Outlook/Gmail in terms of allowing you to set your domain email(s) as aliases within their interface.
Im sure just running Mail in a Box on linode would 100% flag it.
I KNOW google would because half the time i socks through one of my linodes (that i have used and owned the IP for years on) i get thrown through all sorts of captchas on services. INCLUDING signing into my own gsuite from it (despite an established history of just doing it).
Unfortunately the big players own mail, they do what they want. In fact having a domain registered with one will do better for your mail reputation than most would care to admit.
Just look at how MS uses SMTPS on port 25, sure they COULD use 587 or 465, but they dont:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-pra...
I'm not rejecting the concern or the ambiguous worry about arbitrary judgement, but the surveillance web's captchas are much more draconian than spam filters.
But having managed email across all three providers. Microsoft does just ignore rfc’s and basic standards pretty regularly and relies heavily on “AI”.
Google less so.
And when it works it works great. But once you get deliverability issues it’s a pain to resolve with them. Especially if you have to engage support.
If i'm running an email inbox, responding to support regarding email deliverability is my lowest priority primarily because, if I respond once, it becomes an attack vector for dedicated spammers to try to extract information about the spam detection systems.
Frankly you are more likely to make exceptions and monitor internally for deliverability from a google, or outlook.com or comcast.net than for some random xyz.email domain.
And blocking swaths of those has a bigger impact. Frankly though, imho, you should respond to users that report deliverability issues on your domain and tweak your spam filters accordingly. Just ignoring a users saying "i am not getting expected emails from this listserve" is a great way to encourage your users to employ shadow IT and just use personal accounts.
Obscurity isnt security, even with spam mitigations. Things like SPF, DKIM, DMARC along with some user impersonation filtering (including spoofing from fields) is basic spam 101 and will catch 99% of your actual security related phishing.And the largest ones (dmarc) can be probed publicly anyhow since almost all of it relies on DNS txt records.
If what you mention does turn out to be an issue, or you decide it's a worthwhile tradeoff to not have to care about IP reputation, you can choose to route all or a subset (depending on destination domain) of your outgoing mail through a provider like mailroute/mailgun/sendgrid/fastmail/posteo. Or even gmail/AWS. You can still self-host the rest even if you don't want to hother with outgoing SMTP, which you can always add later should uou choose to.
> If you stay on top of all the best-practices for running your own mail server, your hidden cost is the mind-share that that takes.
Are you actually speaking from experience here? Over the past 20-30 years it's been like, what, 4-5 new things to learn?
The mail server's IP is a pretty normal cloud VPS IP from a major hosting company. It's not on any public blocklists. I submitted unblock requests to MS, and signed up for their SNDS service, but all requests were denied without explanation and I simply made no progress.
My conclusion is that this route is impossible - do not waste time trying it.
I recommend raising the issue with support of your cloud VPS. They most likely handle cases like this routinely and have channels to MS that can get this resolved much smoother, IME. It's their IPs, after all.
Been sharing this setup with about 20 family/friends for a while now (5 years?)
> Is it caddy for email?
> No. It was intended to be one but developers quickly acknowledged the fact email cannot be easily abstracted behind some magic.
The only other instances of Caddy are that they copied a "caddyfile lexer" [1] and seemingly a typo in a test[2].
0: https://github.com/foxcpp/maddy/blob/d08c7f0e3927df64f10db91...
1: https://github.com/foxcpp/maddy/blob/d8cabb932d9e7c3abd056fe...
2: https://github.com/foxcpp/maddy/blob/d8cabb932d9e7c3abd056fe...
It doesn't matter what you do.
It doesn't matter that you are replying to an email and the message-id is referenced.
It'll be considered SPAM.
DKIM, DMARC and SPF mitigate it a bit, but not really.
Yesterday I had a form ask me for my email and it only accepted @gmail.com
Every other domain I tried was refused as invalid.
Email is dead.