Recipientlimit, recipientcutoff, deferralrejectlimit, disconnectrecipientlimit, disconnectrejectlimit, disconnectbadcommandlimit Channel Options

From MsgServerDocWiki

Maximum allowed recipients or bad commands (recipientlimit, recipientcutoff, deferralrejectlimit, disconnectrecipientlimit, disconnectrejectlimit, disconnectbadcommandlimit)

The recipientlimit, recipientcutoff and (new in JES MS 6.2) deferralrejectlimit channel options, when placed on a source channel, impose per-channel limits on the number of recipients for a submitted message. They are per-channel (as opposed to per-SMTP-server) analogues of the ALLOW_RECIPIENTS_PER_TRANSACTION, REJECT_RECIPIENTS_PER_TRANSACTION, and ALLOW_REJECTIONS_BEFORE_DEFERRAL SMTP channel settings. Each of these options accepts a single integer argument; they default to no limit.

recipientlimitlimits the total number of recipient addresses that will be accepted for the message; additional recipients will be rejected. The text in the rejection is configurable via the error_text_recipient_over MTA option, which by default is "too many recipients specified". The error is a temporary rejection by default, but if bit 4 (value 16) of the use_permanent_error MTA option is set, then the rejection is permanent. So in the case of attempted SMTP message submissions, the default temporary error, with the default error text, would appear as:

452 4.2.3 too many recipients specified 

whereas with the default error_text_recipient_over text but with bit 4 (value 16) of the use_permanent_error MTA option set, then a permanent error would appear as:

550 4.2.3 too many recipients specified 

recipientcutoffcompares the total number of recipients that were presented to the MTA to the specified value and a message will not be accepted for delivery to any recipients if the value is exceeded. In the case of attempted SMTP submissions, the message will be rejected at the DATA command with the SMTP rejection:

451 4.4.5 Error ending envelope - Too many recipients specified for this message 

New in JES MS 6.2, and supported only for SMTP (not for LMTP), deferralrejectlimit limits the number of bad (failing) addresses that will be allowed during a single session; after this number, all subsequent recipient addresses, good or bad, will be rejected with a temporary error. In the case of attempted SMTP submissions, additional RCPT TO: commands will be rejected with the error:

452 4.5.3 Too many rejections; try again later. 

while attempted VRFY: commands will be rejected with the error:

452 4.5.3 Verification blocked; too many rejections. 

Similar limits controlled on a per-user and per-domain basis can be configured via LDAP attributes; see the MTA options ldap_recipientlimit, ldap_recipientcutoff, ldap_domain_attr_recipientlimit and ldap_domain_attr_recipientcutoff.

The disconnect* channel options are new in Messaging Server 6.2. They are supported only for SMTP, not for LMTP. Each takes an integer argument specifying the maximum number of (recipients, rejections, or bad commands, as applicable) which will be accepted for messages submitted via that source channel; any more will result in the MTA forcing a disconnect of the SMTP session, after issuing an error response to the client consisting of (for disconnectrecipientlimit):

450 4.7.0 Session recipient limit reached; disconnecting 

for disconnectrejectlimit in JES MS 6.2:

450 4.7.0 Session bad recipient limit reached; disconnecting

or in JES MS 6.3 and later (JES MS 6.3 also being when behavior was enhanced so that rejected MAIL FROM's count against the disconnectrejectlimit, whereas in JES MS 6.2 only rejections at the RCPT TO or VRFY stages counted; JES MS 6.3 is also when behavior was enhanced so that disconnectrejectlimit is checked at the VRFY stage and with a negative value applied at the VRFY stage, whereas previously such VRFY rejections were counted but the disconnect would not be triggered until a subsequent RCPT TO attempt "noticed" that the threshhold was exceeded):

450 4.7.0 Session rejection limit reached; disconnecting 

or (for disconnectbadcommandlimit):

450 4.7.0 Session bad command limit reached; disconnecting 

In the case of the disconnectrecipientlimit or disconnectrejectlimit channel options, once the limit is exceeded, the error-response-and-disconnect normally will occur after the next MAIL FROM or RSET command (or in the case of disconnectrejectlimit in JES MS 6.3 and later, potentially after a failed VRFY attempt). (Note that because the disconnect usualy does not happen until after a subsequent MAIL FROM or RSET, these disconnect* channel options would most often be used in conjunction with other channel keywords or TCP/IP channel settings: perhaps recipientlimit or recipientcutoff to limit the number of recipient addresses accepted, or deferralrejectlimit or the ALLOW_REJECTIONS_BEFORE_DEFERRAL TCP/IP channel setting.) In the case of disconnectbadcommandlimit, once the limit is exceeded the error response is issued and the MTA forces the disconnect.

Note that VRFY attempts are counted separately from RCPT TO attempts against the recipient count; that is, one may have up to the recipient limit of VRFYs and up to the recipient limit of RCPT TOs. The VRFYs are counted, but counted separately from RCPT TOs. In contrast, failed VRFY attempts are added to the same rejection counter used for counting failed RCPT TO attempts and MAIL FROM attempts for purposes of comparison against the rejection limit; that is, one may have up to the rejection limit of any combination of failed VRFYs, MAIL FROMs, or RCPT TOs.

When the deferralrejectlimit has been reached (or a channel setting of ALLOW_REJECTIONS_BEFORE_DEFERRAL has been reached), a client VRFY attempt will receive from the MTA an error response:

452 4.5.2 Verification blocked; too many rejections.