Triggering effects from transaction logging with LOG ACTION

( itself was added in   Messaging Server 7.0-3.01. But use of    with MeterMaid---other than simple "throttle" calls -- typically requires MeterMaid features new in   Messaging Server 7.2-0.01. In particular, MeterMaid " " and  " " routines are new in  Messaging Server 7.2-0.01.)

The mapping table  provides a way for any transactions recorded by the MTA  to also, as a side-effect, trigger other effects. A great deal of information, of different types, can be reported in the MTA&#x27;s message transaction and connection transaction log files. Sites may be interested in noticing certain sorts of log entries as evidence of certain sorts of occurrences, or counting (or at least monitoring trends for) certain sorts of occurrences, or making access decisions based on certain sorts of occurrences. The  mapping table provides a way to turn MTA message transaction and connection transaction log file entries into syslog notices, or into MeterMaid counter updates; or if a site wishes to provide their own routine for the mapping table to call, to take whatever, site-defined "action" the site chooses, based upon relevant transaction log entries. For instance, a site might want to notice (via a syslog notice) failed SMTP AUTH attempts as a warning of possible account break-in attempt; or a site might want to count (via MeterMaid) the number of failed (bad) recipients for users&#x27; outgoing messages, and react to "high" numbers as a possible sign of a user sending spam with a poor-quality recipient list.

operation
The  mapping table  is probed each time a  message transaction or connection transaction log entry is written. At present the  mapping table&#x27;s only direct effect on the normal transaction log entries is its ability to disable output (recording) of specified entries. But its more interesting uses tend to be for its "side effects", which can be considered rather similar to the "side effects" available for the address based    mapping tables and   mapping table: In particular,   has the potential to generate syslog notices, or make call-outs such as to  MeterMaid.

Probe format
The format of the  probe  for a message transaction log entry consists at a minimum of the following, plus additional, optional fields: source-channel&#x7c;destination-channel&#x7c;action&#x7c;size&#x7c;envelope-from&#x7c;orig-envelope-to&#x7c;current-envelope-to Here   is the usually logged action code; (i.e., the  attribute&#x27;s value in  XML format MTA transaction logging). Additional log entry fields may be included in the probe, depending upon the setting of the corresponding   MTA options;  usually bit 1 (value 2) for a   MTA option controls whether the field controlled by that option is included in the   probe. For, where bit 1  already has another meaning, bit 8 (value 256) enables inclusion of the claimed source system (as claimed in the client&#x27;s the HELO/EHLO command for SMTP channels, or the enqueueing channel&#x27;s official host name for other types of channels), and the bit that enables inclusion of   and    in the   probe is  bit 9 (value 512); for  ,  bits 2 and 3 (values 4 and 8, respectively) control the inclusion of fields in the probe. These optional fields consist of: &#x7c;notary-bits&#x7c;filename&#x7c;envelope-id&#x7c;message-id&#x7c;username&#x7c;source-system&#x7c;sensitivity &#x7c;mt-priority&#x7c;priority&#x7c;intermediate-dest&#x7c;initial-dest&#x7c;ldap-uid&#x7c;imap-uid:uidvalidity &#x7c;future-release&#x7c;filter&#x7c;reason&#x7c;diagnostics&#x7c;remote-mta&#x7c;isc-status &#x7c;application-info&#x7c;transport-info&#x7c;time-in-queue&#x7c;conversion-tags&#x7c;imap-flags &#x7c;delivery-flags The  , and   and   fields result from two bits of. The   and   fields result from two bits of. The rest of the fields result from, respectively,,   ,   ,   ,  ,   ,  ,  ,   ,  ,  ,  ,   ,  ,  ,  ,  ,  ,  , and.

The format of the probe for a connection transaction log entry consists at a minimum of the following, plus additional, optional fields: source-channel&#x7c;direction&#x7c;action The   is either  for inbound connections, or   for outbound connections.   is the usually logged connection action code, with the possible addition of an " " suffix (on " " or " " action entries), added if the entry corresponds to a case where the MTA encountered an error with its attempt to create a   file. The optional fields consist of any subset of: &#x7c;SASL-error-or-ETRN-host-name&#x7c;username&#x7c;extra&#x7c;adminser&#x7c;diagnostics&#x7c;transport-info&#x7c;application-info&#x7c;queue-time Optional fields are enabled by the relevant bit or bits of   (bit 1, value 2 enables logging of the SASL error in " " SMTP AUTH records and the host name from client ETRN commands in " " ETRN records),     (especially relevant for U SMTP AUTH records),    (especially relevant for open/close SMTP records), ,     (bit 9, value 512 enables both   and  ),  and. Note that the same bit (or bits) enable probe inclusion both for message transaction probes and connection transaction probes.

