I have recently moved my MX server to a new IPv4 address. Admittedly, new IPv4 address is in quite bad neighbourhood, a residential /24 pool provided by ISP who doesn't filter outgoing SMTP by default. Most other IPv4 addresses in this pool have quite poor reputation, probably without their users even knowing their malware infested devices are being used to send spam. It took less than a week since I took over this new IPv4 for it to get dropped from most of lists such as spamhaus which actively monitor and list spamming IP addresses, delisting them automatically when spamming stops.

The Drill

Having set up and maintained dozens of MX servers over two decades, I am familiar with complete drill a postmaster needs to pass in order to have emails from their servers accepted by other postmasters. Some are as relaxed as requiring MX server to have A DNS record set up, while others - reasonably so - require matching forward and reverse A DNS record, as well as SPF, DKIM, DMARC and MTA-STS DNS records. Most of them will additionally consult some lists such as ZEN by spamhaus or barracuda before accepting email. Finally, their content filtering systems will check message headers and bodies before deciding should they deliver email to their user's inboxes or junk folders, or drop it altogether if it violates some policies such as banned attachment extensions, malware or phishing keywords and links.

Preparation and Migration

I monitored IP reputation providers for two weeks until I saw my new IPv4 disappeared from most of automated spam lists. Over that period I made all preparations needed for moving.I asked my ISP to set up PTR DNS record for my MX server in their in.addr-arpa zone to match A record I configured in my domain's DNS zone. I prepared fresh DKIM keys, included new IPv4 address in my SPF record, and any other DNS-related stuff. Then I moved on to actual migration of email server which was as easy as sending my bhyve vm which holds all the components - postfix, dovecot, rspamd and roundcube - over ZFS to new host, starting it and changing IP address records in a few config files. Once i changed my MX records emails started pouring in, outgoing mail was mostly fine except for most important email providers - google, microsoft and yahoo. Which translates to outgoing mail was not fine at all because most people have their mailboxes on one of those three and my users couldn't send email to most of their contacts even though they successfully received email from them.

Smoothing Rough Edges

I noticed some lists - barracuda and a few others - still listed my IP address. Luckily, they all provided web forms for delisting requests. After politely explaining I took over IPv4 from residential pool without outgoing SMTP filtering and assuring them I will be closely monitoring all suspicious activity originating from it, as well as maintaining and reading emails sent to all required RFC2142 mailboxes such as postmaster@ and abuse@ I got delisted quite quickly. This let me through to Yahoo, but Microsoft and Google took a bit more time and effort. I don't remember all the details but I know Microsoft was easier and faster. Google let me through to G-Suite users a week or so earlier than to standard gmail recipients but the latter also got ultimately resolved after some meddling in their web interfaces and verifying my domain over DNS. Things finally settled down and my users and me could finally get back to business of sending and receiving email as usual.

Unrepairable Villains

Then, some time ago, I received email birthday greeting from a friend of mine. I replied and got the following message from my postfix:

<myfriend@t-online.de>: host mx00.t-online.de[194.25.134.8] refused to talk to
    me: 554 IP=IP.ADD.RE.SS - A problem occurred. Ask your postmaster for
    help or to contact tosa@rx.t-online.de to clarify. (TEM)

I contacted above email, explained politely about IPv4 address change of my mx server and assured them I did all the steps as required by appropriate standards and RFCs, similar to what I always do when I have delivery problems. Contrary to everyone else who ultimately let my mails through, they pointed me to their Requirements for smooth access to their email exchanges. I assured them I am compliant, but they insisted otherwise in an email they sent me:

"There must be a domain and website with direct contact information easily deducible from the delivering IP's hostname (FQDN)."

According to this "http(s)://[mx.]example.org" has to link or redirect to a website which has to show direct contact data of the person responsible for e-mail sent from that system.

I once again assured them my website, whose second level domain matches that of my mx server, contains contact form which delivers email straight to my primary mailbox, and that I maintain postmaster@ and abuse@ mailboxes as well as read all email sent to them. Another negative response from them made me think it was written by AI. Ultimately I took a look at my mx server's statistics where I saw the number of emails exchanged with t-online.de mailboxes was exactly two per year - one is my friend wishing me happy birthday, the other my reply to thank him for best wishes. Yes, I do wish him happy birthday as well, but by other means of communication. Or maybe I forgot a few times. I'll try to be better at it. Anyway I decided I won't spend any more time and effort for fullfilling t-online.de's ridiculous requirements. Also that I won't be accepting any emails from them for as long as they don't accept emails from me.

Finding out IP addresses of all four IP addresses of their sending MX servers was easy, They all reside in same /24. Whole /24 ended up banned on my postfix:

# /usr/local/etc/postfix/client_access
194.25.134.0/24 REJECT Your email provider sucks. Ask them to start respecting standards or move to another provider.

For good measure I also banned their domain:

# /usr/local/etc/postfix/sender_access
t-mobile.de REJECT Your email provider sucks. Ask them to start respecting standards or move to another provider.

That should teach them. It won't. All this talk about GDPR and privacy is quite often just a fig's leaf over some corporations' insatiable greed for any private data they can slurp as this service provider in Germany, lauded for their privacy laws, showed to be worse in that aspect than even some of their US rivals, to the point of denying service to small providers who won't bow down to their ridiculous self-serving regulations. We could have been friends.