Get your Portable ID!

Thursday, September 18, 2008

But Isaac Newton beat me to it...

I'd like to be the first to say "Fuck you, Apple."

I've just spent the last week doing nothing but wrestling with OS X Server's incredibly fucked up postfix implementation.

Here's the deal. When a message is received which is addressed to a bogus domain or mailbox name (that's the parts after and before the @, for you Philistines), it's supposed to be silently rejected. That's just how the internet works these days. You don't blithely accept for relay all mail which comes to your computer.

Apple's system doesn't accept mail to bogus domains, but it does accept mail to bogus users. Sure, local_recipient_maps and relay_recipient_maps are two fine and dandy wonderful files which are intended to keep the server from doing that. The only problem exists when you are setting up a mail server which authenticates from another domain controller. Then Apple's setup automatically accepts regardless of whether or not "whatever" is a valid mailbox name or not.

This creates problems because:

  1. The server's delivery queue becomes filled with undeliverable mail.
  2. The server bounces the mail when it realizes that the queue is undeliverable, creating a bounce message via MAILER-DAEMON which then gets stuck into the queue.
  3. The queue now has a bounce message which is scheduled to be delivered to whoever sent the message, which, almost univerally is either a bogus domain name or some poor innocent bastard's email account.

The end result of this is that, in the best case scenario, our mail server spams some poor guy with a bounce message containing junkmail. In the worst case scenario, this bogus mail sits in the queue for as long as 5 days (by default behavior, thanks again, Apple) trying to deliver. While it's failing to deliver, the 2 outgoing connections total (once again, default behavior, thanks, Apple) are clogged up waiting for domain name resolution to fail.

This means that all of the messages which are attempted to deliver at this time are postponed for, you guessed it, the Apple defined default time of 400 minutes. When they come around for delivery again, if the queue happens to be full again, the message is requeued again this time postponed for a non-linearly increased time of > 400 seconds.

The end result of this is that with even 5-10 of these undeliverable messages sitting in the queue, the queue can get backed up for as long as 24 hours within less than a day of receiving an unholy volume of spam.

Aforementioned unholy volume being a number < 300 per day. As a result, the queue will often be sitting there with less than 300 messages (which should take at most 20 seconds to process all of them) for as long as 20 hours without attempting to redeliver a single one of them.

To quote Alice Cooper, "Welcome to my Nightmare."

No comments:

Post a Comment