Mapping input flags are described in the following table.

If the probe string matches the pattern (i.e., the left hand side of an entry in the mapping table), then the resulting output template (right hand side) is checked. The output templates in the  mapping table can use the special flags defined in  the table below, as well, of course, as any general mapping table  substitutions or metacharacters such as calling  out to a routine.

 1To use multiple flags with arguments, separate the arguments with the  vertical bar character, , placing the arguments in the  order listed in this table.

Examples of use
This section shows examples of some possible uses of the  mapping table. The syntax and general operation of the  mapping table is discussed above. The first example below is a very simple use to disable recording of certain entries. The additional  examples below are more sophisticated,  making use of MeterMaid callouts.

Disabling logging of connections from a periodic monitoring source
One use of  is to disable logging of some particular type of entry, while still retaining logging in general: for instance, connection attempts from some special source, when such connections are performed merely for "monitoring" or "heartbeat" reasons, may not deserve to be recorded.

For instance, if the monitor source IP is  , then set bit 9 (value 512) of the  MTA option and then  use a   mapping table along the lines of that shown below to disable the logging of the connection "O"pen and connection "C"lose records generated by the monitoring probe connections. LOG_ACTION &#x2a;&#x7c;&#x2a;&#x7c;O&#x7c;&#x2a;&#x7c;monitor-ip&#x7c;&#x2a;    $N &#x2a;&#x7c;&#x2a;&#x7c;C&#x7c;&#x2a;&#x7c;monitor-ip&#x7c;&#x2a;    $N

 Syslog notices after SMTP AUTH attempts with bad password
One use of  might be to generate a syslog notice if more than some site-chosen number of bad password SMTP AUTH attempts are made against any user account. This can be achieved by calling out to MeterMaid from, and then generating the syslog notice when MeterMaid&#x27;s threshold is reached.

First, in the MTA option file make sure that appropriate data will be included in the  mapping table probes by setting    MTA options as below, and set    to values for syslog facility and severity that will coordinate with your   configuration for syslog notice handling: msconfig&#x3e; show log_connection role.mta.log_connection = 6 instance.channel:tcp_monitor.log_connection = 0 msconfig&#x3e; set mta.log_connection 134 msconfig# write -remark="Set bit 7/value 128 of log_connection to get U connection records" msconfig&#x3e; set log_message_id 3 msconfig# set log_username 3 msconfig# set log_diagnostics 3 msconfig# write -remark="Enable more fields in LOG_ACTION probes" msconfig&#x3e; set sndopr_priority 20 msconfig&#x3e; set sndopr_prefix "" msconfig# write -remark="MTA syslog notices to get LOG_MAIL+LOG_WARNING syslog.conf handling" msconfig&#x3e; quit # In legacy configuration mode, this would correspond to setting MTA options in the  file along the lines of: ! Sites likely want additional bits of LOG_CONNECTION set; this example ! requires that bit 7/value 128 be set. ! LOG_CONNECTION=128 LOG_MESSAGE_ID=3 LOG_USERNAME=3 LOG_DIAGNOSTICS=3 ! ! Set SNDOPR_PRIORITY to a syslog facility+severity value that will ! coordinate with your syslog.conf configuration, e.g. ! SNDOPR_PRIORITY=20 to choose LOG_MAIL+LOG_WARNING syslog.conf handling. ! SNDOPR_PRIORITY=20 ! ! Eliminate the syslog prefix ! SNDOPR_PREFIX= (The above settings represent likely site practice, rather than what is strictly required, as they show  option values set so that regular MTA connection transaction log entries will be generated as well as fields in   probes; but in principle, the   probes could be set without having to enable the connection transaction logging.)
 * 1) msconfig

