> There are all kinds of invisible forces that you abutt that can be difficult to figure out
This was my main experience, and all I did was try to set up the ability to simply send emails to myself (gmail) (and no-one else). Things like: this script crashed, or btrfs scrub finished + scrub results, and similar.
The first thing I tried was just setting up a VM with postfix running on it locally with my residential ISP. I don't even remember what the error was for this scenario, but it was just totally dead in the water. Absolutely zero mail delivery. I think I eventually figured out it's because google defers to spamhaus, and spamhaus says residential IPs = hard no.
That next thing I tried, and what I ended up doing, was writing a docker container that just runs an SSH port forward to jump from my local network to a digitalocean host, which is where another docker container runs postfix. I had done this bit once before, and I tried to just set up DKIM (since DKIM was, to my reading, basically bulletproof - why bother with SPF when you have real cryptographic identity assurance?). This led to weird error messages from google about my IP having a super low reputation. This was something I'd been worried about so I spent a bit of time trying to cycle my IP. But I eventually figured out it was just a bad error message and setting up SPF suddenly made my emails start delivering.
My main ongoing issue is that I had to add all my sending addresses (things my internalhostnamehere@myrealdomain.com) to my contacts in gmail, otherwise there was like a 50% chance they'd just go to spam. I've been running this setup for about a year and it's still a coin toss whether emails will come through fine, or if they'll say "this would've gone to spam but it's in your contacts". When that happens, I check the DKIM and SPF status in "original message" in gmail, and gmail itself says they both passed.
Absurd tbh.
For my "not self-hosted but better than letting google own my digital identity" solution, since I use apple icloud+ or whatever it's called, I set up the SPF stuff to let me send+receive email from my custom domain, so while icloud could still scan my mail, at least if I get banned, I still own the actual domain and could move somewhere else.
Even if one setups everything by the book (SPF, DKIM, DNS.) etc. No one at @outlook.com will receive email, based on my experience. Thus, it does not work well if email is important for business-to-business use.
Outlook and Gmail are basically having opaque rules who can receive email and there is no process to get “whitelisted” on these receivers.
I had exactly this problem too. I elaborated below.
If you keep an eye on your logs, when your emails are being blackholed (it accepts them but it does not deliver them!) it does provide a link in one of the 550 status messages, where you can get yourself unblocked. I've elaborated here: https://news.ycombinator.com/item?id=31185297
However this only works temporarily, after a month you're back in the doghouse. Only senders which send a large volume of legit traffic are allowed. It's ridiculous but sadly true.
Edit: I found the message in my old emails:
---
550 SC-001 (BAY004-MCxxx) Unfortunately, messages from
XXX.XXX.XXX.XXX weren't sent. Please contact your Internet service provider
since part of their network is on our block list. You can also refer your
provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
---
In that link the "SC-001" code also refers to that reputation thing. This was the same at outlook.com / hotmail.com and live.com . It did not, however, affect corporate customers using Office 365 / Exchange 365. Only customers of MS' consumer offerings.
My "internet service provider" was a legit colocation service and nothing funny was going on in their network by the way. Microsoft was the only party that had issues with my server. All known blocklists had no issues with it. It was just MS being difficult and making up their own rules.
Anyway going to that link there is a form somewhere to temporarily unblock it. Give it a try.. Perhaps you can create an account at live.com yourself and send a daily test email or something... I thought of doing this but eventually I got so frustrated I gave up on it.
> Only senders which send a large volume of legit traffic are allowed. It's ridiculous but sadly true.
That’s the thing I’ll never understand: why would one have to spam email to be considered not spam?
I wonder at which point it is legitimate to go full conspiracy theory, and suspect they’re just trying to block the little players so they can keep their relative monopoly. Maybe they don’t do it on purpose, but the way their anti-spam measures make life real hard for the little ones sure looks convenient.
If you get a 550 then it did NOT accept the mail. What grandparent is talking about would be the server replying with 250 OK and then neither delivering the mail nor sending a delivery failure notification.
One potential 1%-of-the-complexity answer to the problem of personal notification (which I presume was what email-to-self was solving) is to set up a Telegram bot. I recently really wanted realtime notifications on my phone (package tracking) and realized that all the top-level "send notifications to phone" type services are either mass push notification shops ($$$$) or bundled offerings ($$$) that were entirely overkill for my purposes.
There are two ways to run a bot on Telegram, either by running the bot client directly (meh, interesting but extra setup) or by using Telegram's bot hosting system that works over HTTPS. It's the second approach that takes 3 minutes (!) to get to an MVP state for notifications.
- You walk through a flow with a specific account (@Botfather) on Telegram to create a new bot account, which gives you an API key
- Find the new bot using the search function then open a conversation with it and (after sending /start) send a junk message
- Call something like `curl "https://api.telegram.org/bot$APIKEY/sendMessage" -X POST -H 'Content-Type: application/json' -d '{"chat_id":"1234567890","text":"boop"}'` (set chat_id to your account id) to send a new message - yup, it's literally this simple to send messages
- Go into Telegram's settings and add the bot as a notification exception (assuming you have notifications universally turned off by default)
- If you also set the full-screen popup to "when off" Telegram will (even when your device is locked) show an instant notification containing the sent text
- Because this is a conversation, the message history will be preserved unless you explicitly delete the messages (which you can do on a per-message basis)
- The Telegram bot API supports both polling and push-based I/O, where you can periodically poll /getUpdates or have Telegram call a webhook you configure. IMHO the way easier approach is just running the bot client locally at that point, *but*, for just sending out one-way notifications where replies don't matter, the default polling setting (no webhooks) is ideal as the bot server will delete un-acknowledged messages after IIRC 24 hours or so - so you don't have to worry about queue quotas or whatever, you can just ignore the whole receive side and it just works
Obviously the caveat is that this is 1% of the complexity and equally 1% of the... provenance, for want of a better way to put it. But in terms of "I need realtime notifications now" I am yet to find a better system. It worked perfectly.
This was my main experience, and all I did was try to set up the ability to simply send emails to myself (gmail) (and no-one else). Things like: this script crashed, or btrfs scrub finished + scrub results, and similar.
The first thing I tried was just setting up a VM with postfix running on it locally with my residential ISP. I don't even remember what the error was for this scenario, but it was just totally dead in the water. Absolutely zero mail delivery. I think I eventually figured out it's because google defers to spamhaus, and spamhaus says residential IPs = hard no.
That next thing I tried, and what I ended up doing, was writing a docker container that just runs an SSH port forward to jump from my local network to a digitalocean host, which is where another docker container runs postfix. I had done this bit once before, and I tried to just set up DKIM (since DKIM was, to my reading, basically bulletproof - why bother with SPF when you have real cryptographic identity assurance?). This led to weird error messages from google about my IP having a super low reputation. This was something I'd been worried about so I spent a bit of time trying to cycle my IP. But I eventually figured out it was just a bad error message and setting up SPF suddenly made my emails start delivering.
My main ongoing issue is that I had to add all my sending addresses (things my internalhostnamehere@myrealdomain.com) to my contacts in gmail, otherwise there was like a 50% chance they'd just go to spam. I've been running this setup for about a year and it's still a coin toss whether emails will come through fine, or if they'll say "this would've gone to spam but it's in your contacts". When that happens, I check the DKIM and SPF status in "original message" in gmail, and gmail itself says they both passed.
Absurd tbh.
For my "not self-hosted but better than letting google own my digital identity" solution, since I use apple icloud+ or whatever it's called, I set up the SPF stuff to let me send+receive email from my custom domain, so while icloud could still scan my mail, at least if I get banned, I still own the actual domain and could move somewhere else.