With regard to the 556 errors, should I assume that these messages will
not have been received, or is Mercury smart enough to fall back and try
again later ?
556 is fatal and will not be retried. This was a single message with a lot of RCPT TO: addresses and the receiving system has set a limit on how many bad addresses it will accept in a single connection. To solve a problem like this you should use a mailing list to create either a single message for each user ( VERP) or reduce the number of addresses in each message (Explode). VERP based is the most effective but it also takes to most resources. I use it for 1000 member lists though quite effectively with Mercury/32 and MercuryE.
From the Mercury/32 mailing list help:
2: VERP-based error handling VERP stands for "Variable Envelope Return-path Processing": when using this method, every recipient in the list gets a separate copy of every message sent to the list, and in that copy of the message, a special version of the Return-path field is created that allows Mercury to work out the individual list and subscriber from any errors that get returned to it. Using this information, Mercury can automatically take certain actions when errors occur, such as setting the subscriber's entry to "NOMAIL" or deleting the subscription. Using VERP allows error handling to be almost entirely automated for a mailing list, but it is very "expensive" in the sense that it generates an individual message for every subscriber when a message is sent to the list. Even given the expense factor, however, VERP is often the only manageable way of handling larger mailing lists. Note: when using VERP error handling, any value you enter in the "Explode submissions into x jobs" field of the Distribution page of the Mailing List editor will be ignored - VERP-based mailing always generates a separate copy of every message for every subscriber on the list.
Explode submissions For large lists, it can be significantly more efficient to send the message out to several chunks of the subscription list instead of simply generating one large message, since doing so allows multiple SMTP processes to handle the mail at the same time. If you enter a value here, Mercury will "explode" messages sent to the list into that number of outgoing jobs. This setting can have a dramatic impact on list delivery if you are using the MercuryE SMTP end-to-end delivery protocol module. You cannot explode a submission into more than 20 jobs.
<blockquote>With regard to the 556 errors, should I assume that these messages will
not have been received, or is Mercury smart enough to fall back and try
again later ?</blockquote><p>556 is fatal and will not be retried.&nbsp; This was a single message with a lot of RCPT TO: addresses and the receiving system has set a limit on how many bad addresses it will accept in a single connection.&nbsp; To solve a problem like this you should use a mailing list to create either a single message for each user ( VERP)&nbsp; or reduce the number of addresses in each message (Explode).&nbsp; VERP based is the most effective but it also takes to most resources.&nbsp; I use it for 1000 member lists though quite effectively with Mercury/32 and MercuryE.
</p><p>&nbsp;From the Mercury/32 mailing list help:
</p><p><i><b>2: VERP-based error handling</b></i>&nbsp;&nbsp; VERP stands for "Variable Envelope Return-path Processing": when using this method, every recipient in the list gets a separate copy of every message sent to the list, and in that copy of the message, a special version of the Return-path field is created that allows Mercury to work out the individual list and subscriber from any errors that get returned to it. Using this information, Mercury can automatically take certain actions when errors occur, such as setting the subscriber's entry to "NOMAIL" or deleting the subscription. Using VERP allows error handling to be almost entirely automated for a mailing list, but it is very "expensive" in the sense that it generates an individual message for every subscriber when a message is sent to the list. Even given the expense factor, however, VERP is often the only manageable way of handling larger mailing lists. Note: when using VERP error handling, any value you enter in the "Explode submissions into x jobs" field of the Distribution page of the Mailing List editor will be ignored - VERP-based mailing always generates a separate copy of every message for every subscriber on the list.</p><p><i><b>&nbsp;Explode submissions</b></i>&nbsp; For large lists, it can be significantly more efficient to send the message out to several chunks of the subscription list instead of simply generating one large message, since doing so allows multiple SMTP processes to handle the mail at the same time. If you enter a value here, Mercury will "explode" messages sent to the list into that number of outgoing jobs. This setting can have a dramatic impact on list delivery if you are using the MercuryE SMTP end-to-end delivery protocol module. You cannot explode a submission into more than 20 jobs.</p>