To have a MeterMaid  table named , configure MeterMaid with a new table via: msconfig&#x3e; ! First check if MeterMaid has had basic configuration: msconfig&#x3e; show metermaid.&#x2a; role.metermaid_client.server_host = host-name role.metermaid.enable = 1 role.metermaid.secret (suppressed) msconfig&#x3e; ! Yes, MeterMaid basics already configured; msconfig&#x3e; ! so now add a new bad_password_attempts table msconfig&#x3e; set metermaid.local_table:bad_password_attempts.data_type string msconfig# set metermaid.local_table:bad_password_attempts.max_entries 1000 msconfig# set metermaid.local_table:bad_password_attempts.table_options "nocase penalize" msconfig# set metermaid.local_table:bad_password_attempts.table_type throttle msconfig# set metermaid.local_table:bad_password_attempts.quota 5 msconfig# set metermaid.local_table:bad_password_attempts.quota_time 3600 msconfig# write -remark="Added bad_password_attempts MeterMaid table" msconfig&#x3e; quit # In legacy configuration mode, (assuming basic MeterMaid configuration had already been performed via additional   parameters not shown below), this would correspond to a MeterMaid table configured via   values, including these (though note that many of the values shown being set are actually defaults): metermaid.table.bad_password_attempts.data_type: string metermaid.table.bad_password_attempts.max_entries: 1000 metermaid.table.bad_password_attempts.options: nocase,penalize metermaid.table.bad_password_attempts.type: throttle metermaid.table.bad_password_attempts.quota: 5 metermaid.table.bad_password_attempts.quota_time: 3600 Then a   mapping table  to make use of that MeterMaid table could be as follows: LOG_ACTION ! With log_connection=128 set, we get "U" action records. ! With log_message_id=3 set, the SASL-error is recorded in the message-id field ! With log_username=3, get a username field ! With log_diagnostics=3, get a diagnostics field ! ! So probe format is: ! ! source-chan&#x7c;direction&#x7c;action&#x7c;SASL-error&#x7c;username&#x7c;diagnostics !  tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;Bad$ password$_&#x2a;&#x7c;$_&#x2a;&#x7c;&#x2a;   \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,bad_password_attempts,$1&#x5d;$&#x3c;LOGACTION,$ \ Too$ many$ bad$ password$ attempts$ for$ user$ $1 There is a subtlety in the above, which is that   is shown being set purely to ensure that there is at least one more vertical bar and (possibly empty) field appearing after the   field. Furthermore, asterisk wildcard for matching the   field has the "minimal matching"  modifier set on it.) This is not strictly necessary for this exact example, but makes this example easier to extend with additional fields should sites wish to do so.
 * 1) msconfig

There is also a prior  match in the reason field portion of the pattern, just after "Bad$ password"; that is necessary as of 8.0 when additional detail text was added to the reason field.

