Defragmentation channel message retention time

Messages are retained in the defragment channel queue only for a limited time. When one half of the time before the first nondelivery notice is sent has elapsed1 (and a    time  has elapsed so that the channel is attempting to process relevant  message fragments), the various parts of a message will be sent on  without being reassembled. This choice of time value (normally) eliminates the possibility of a nondelivery notification being sent  about a message in the defragment channel queue.

The   channel option (and optionally its priority-sensitive variants,  )  controls the amount of time  that can elapse before nondelivery notifications are sent, while the    channel option (and optionally its  priority-sensitive variants,  )  controls when  message delivery attempts are made. So between the two of them, they control the amount of time messages are retained before being sent on  in pieces, with   normally being the primary control  (controlling how long before the channel "gives us" on  attempting to reassemble message fragments), modulated by when the    values in fact cause the channel to run and  attempt message delivery (hence deliver message fragments that have  lingered past half the final   value and still do  not make up a complete message "as is", without reassembly). Set the  option value to twice the amount of time  you wish to retain messages for possible defragmentation (and ensure  that the   values in effect for the defragment  channel are such that a delivery attempt will be made shortly after  half the final   value). For example, normally a   value of 4 would cause retention of message  fragments for two days: defragment notices 4 defragment-daemon Or if the more general   values do not align well  with the defragment channel&#x27;s    time scale, then  also set some sensible   values explicitly on the  defragment channel. For instance, setting the final   value to   means that message  (fragments) will get a reassembly-and-possible-delivery attempt every  four hours. Hence the following sort of definition: defragment backoff "p1h" "p2h" "p2h" "p4h" notices 4 will mean that message fragments will get sent on as is (still as fragments, rather than reassembled) after approximately forty-nine  hours. (There will be message delivery attempts immediately, then at one hour, three hours, five hours, nine hours, then every four hours  thereafter---so the first time past the two day point, the expiration  of half of the   final value, will be at forty-nine  hours.)

When the defragment channel cannot reassemble a message, and decides to send onwards a message fragment, it will add a header line Defragment-failed: official-local-host-name showing the   from the L channel.

 1Note that the "half" is calculated using integer integral division but not allowed to go below one, so for          instance an initial   value of            results in fragments being eligible for delivery after            days or hours depending upon  , but even an initial            value of   still means fragments          aren&#x27;t eligible for delivery until after   day or hour.

See also:
 * Defragmentation channel
 * backoff Option
 * notices Option
 * return_units MTA Option
 * official_host_name Option
 * Local channel
 * Defragmentation channel configuration