Molti mittenti non hanno idea che le scarse capacità di gestione delle code della loro infrastruttura email siano la causa principale dei loro problemi di invio. Le soluzioni open source utilizzano un approccio molto rudimentale che prevede l'utilizzo di un'unica coda monolitica per gestire il traffico, il che crea molti problemi di consegna delle email. Molti mittenti hanno affrontato questi problemi per così tanto tempo che accettano che facciano semplicemente parte dell'attività di invio delle email.
#2 Shared Message Queues Cause Delays
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.
#3 Message Queuing Issues Affects Sender Reputation
Left unaddressed, tarpitting and blocking issues will degrade the reputation of the associated IP addresses, and senders can find themselves in the unfortunate position of getting placed on ISP blacklists. Juggling senders and adding hardware can address the problem, but the process is manually intensive, costly and introduces operational risk. Without an effective solution, many companies find the profitability of their email operations eroding as costs outpace the growth of their revenue streams.
#4 Momentum’s Intelligent Message Queuing Capabilities Resolves Tarpitting & Blocking Issues
A key differentiator between Momentum and other commercial or open source solutions is this: as traffic is processed, Momentum creates a set of receiving domain queues for each traffic stream.
Each queue is then independently processed in parallel with the others. For example, a mailing with 50,000 messages that is throttled by the Yahoo queue for one traffic stream will never cause delays to Yahoo queues of other traffic streams. Transactional or bulk traffic will have no impact on any of the other traffic streams, and any tarpitting or blocking problem is limited to a tiny, easily detected fraction of the overall traffic.
Because Momentum enables management down to the receiving domain of each sending IP address, it can easily provide diagnostic statistics at the same level of granularity. The operator can see which traffic streams have unusually high bounce rates and what types of bounces are occurring most frequently, thereby providing the operator and the deliverability manager the information required to immediately begin remediating the issue. For more information about Message Queue Management, download A Deep Dive into Momentum’s Intelligent Queuing Architecture.
Learn more about why monolithic and shared queues used by commodity MTAs are detrimental to the speed and effectiveness of delivering messages in the Momentum vs Commodity MTAs white paper.