Syslog notices after SMTP AUTH attempts with bad username
Another example would be to generate a syslog notice if the same source IP makes multiple attempts to authenticate with a bad username (hence suggestive of a possible "dictionary attack" against your user name space). With MTA options settings of: msconfig&#x3e; show log_connection role.mta.log_connection = 2 msconfig&#x3e; set mta.log_connection 642 msconfig# write -remark="Set bit 1/value 2 plus bit 7/value 128 plus bit 9/value 512 of mta.log_connection to get O and C plus U connection records,   plus application and transport fields included in LOG_ACTION probes" msconfig&#x3e; set log_message_id 3 msconfig# set log_username 3 msconfig# set log_diagnostics 3 msconfig# write -remark="Enable extra fields in LOG_ACTION probes" msconfig# set sndopr_priority 20 msconfig# write -remark="MTA syslog notices to get LOG_MAIL+LOG_WARNING syslog.conf handling" msconfig&#x3e; quit # Or in legacy configuration mode: ! Sites likely want additional bits of LOG_CONNECTION set; this example ! requires that bit 1/value 2 plus bit 7/value 128 plus bit 9/value 512 be set. LOG_CONNECTION=642 LOG_MESSAGE_ID=3 LOG_USERNAME=3 LOG_DIAGNOSTICS=3 ! ! Set SNDOPR_PRIORITY to a syslog facility+severity value that will ! coordinate with your syslog.conf configuration, e.g. ! SNDOPR_PRIORITY=20 to choose LOG_MAIL+LOG_WARNING syslog.conf handling. ! SNDOPR_PRIORITY=20 To have a MeterMaid table named, configure MeterMaid with a new table via: msconfig&#x3e; ! First check if MeterMaid has had basic configuration: msconfig&#x3e; show metermaid.&#x2a; role.metermaid_client.server_host = host-name role.metermaid.enable = 1 role.metermaid.secret (suppressed) msconfig&#x3e; ! Yes, MeterMaid basics already configured; msconfig&#x3e; ! so now add a new bad_user_attempts table msconfig&#x3e; set metermaid.local_table:bad_user_attempts.data_type ipv4 msconfig# set metermaid.local_table:bad_user_attempts.max_entries 1000 msconfig# set metermaid.local_table:bad_user_attempts.table_options "penalize" msconfig# set metermaid.local_table:bad_user_attempts.table_type throttle msconfig# set metermaid.local_table:bad_user_attempts.quota 5 msconfig# set metermaid.local_table:bad_user_attempts.quota_time 3600 msconfig# write -remark="Added bad_user_attempts MeterMaid table" msconfig&#x3e; quit # In legacy configuration mode, (assuming basic MeterMaid configuration had already been performed via additional  parameters not shown below), this would correspond to a MeterMaid table configured via   values including: metermaid.table.bad_user_attempts.data_type: ipv4 metermaid.table.bad_user_attempts.max_entries: 1000 metermaid.table.bad_user_attempts.options: penalize metermaid.table.bad_user_attempts.type: throttle metermaid.table.bad_user_attempts.quota: 5 metermaid.table.bad_user_attempts.quota_time: 3600 then a  mapping table could be: LOG_ACTION ! With log_connection=642 set, we get "U" action records and transport-info ! fields. ! With log_message_id=3 set, the SASL-error is recorded in the message-id field ! With log_username=3, get a username field ! With log_diagnostics=3, get a diagnostics field ! ! So probe format is: ! ! source-chan&#x7c;direction&#x7c;action&#x7c;SASL-error&#x7c;username&#x7c;diagnostics&#x7c;transport-info ! where transport-info is: TCP&#x7c;host-IP&#x7c;host-port&#x7c;source-IP&#x7c;source-port !  tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;No$ such$ user&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;TCP&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;&#x2a;   \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,bad_user_attempts,$5&#x5d;$&#x3c;LOGACTION,$ \ Too$ many$ wrong$ username$ attempts$ from$ $5$ (username$ attempted:$ $1)
 * 1) msconfig
 * 1) msconfig

Syslog notices after failing SMTP AUTH attempts, resetting after success
Both of the above examples could be improved by using the  (new in 7.2-0.01)    routine of MeterMaid to achieve a "reset" effect after desired "good" occurrences. For instance, with settings as above (including   and  ): LOG_ACTION ! With log_connection=642 set, we get "U" action records and transport-info ! fields. ! With log_message_id=3 set, the SASL-error is recorded in the message-id field ! With log_username=3, get a username field ! With log_diagnostics=3, get a diagnostics field ! ! So probe format is: ! ! source-chan&#x7c;direction&#x7c;action&#x7c;SASL-error&#x7c;username&#x7c;diagnostics&#x7c;transport-info ! where transport-info is: TCP&#x7c;host-IP&#x7c;host-port&#x7c;source-IP&#x7c;source-port !  tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;Bad$ password&#x7c;$_&#x2a;&#x7c;&#x2a;    \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,bad_password_attempts,$1&#x5d;$&#x3c;LOGACTION,$ \ Too$ many$ bad$ password$ attempts$ for$ user$ $1 tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;No$ such$ user&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;TCP&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;&#x2a;   \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,bad_user_attempts,$5&#x5d;$&#x3c;LOGACTION,$ \ Too$ many$ wrong$ username$ attempts$ from$ $5$ (username$ attempted:$ $1) ! ! Once a successful AUTH occurs, remove the entry for that username in the ! bad_password_attempts table, and remove the entry for that source IP in ! the bad_user_attempts table. We want to try to remove the source IP entry in ! the second table, even if (for some reason) the MeterMaid callout on the ! first fails, so we split the store calls into two separate entries, rather ! than attempting two routine calls from one right hand side. !  tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;authentication$ successful&#x2a;&#x7c;TCP&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;$_&#x2a;&#x7c;&#x2a;  $CCLEAR&#x7c;$2&#x7c;$7 ! ! If the authentication was successful, then the probe is now: ! CLEAR&#x7c;username&#x7c;source-ip !  CLEAR&#x7c;&#x2a;&#x7c;&#x2a;  \ $CCLEAR&#x7c;$0&#x7c;$1$&#x5b;IMTA_LIB:check_metermaid.so,remove,bad_password_attempts,$0&#x5d; CLEAR&#x7c;&#x2a;&#x7c;&#x2a;   $&#x5b;IMTA_LIB:check_metermaid.so,remove,bad_user_attempts,$1&#x5d; In the above example, it is convenient to detect successful authentication via the diagnostics field (the SMTP response). However, as of Messaging Server 7.3-11.01, an equivalent approach would be to detect successful authentication via the reason field (and use  ): as of  Messaging Server 7.3-11.01, the reason field in cases of successful authentication would either be  " " or " ". (In prior versions, the reason field confounded some cases.)

