16

Outsourcing mail and the mailer daemon blackhole trap

 4 years ago
source link: http://rachelbythebay.com/w/2012/11/08/mx/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Outsourcing mail and the mailer daemon blackhole trap

Yesterday's post about bad Postfix settings reminded me of something else which used to create support tickets. It was the disconnect between having a machine which thought it was X as far as mail was concerned when X's mail was actually being handled somewhere else. This became more and more of a problem as people started outsourcing mail service for their domains to third parties.

Let's say you have a site called example.com, and it's also www.example.com by extension. You run Apache and serve up web pages for that domain from your machine at a web hosting company. However, your mail exchanger records are pointed at some third party, and they handle all of your mail service. Your users hit them for IMAP access and SMTP relaying, and they never even think about the separate web server.

However, on the web server, it thinks it is example.com, and it defaults to accepting mail for its own name. This is usually not a huge problem since only dumb spammer types ignore MXs when they are present, usually in a half-assed attempt to bypass filtering. When they try that approach, the mail either bounces or goes to a mailbox that nobody ever checks.

This misconfiguration becomes apparent when someone tries to set up a cron job or something else of the sort which then tries to send mail to someone at your own domain. Since the machine believes it is supposed to handle mail for that domain, one of two things happen. One possibility is if you have it set for "catch all" (or if that account happens to exist somehow), then it goes into a mailbox and is never seen again. Alternatively, it bounces, and then the bounce itself might go somewhere useful, or it might also double bounce and get dropped on the floor.

Eventually, the customer notices that they can't get mail from their own process and complains via a ticket, and that's when the web hosting support monkeys drop in and discover the mess. Sometimes there are impressive attempts at "rescuing" and redelivering the queued up mail which had been stuck on there. Other times, it's just written off.

Sometimes, people work around this by just changing the hostname of the machine to something else so it doesn't match exactly. This can also happen by way of mail server directives to accomplish the same thing. Having it believe it's actually www.example.com is one quick and cheap hack to make it leave example.com itself alone.

Some of my stories are from the old days. This one is from yesterday, as in November 7, 2012. I had to do this "you aren't really this" workaround to a Postfix box in this day and age. Yes, when it comes to some matters of technology, we're still banging rocks together, and probably always will be.


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK