Blocklimit, linelimit, sourceblocklimit, noblocklimit, nolinelimit Channel Options

Message size limits
Although fragmentation may be used to break messages into smaller pieces automatically, it may also be appropriate in some cases to simply reject outright messages larger than some administratively defined limit, (e.g., so as to avoid service denial attacks on the system or individual mailboxes).

The,   and   channel options are used to impose absolute size limits. Each of these options requires a single integer argument. specifies the maximum number of blocks allowed in a message. The MTA will reject attempts to queue messages containing more blocks than this to the channel. The  specifies the maximum number of blocks allowed in an incoming message. The MTA will reject attempts to submit a message containing more blocks than this to the channel. In other words,  applies to destination channels;

applies to source channels. An MTA block is normally 1024 bytes; this can be changed with the   MTA option. specifies the maximum number of lines allowed in a message. The MTA will reject attempts to queue messages containing more than this number of lines to the channel. These limits can be imposed simultaneously if necessary.

Note that the   and    MTA options can be used to impose similar limits on all channels. These limits have the advantage that since they apply across all channels the MTA can make them known to mail clients via the SMTP SIZE extension prior to obtaining message recipient information. This simplifies the process of message rejection in some situations.

The  and   settings are the default and mean that no per-channel limits are imposed. But message size may still be limited via other configuration choices: global limits imposed via the   or    MTA options, per-domain limits imposed via the attributes named by the   or   MTA options, or per-user limits imposed via the attributes named by the   or   MTA options, or a per-group/mailing list limit imposed via the attribute named by the   MTA option, or per-group/mailing list limits imposed via the   or   alias options (or in legacy configuration the equivalent &#x5b;BLOCKLIMIT&#x5d; or &#x5b;LINELIMIT&#x5d;  alias file named parameters), or a limit imposed via use of the   flag in the   mapping table.

Note that the  MTA option,  or similarly the    channel option on an incoming TCP/IP channel, causes the MTA&#x27;s SMTP  server to advertise the stated size (the minimum of    and the  channel&#x27;s  ) as the maximum size accepted  in response to a sender&#x27;s EHLO command. This means that clients/senders that understand the SIZE SMTP extension (see RFC 1870, ESMTP message  size extension) may not bother to even try to submit larger messages  after seeing the MTA&#x27;s EHLO response. Or if they do start to submit a larger message, if they at least specify the SIZE via the SMTP  extension on the MAIL FROM command, then the MTA&#x27;s SMTP server will  reject the message at the MAIL FROM. This contrasts with the effect of the   channel option which cannot be applied  (even if the sender used the SIZE extension on the MAIL FROM) until  after the RCPT TO is specified so that the MTA can determine the    for the relevant destination channel.

Related to the above effects, is the fact that messages rejected due to the   MTA option, or  similarly due to the    channel option, do not necessarily result in a  "J" rejection entry in the    file, since  potentially a client/sender-SMTP doesn&#x27;t even bother to submit a  message when it sees the advertised size limit. Or even if the MTA does perform a "rejection" itself, it may occur at the MAIL FROM  stage (if the client uses the SIZE SMTP extension to include the  expected message size on the MAIL FROM command line); this is before  the MTA has its normal log information (such as receipient  information), but will nevertheless be logged as a "J" record  (missing some fields such as recipient fields) as of MS 6.0 and  later. (In earlier versions, such rejections at the MAIL FROM stage would not be recorded in a   record; in  particular, would not cause a "J" record to be generated.)  This contrasts with messages rejected due to   on  the destination channel which do, and have even in older versions, get  logged as "J" entries with recipient field(s) filled in  "normally".

(Note also that the    channel option, if used, may modify the timing and form of rejections due to exceeding message size constraints.)

See also:
 * block_limit MTA Option
 * line_limit MTA Option
 * block_size MTA Option
 * ldap_domain_attr_blocklimit MTA Option
 * ldap_domain_attr_sourceblocklimit MTA Option
 * ldap_blocklimit MTA Option
 * ldap_sourceblocklimit MTA Option
 * ldap_maximum_message_size MTA Option
 * alias_blocklimit Option
 * alias_linelimit Option
 * Alias file named parameters
 * FROM_ACCESS mapping table
 * MTA transaction logging
 * acceptalladdresses Option
 * Size limits on messages channel options
 * Channel options