Syslog notices when time-in-queue becomes "high", ceasing after any quick delivery
(Note that this example uses the MeterMaid "remove" routine, new in  Messaging Server 7.2-0.01.)  Another example of generating syslog notices when some condition occurs, and then resetting the MeterMaid table entry (and hence stopping the syslog notices) when the condition ceases, would be for cases where messages, while getting delivered upon first delivery attempt, are not getting delivered sufficiently promptly for the site&#x27;s taste. That is, considering only messages that actually do manage to get delivered upon first attempt rather than failing a delivery attempt and having to be retried later (hence inherently taking a relatively "long" time to be delivered), the site wishes to watch for cases where that initial, successful, delivery attempt nevertheless was rather "slow". Here we will record in MeterMaid the destination domain for each new  message whose delivery is "slow" (taking 300 seconds or more), and generate a syslog notice for such domains once 5 messages have been slow within an hour (3600 seconds), but reset (to 0) the MeterMaid table entry for that domain once a "quick delivery" (within 60 seconds) has occurred. LOG_FILENAME=3 LOG_QUEUE_TIME=3 ! ! Set SNDOPR_PRIORITY to a syslog facility+severity value that will ! coordinate with your syslog.conf configuration, e.g. ! SNDOPR_PRIORITY=20 to choose LOG_MAIL+LOG_WARNING syslog.conf handling. ! SNDOPR_PRIORITY=20 metermaid.table.slow_delivery.data_type: string metermaid.table.slow_delivery.max_entries: 2000 metermaid.table.slow_delivery.options: nocase metermaid.table.slow_delivery.type: throttle metermaid.table.slow_delivery.quota: 5 metermaid.table.slow_delivery.quota_time: 3600 LOG_ACTION ! source-chan&#x7c;dest-chan&#x7c;D&#x7c;size&#x7c;env-from&#x7c;orig-env-to&#x7c;env-to&#x7c;filename&#x7c;queue-time !  &#x2a;&#x7c;&#x2a;&#x7c;D&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;ZZ&#x2a;&#x7c;&#x2a;   $CDEQUEUEDOMAINTIME&#x7c;$7&#x7c;$9 ! ! Now probing with just DEQUEUEDOMAINTIME&#x7c;domain&#x7c;queue-time !  DEQUEUEDOMAINTIME&#x7c;&#x2a;&#x7c;&#x2a;    $CFASTDOMAIN&#x7c;$`integer($1)&#x3c;=60&#x27;&#x7c;$0&#x7c;$1 ! ! Now the probe will be FASTDOMAIN&#x7c;1&#x7c;domain&#x7c;queue-time for queue-time&#x3c;=60s ! or FASTDOMAIN&#x7c;0&#x7c;domain&#x7c;queue-time for queue-time&#x3e;60 !  FASTDOMAIN&#x7c;1&#x7c;&#x2a;&#x7c;&#x2a;         \ $&#x5b;IMTA_LIB:check_metermaid.so,remove,slow_delivery,$0&#x5d; FASTDOMAIN&#x7c;0&#x7c;&#x2a;&#x7c;&#x2a;        $CSLOWDOMAIN&#x7c;$`integer($1)&#x3e;=300&#x27;&#x7c;$0&#x7c;$1 ! ! Now the probe will be SLOWDOMAIN&#x7c;1&#x7c;domain&#x7c;queue-time for queue-time&#x3e;=300s ! or SLOWDOMAIN&#x7c;0&#x7c;domain&#x7c;queue-time for 60s&#x3c;queue-time&#x3c;300s !  SLOWDOMAIN&#x7c;1&#x7c;&#x2a;&#x7c;&#x2a;         \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,slow_delivery,$0&#x5d;$&#x3c;LOGACTION,$ \ Domain$ $0$ deliveries$ slow The above example uses the mapping table expression substitution syntax,, to perform a test on the value of the   (time in queue) field: such an expression will evaluate to 1 if true, 0 if false, so such an expression substitution inserts the string   if the numeric test was true or inserts the string   if the numeric test was false.

