I have my own mail server and am running it from my home server for 15 years now, I did not notice having issues with delivery to large providers and I did not set up SPF, DKIM or whatever currently you supposed to use (I do have TLS enabled though).

I do have some mailing lists running from it, so it's possible it helped me that their users are making sure mails from it doesn't end up in junk folder.

Anyway, I would encourage anyone to run their own mail server, to prevent large provider doing what you're mentioning. Google already did this with XMPP. They made GTalk interconnected with rest of XMPP server, but as soon as they got a large base they disconnected from the rest and made their own proprietary network.

Same experience here. No special setup, no SPF or DKIM, and yet no particular challenge in sending e-mail. I feel the challenges of operating a mail server are often exaggerated. But then, I don't tend to send spam.

Wow, I am surprised. I recently had to migrate my mailserver from my datacenter to the cloud. I lost the original IP address as a result. The new IP address got flagged immediately on gmail and everywhere else. I setup SPF and DKIM, that seems to fix the issues with the big guys. However on comcast and others I still got throttled for quite a bit. i had to request csi.cloudmark.com to unblock the ip..

I wonder if you happened to inherit an IP address from someone who was up to something less than savory.

Oftentimes, poorly-managed VMs / VPSes get infected with scripts / botnet software and start blasting out spam. It takes a long time for IP reputation to recover, esp. under the same owner info on the netblock.

Regarding inbox deliverability from dynamic IPs (like you'd have with a residential connection), it might work sometimes for short messages with no attachments to people you've corresponded with before, but I wouldn't expect general deliverability to be very good. You have the same problem with botnet infections / malware-based spam here as well; home PCs are much more likely to get infected with that kind of stuff (though WordPress exploits are VERY common on servers), so many people running mail servers will just straight up block dynamic IPs from big ISPs and assume that nothing of value was lost. Personally, for low-volume mail such as what a home server might send regarding maintenance or alerts, I'd recommend using a service like mailgun and hooking up to that with SMTP. It's a lot easier than running your own mail server, you won't have to deal with inbound spam if you're only sending, it works well with minimal setup, they guide you through each step, etc etc.

That would be my guess.

I run an email server with ten domains on it. Hotmail blocked me once, but I had no problem getting that lifted. No other issues for over five years now.

I have more of a problem with mail going the other way. I use a number of online spam traps to avoid spam, and my gf's Yahoo account often gets bounced by them.

Specific Yahoo servers regularly get flagged for spam, and if you're using a Yahoo account your mail will be filtered by many, many servers if it's sent from one of those IPs.

It was a long time ago so my memory is a bit fuzzy, but if I remember correctly it was fairly straightforward. It was right before and as SPF really became worth doing. The thing that would get a lot of my customers running their own mail was the PTR not matching the name presented by the mail server and/or that name not being listed in the MX records for the domain it was relaying mail for. I did have to deal with the occasional IP that had been blacklisted on RBLs and that could be a pain the ass and typically the first order of business was actually blocking outbound SMTP except from their mail server.

Those were the days that I don't miss.

"And SMS is also frustratingly non-universal. After years of having cell service with one of the large providers" .. "Each SMS shortcode is only supported on a provider-by-provider basis."

Yes, each provider does support their own short codes, but this is not a great example of SMS being "non-universal"

A short code is just "dialling sugar" for {country_code} + {network_code} + {short_code}.

Think about it this way: It would be kind of like trying to access the following url: http://news.ycombinator

Do you need it on .com? .co.za? .io?

So in other words, if you are roaming and you want to use a short code. Just prefix with {country_code} + {network_code}.

The routing should work correctly, the switch (msc) routing tables will have the country code + network code, and route the message correctly to your network. If your network has been configured correctly, it will be able to respond.

There is nothing inherently in SMS that prevents it working. Though carriers can choose to block short codes to other networks (usually to avoid fraud). Your carrier would then need to include request the roaming partner white list a set of allowed short codes.

This isn't really correct. Short codes are hardcoded routing rules specific to each operator, not just syntactic sugar. They don't map to regular phone numbers (MSISDN) and are generally not available from other networks or overseas, unless the service provider (not the operator) makes an effort to replicate the code across operators and provide it internationally. Some countries have regulatory coordination to prevent the same number from routing to different services across different operators, but that's about it.

Source: used to work with SMS gateways for a living.

That said, short codes are rapidly becoming obsolete since data has become ubiquitous and everything is online now. The only one I ever use is voicemail.

> short codes are rapidly becoming obsolete

I wish. With the prevalence of using SMS for 2FA, short codes are very much in use. When you've got a provider that doesn't work with most short codes, you run into a frighteningly large number of difficult situations. Some providers will give you a "I didn't receive the text, call me" option. Some (grr...Venmo) don't. But it's one of those features you don't realize how often it's used until it doesn't work for you.

Yes they are hard coded on the home operator/carrier. Though this does not mean it will not route.

What country are you in?

The way I have seen them configured is they work from off-net if you prefix with correct codes.

Remember the foreign switch,smsc or ussd gateway is going to route the message if it has the correct prefix. The Routing (b number analysis) is looking up a prefix, to send it off.

It is up to your home operator to correctly handle this.

Source: 10+ years working with mobile operators

I run my own email, on a vps no less, and the only blocklist that has given me trouble is Symantec's (and a bit of Googling at the time showed it had a high false-positive rate).

Google, Hotmail, etc, all work just fine. Just make sure to set up DMARC (DKIM+SPF) and TLS by default.

That's a shame since I wrote the RFC/BCP on DNS blocklists while at Symantec.

Haha, well this is awkward..

It was a while ago, if I recall correctly the block seemed to be ip based (it reported my ip not domain-name). I host with vpsdime, while it is a vps and thus to be expected I don't seem to be on any other lists.

DMARC, PTR, no open-relay, encryption, etc., all set up on my end. The email I was trying to reach was in fact an (important to me) gov't adress. Ended up using my old gmail for that instead.

Short codes are managed per country, but within the US just about every true mobile operator should have the ability to work with the same US short code. If they don't support a given code, it is because they choose not to. Part of the approval process for getting a short code is having all of the major wireless carriers sign off on your application.

If Google Fi is using SMS-enabled wireline numbers as opposed to mobile numbers then there could be additional complications.

Good points, both! I think it's telling that the e-mail one is a relatively recent development. Is that also the case for SMS? I'm not too familiar with the history of short codes, but I have the impression that they're newer too.

I didn't even know what shortcodes were until this moment. I think this detracts from the main point, though. Of course automated commercial services will have their idiosyncrasies, but if you want to communicate with people, phone calls and SMS seem to work reliably, worldwide, in a universal way.

That's only true if you are in certain IP spaces that get lumped in with residential users or are public spaces that are heavily used like AWS.

I've run on-Prem email for years in different capacities. It isn't nearly as difficult as its often portrayed.

Postfix is not fun to set up and even less fun to debug if there are config issues.

But there are useful sample config files online, and once it's running it just works.

That's nothing - you should try running your own cell tower. Or just hooking up your own telephone exchange.

Email interoperability is at LEAST as good as phone interoperability, which was the GP's point, I think. But all of these things are more walled gardens than you might think.

We ran our own mail server, didn't find it very difficult. If you run it off of IP blocks that have been abused in the past, might be harder.

And what you are describing are isolated instances that almost no one experiences with email or sms.