Thank you for this perspective. I've been hosting my own email for about 25 years and have never had significant problems delivering to any of the large providers. A couple of months ago I migrated from one VPS host to another. I'd been putting this off for a long time, in part because of what I've read on HN about how difficult it is to self-host your mail. I finally took the plunge a couple of months ago, expecting to find the new provider's IP space unusable & having to relay via the old MTA/start relaying via a commercial MTA; but to my surprise, it's been completely smooth sailing! Maybe I've just been lucky with the nature of my setup: a small number of mailboxes and domains used for personal/small business use. Certainly if I was sending bulk mail or significant amounts of transactional mail then I'd use someone else's service.

I've been self hosting for ~15 years and maybe have deliverability problems once every 3-4 years at most. Just had one this morning, in fact. Once in a blue moon I end up on one of the very aggressive spam blocklists (this time Spamhaus) and it's usually just a matter of following their delisting process.

I've also been hosting all of my own infrastructure including email. I have only used small cheap VPSs and one thing I have learned is that the reputation of the IP address you are assigned may or may not have a history of delivering mail, and it's just luck if you get an IP that hasn't been blacklisted or known for SPAM in the past. I have put off migrating to a new hosting provider and actually just finished that task.

If you set up a new VPS for sendmail email, the first thing you should do is look up the IP address you have been assigned to assess it's reputation. If it's bad, you may be able to be assigned a new IP through some providers, but you can always just spin up a new VPS, check it's IP, and if it's clean, use it, otherwise drop the VPS, create a new one, and check the IP.

Another option is to buy your own CIDR range. The smallest subnet you can buy is a /24, but your addresses will be portable between ISPs giving you complete control over your IP reputation, and the ability to warm up IPs for sending when an existing IP you are sending from starts to get a negative reputation.

Always make sure you set your rDNS or PTR record to match the A record for the mail server's FQDN.

Set up opendkim, opendmarc, and policy-spf or equivalent, make sure your DNS is all aligned properly, and set your DMARC policy to enforce. You can start off enforcing on a small percentage of outgoing email, and if that looks good, set to reject 100% of DMARC failures.

My stack is postfix and dovecot with opendkim, opendmarc, policy-spf, with postgres to hold domains, mailboxes, aliases, etc and some simple scripts to get postfix and dovecot to use the postgres db. I used postgres for reasons not directly related to sending email, so the same thing can be accomplished using something like SQLite or even flat text files. I ended up writing a perl program years ago to manage the whole stack from a single cli command.

I'm not suggesting my stack is anything special. I use the daemons I use because I have been using them for years and understand them very well. If you want something more than just a TUI, there are a lot of options. I still use spamassassin, but I know there are newer alternatives.

The main driver behind how I chose the stack I use is knowing exactly how every part of it works.

Running your own email server without understanding how all of it works is what people mean when they say that you should not host your own email server. It's not enough to copy/paste from a tutorial, because you will run into issues in which something isn't working right, but since you just copy/pasted you have no idea how to fix it.

I worked for an online publishing company that sent a mixture of quality content to double-opt-in subscribers and transactional emails, and moving traffic around on your IPs if you have more than one to maintain reputation. We sent over 500 million emails a month using a combination of self-hosting our MTAs, and also using ESPs in some scenarios in which even the best IP/domain reputation practices aren't enough to get inboxed. Always set up feedback loops and maintain your lists if you are sending newsletters. Set google postmaster tools.

One of the reasons I run my own mail server is that I create aliases any time I sign up for an account on a website that are unique to that site. github@example.com would be an alias that forwards to an actual mailbox that is unknown to the rest of the world. This way I can tell who has sold my email address, or had their mailing list compromised, and I can simply remove the alias to stop any spam going to the real inbox. Doing that can reveal some pretty interesting things about how your information is bought and sold by data brokers.

Did you change domains?

Can you formulate that question more precisely if this doesn't answer you?

* I am still using the same domains that I've always hosted mail for * Since I am sending from new IP addresses, but want to retain the ability to send from the old MTA until it is decomissioned, the new MTA uses a different HELO identifier, and the dependencies for that are all in place (forward and reverse DNS addresses and updated SPF records) * The new DNS records are still in the same administrative domain as the old ones

Debian builds Exim against GnuTLS because OpenSSL used to use a license with an advertising clause, making it incompatible with the GPLd Exim.

Since OpenSSL 3 is now available under a GPL-compatible license, I think it's long past time to switch. But judging by the sorry state of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446036 I don't think it's going to happen any time soon.

Ask the CA/Browser forum what they will insist upon

FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.

They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!

Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:

    $ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
    allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
    allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write };
    allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
    allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };

... that's a lot of domains, including container_t and user_t; and obviously anything unconfined_t can't be expected to be restricted.

(Maybe you & others are specifically thinking of Android's policy?)

sorry yeah, I saw not exploitable on Android and thought most SELinux would be ok. Not super sure on this case what the surface is

... and that is why all 'modern' software is incredibly memory and CPU intensive...

But when things go wrong, you can usually find some random json file and adjust it :)

Take it from someone who saw it when it first aired on standard definition analogue TV: it doesn't really matter all that much. The performance of the actors and the story is what's important!

That’s fair but from what I understand, inaccurate ratios could hide a lot of crucial detail

https://www.insidehook.com/television/seinfeld-netflix-aspec...

A _real_ web site!

When I first returned to it rewatching B5 a couple of years ago, I actaully found it difficult to navigate. It took me a while to realise that my brain was parsing the block of navigation buttons at the centre top of the screen as a banner ad and filtering it out!

The "TKO" 'A' plot is silly but it has one of the most moving and memorable 'B' plots of the series!

Agreed! In fact it is kindof annoying. Every set of orderable elements has a worst element, therefore every show has some bad episodes. You want to tell new viewers to just skip those episodes if they want, but it’s practically impossible with B5. If you skip TKO because part of it is cliche then you also miss the essential key to understanding Ivanova.

Both were pretty meh IMO.