Most commercial MTA server products are little better. They force traffic into a limited number of shared queues, creating major stability problems when any one of the traffic streams encounters problems. When receiving domains deem certain content or sending practices suspect, they “tarpit” traffic from the offending sender. Tarpitting slows the acceptance of a message to a crawl by drawing out server responses to the maximum time allowed (as specified in the Simple Mail Transfer Protocol). Tarpitting causes messages queued behind the offending message to back up, delaying everything else in the shared queue. Clearing or sidelining the affected traffic could alleviate the problem. But with queuing architecture of this kind, even just determining which messages in a shared queue are causing the problem can be very time consuming.

When using a shared queue and one sender’s large mailing is submitted, these messages are placed at the front of the queues. When a subsequent mailing or transactional message is submitted, those messages are then placed in the queue behind the first mailing. Typically, this queue contention will cause the sender of the second mailing to experience delays, which will often prompt complaints and calls to the IT support operations.