It’s always DNS, even when you don’t think DNS is part of this configuration
In November, I rediscovered that my domain registrar and hosting provider offers email forwarding in addition to their hosted email service. This would end poorly.
At previous places I’ve worked, you could set up forwarding and hosted inboxes on the same mail exchange server, with conditional or wildcard forwarding. So I assumed that this was possible with the products I’m getting from my registrar and turned on forwarding for “workwithme@…” because not every system likes my actual email.
As it turns out, not only is their system not set up for this but it will also break delivery to the hosted email product. I was so distracted with trying to finish up my time at Flatiron, though, that I didn’t notice my inbox had stopped its steady flow of new emails. It was great to be so absorbed in work that I forgot to check my emails for a couple of weeks… but it was a serious blow to my pride that I let this go for so long. I only noticed when I realized that I hadn’t gotten my “You finished flatiron! Good job!” email along with the other students.
At the other place I worked that I was used to, we could configure forwarding and hosted mailboxes by making changes to
sendmail has a notoriously complex configuration file, to the point where the best practice for configuring
sendmail is to use a macro that processes a more conventionally formatted configuration and generates the actual configuration file.
The workflow for this will involve something like this:
/etc/mail# vim sendmail.mc /etc/mail# m4 sendmail.mc > sendmail.cf /etc/mail# service sendmail restart
Crucially, even though we could define forwarding to ‘adjacent’ (same domain), outside (different domain), or mailing lists – none of this had anything to do with our BIND DNS configuration. These services worked relatively independently of each other. So when I turned on forwarding I didn’t think to check my DNS records for the additional MX records that turning on forwarding generates, or realize what it meant when they were present (that they would conflict with the MX record for my primary hosted email account).
It’s a disappointing lesson to have to learn over and over again, but remember: it’s always DNS and there’s always more to other organizations’ infrastructure than you think there is.
Stay humble out there everyone! If you want to commiserate with me on this post, please hit me up here in the comments or on LinkedIn.