Blocking submissions of local senders who may be spammers
(Note that this example uses the MeterMaid "test" routine, new in Messaging Server 7.0 update 2.) A different type of use of  is to update a MeterMaid table with information relating to message dequeue, which a message enqueue access mapping table can then consult. That is,  with MeterMaid can provide a way for decisions on allowing message enqueue to reference historical data regarding message dequeue. For instance, a local user whose outbound to the Internet messages suffer a high number of rejections of bad addresses by remote destinations may raise the suspicion that that user is attempting to send spam using a poor quality recipient list; a site may wish to deny that account further submissions that day.

For any such access restrictions on senders, it is always strongly advisable to require local users to authenticate (use SMTP AUTH) in order to submit messages, and then to perform the access checks using the authenticated submission address. Because the SMTP envelope From is easy to forge in the base SMTP protocol, attempts to enforce access restrictions based solely upon envelope From are regrettably likely to unintentionally encourage (or at least motivate) users to forge their envelope From as a way to bypass the access restrictions. Thus poorly considered access restrictions on senders can cause more harm than good, by motivating users to obscure their identity to evade the restrictions. So this example will assume that a security-conscious configuration, where users are required to use SMTP AUTH to submit, is already in place, so that authentication information is available both for logging via the LOG_USERNAME MTA option, and for performing an access check from the FROM_ACCESS mapping table.

So with MTA options settings that include (legacy configuration style): ! Bit 1/value 2 is not set in any of: ! LOG_NOTARY, LOG_FILENAME, LOG_ENVELOPE_ID, or LOG_MESSAGE_ID LOG_REASON=3 LOG_USERNAME=3 LOG_DIAGNOSTICS=3 or in Unified Configuration: msconfig&#x3e; show log_&#x2a; role.mta.log_diagnostics = 3 role.mta.log_reason = 3 role.mta.log_username = 3 ...and likely additional log_&#x2a; MTA options settings... and  MeterMaid table settings that, in addition to basic configuration not shown here, include: metermaid.table.sends_to_bogus_recipients.data_type: string metermaid.table.sends_to_bogus_recipients.max_entries: 5000 metermaid.table.sends_to_bogus_recipients.options: nocase,penalize metermaid.table.sends_to_bogus_recipients.type: throttle metermaid.table.sends_to_bogus_recipients.quota: 15 metermaid.table.sends_to_bogus_recipients.quota_time: 86400 then a  mapping table to track in MeterMaid bad recipient addresses discovered at dequeue time, and a corresponding   mapping table that checks that MeterMaid data to decide whether to allow new message submissions, could be: LOG_ACTION ! source-chan&#x7c;dest-chan&#x7c;action&#x7c;size&#x7c;env-from&#x7c;orig-env-to&#x7c;env-to&#x7c; ! username&#x7c;reason&#x7c;diagnostics !  tcp_local&#x7c;&#x7c;R&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;$&#x2a;&#x2a;&#x7c;Remote$ SMTP$ server$ has$ rejected$ address&#x7c;&#x2a;  \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,sends_to_bogus_recipients,$5&#x5d; tcp_local&#x7c;&#x7c;K&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;$&#x2a;&#x2a;&#x7c;Remote$ SMTP$ server$ has$ rejected$ address&#x7c;&#x2a; \ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,sends_to_bogus_recipients,$5&#x5d; FROM_ACCESS TCP&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;SMTP&#x2a;&#x7c;MAIL&#x7c;tcp_auth&#x7c;&#x2a;&#x7c;&#x2a;  \ $&#x5b;IMTA_LIB:check_metermaid.so,test,sends_to_bogus_recipients,$6,&#x3e;=15&#x5d;$NYou$ \ have$ sent$ to$ too$ many$ bad$ addresses$ today Note that since in the logging (MTA transaction log entries and hence the  field) the username field resulting from SMTP AUTH authentication is actually the   attribute value with the asterisk character prefixed, whereas in    the "username" field is simply the pure   attribute value, above in   the entries make sure to explicitly match the asterisk character and then not include it in the sends_to_bogus_recipients table updates, so that the   probes can match on just the username.

Blocking dictionary attack on user name space (botnet attack)
Automated spam engines may mount a so-called "dictionary attack", attempting to run quickly through possible recipient addresses when submitting messages. So a source that frequently submits messages with many bad (invalid) addresses in the local domain may be regarded with suspicion. One possible use of MeterMaid with    is to throttle submissions from senders who cause many  "J" records (rejections of attempted submissions).

So with   set on the   channel, and with MTA options settings that include: LOG_CONNECTION=515 LOG_DIAGNOSTICS=3 or in Unified Configuration msconfig&#x3e; show log_&#x2a; role.mta.log_connection = 515 role.mta.log_diagnostics = 3 ...and likely additional log_&#x2a; MTA options settings... and  MeterMaid table settings that, in addition to basic configuration not shown here, includes configuration of a MeterMaid "J-by-IP" table and a "J-jail" table: metermaid.table.J-by-IP.data_type: ipv4 metermaid.table.J-by-IP.max_entries: 10000 metermaid.table.J-by-IP.quota: 4 metermaid.table.J-by-IP.quota_time: 600 metermaid.table.J-jail.data_type: ipv4 metermaid.table.J-jail.max_entries: 10000 metermaid.table.J-jail.quota: 1 metermaid.table.J-jail.quota_time: 3600 or in Unified Configuration: metermaid.table.J-by-IP.data_type: ipv4 metermaid.table.J-by-IP.max_entries: 10000 metermaid.table.J-by-IP.quota: 4 metermaid.table.J-by-IP.quota_time: 600 metermaid.table.J-jail.data_type: ipv4 metermaid.table.J-jail.max_entries: 10000 metermaid.table.J-jail.quota: 1 metermaid.table.J-jail.quota_time: 3600 then a  mapping table to track in MeterMaid  "J" records, and a corresponding    mapping table that checks that MeterMaid data to decide whether or not to allow connections, could be: PORT_ACCESS &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $C$&#x7c;INTERNAL_IP;$3&#x7c;$Y$E TCP&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $:A$C$&#x5b;IMTA_LIB:check_metermaid.so,test,J-jail,$2,&#x3e;0&#x5d;$N$2-blocked2$E &#x2a; $YEXTERNAL DONT_JAIL $&#x3c;10.0.0.0/24&#x3e; $N &#x2a; $Y LOG_ACTION ! To count only the "J" records that exceeded the chosen toleration ! level of 3, we look for the deferralrejectlimit error text: ! tcp_local&#x7c;&#x2a;&#x7c;J&#x2a;&#x7c;&#x2a;&#x7c;rfc822;&#x7c;&#x2a;&#x7c;451$ 4.5.3$ Too$ many$ rejections;$ \ try$ again$ later.&#x2a;&#x7c;TCP&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;SMTP \ $C$&#x7c;DONT_JAIL;$6&#x7c;\ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,j-by-ip,$6&#x5d;\ $&#x5b;IMTA_LIB:check_metermaid.so,throttle,j-jail,$6&#x5d;$E The asterisk at the end of the diagnostic text is so that even a "final" "J" record for an SMTP session -- as when the TCP/IP-channel-specific option     is exceeded, resulting in some additional, extra text  -- will be counted.

Delay after bad username and password specified in SUBMIT
Given the following MTA option settings: LOG_CONNECTION=515 LOG_USERNAME=3 LOG_DIAGNOSTICS=3 And mapping: LOG_ACTION tcp_&#x2a;&#x7c;+&#x7c;U&#x7c;&#x2a;&#x7c;535&#x2a;     $D300 A three second delay would follow any failed authentication attempt.

See also:
 * MeterMaid
 * Mapping tables
 * Transaction logging MTA options
 * MTA transaction logging
 * sndopr_prefix MTA Option
 * sndopr_priority MTA Option
 * Recipient access mapping tables
 * FROM_ACCESS mapping table
 * PORT_ACCESS mapping table
 * deferralrejectlimit Option
 * Typical TCPIP channels and servers
 * MTA transaction log entry format
 * MAX_J_ENTRIES
 * MAX_H_ENTRIES