Triggering effects from transaction logging with LOG_ACTION

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


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

The LOG_ACTION 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'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 LOG_ACTION 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' outgoing messages, and react to "high" numbers as a possible sign of a user sending spam with a poor-quality recipient list.

LOG_ACTION operation

The LOG_ACTION mapping table is probed each time a message transaction or connection transaction log entry is written. At present the LOG_ACTION mapping table'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 *_ACCESS mapping tables and FROM_ACCESS mapping table: In particular, LOG_ACTION has the potential to generate syslog notices, or make call-outs such as to MeterMaid.

Probe format

The format of the LOG_ACTION probe for a message transaction log entry consists at a minimum of the following, plus additional, optional fields:


  source-channel|destination-channel|action|size|envelope-from|orig-envelope-to|current-envelope-to

Here action is the usually logged action code; (i.e., the ac attribute'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 log_* MTA options; usually bit 1 (value 2) for a log_* MTA option controls whether the field controlled by that option is included in the LOG_ACTION probe. For log_connection, where bit 1 already has another meaning, bit 8 (value 256) enables inclusion of the claimed source system (as claimed in the client's the HELO/EHLO command for SMTP channels, or the enqueueing channel's official host name for other types of channels), and the bit that enables inclusion of application-info and transport-info in the LOG_ACTION probe is bit 9 (value 512); for log_intermediate, bits 2 and 3 (values 4 and 8, respectively) control the inclusion of fields in the probe. These optional fields consist of:


|notary-bits|filename|envelope-id|message-id|username|source-system|sensitivity
|mt-priority|priority|intermediate-dest|initial-dest|ldap-uid|imap-uid:uidvalidity
|future-release|filter|reason|diagnostics|remote-mta|isc-status
|application-info|transport-info|time-in-queue|conversion-tags|imap-flags
|delivery-flags

The source-system, and application-info and transport-info fields result from two bits of log_connection. The intermediate-dest and initial-dest fields result from two bits of log_intermediate. The rest of the fields result from, respectively, log_notary, log_filename, log_envelope_id, log_message_id, log_username, log_sensitivity, log_mtpriority, log_priority, log_uid, log_mailbox_uid, log_futurerelease, log_filter, log_reason, log_diagnostics, log_remote_mta, log_isc_status, log_queue_time, log_conversion_tag, log_imap_flags, and log_delivery_flags.

The format of the probe for a connection transaction log entry consists at a minimum of the following, plus additional, optional fields:

source-channel|direction|action

The direction is either + for inbound connections, or - for outbound connections. action is the usually logged connection action code, with the possible addition of an "F" suffix (on "C" or "X" action entries), added if the entry corresponds to a case where the MTA encountered an error with its attempt to create a *.data-failed file. The optional fields consist of any subset of:


|SASL-error-or-ETRN-host-name|username|extra|adminser|diagnostics|transport-info|application-info|queue-time

Optional fields are enabled by the relevant bit or bits of log_message_id (bit 1, value 2 enables logging of the SASL error in "U" SMTP AUTH records and the host name from client ETRN commands in "I" ETRN records), log_username (especially relevant for U SMTP AUTH records), log_conversion_tag (especially relevant for open/close SMTP records), log_diagnostics, log_connection (bit 9, value 512 enables both transport-info and application-info), and log_queue_time. 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.

LOG_ACTION mapping input flags
Flag Description
$| (New in MS 8.0.1.2) Set if one or more of the input strings contains a vertical bar character. (A vertical bar in an input string has the potential of being misinterpreted as a delimiter.)
$R (New in MS 8.0.1.2) Set if the source channel is an "internal" channel and the MTA is operating in reprocessing mode.
$S (New in MS 8.0.2.3) Set if the per-entry save flag is set and the entry is going to be written to the log file; clear otherwise.

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 LOG_ACTION 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.

LOG_ACTION mapping output flags
Flag Description
$F Disable writing this entry to the transaction log file
$N Disable writing this entry to the transaction log file
$+| Causes any syslog message produced by $< or $> to consume all remaining arguments as well as including the vertical bars themselves.
Output flags with arguments, in argument reading order1
$Tprobe-⁠tag (New in MS 8.0) (Only takes effect for message transaction probes, not connection transaction probes.) Prefix subsequent *_ACCESS mapping table probes with the tag probe-tag. The last such tag may optionally be prepended to the AUTH_REWRITE mapping table probe.
$DN (New in MS 8.0.1.2) Delay the session after logging operation is complete. The delay is controlled by the signed integer parameter value N. Positive values of N specify the number of centiseconds to delay; if multiple log records are being written as part of a transaction the value associated with the last matching probe is used. Negative values of N are cumulative; the absolute values of matching probes are added together to produce the number of centiseconds to delay.
$<string Send string to syslog (UNIX) if probe matches; see also the sndopr_priority MTA option.
$>string Send string to syslog (UNIX) if access is rejected; see also the sndopr_priority MTA option.

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 LOG_ACTION use

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

Disabling logging of connections from a periodic monitoring source

One use of LOG_ACTION 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 monitor-ip, then set bit 9 (value 512) of the log_connection MTA option and then use a LOG_ACTION 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

  *|*|O|*|monitor-ip|*     $N
  *|*|C|*|monitor-ip|*     $N


Syslog notices after SMTP AUTH attempts with bad password

One use of LOG_ACTION 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 LOG_ACTION, and then generating the syslog notice when MeterMaid's threshold is reached.

First, in the MTA option file make sure that appropriate data will be included in the LOG_ACTION mapping table probes by setting log_* MTA options as below, and set sndopr_priority to values for syslog facility and severity that will coordinate with your syslog.conf configuration for syslog notice handling:


# msconfig
msconfig> show log_connection
role.mta.log_connection = 6
instance.channel:tcp_monitor.log_connection = 0
msconfig> set mta.log_connection 134
msconfig# write -remark="Set bit 7/value 128 of log_connection to get U connection records"
msconfig> 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> set sndopr_priority 20
msconfig> set sndopr_prefix ""
msconfig# write -remark="MTA syslog notices to get LOG_MAIL+LOG_WARNING syslog.conf handling"
msconfig> quit
#

In legacy configuration mode, this would correspond to setting MTA options in the option.dat 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 log_* option values set so that regular MTA connection transaction log entries will be generated as well as fields in LOG_ACTION probes; but in principle, the LOG_ACTION probes could be set without having to enable the connection transaction logging.)

To have a MeterMaid table named bad_password_attempts, configure MeterMaid with a new table via:


# msconfig
msconfig> ! First check if MeterMaid has had basic configuration:
msconfig> show metermaid.*
role.metermaid_client.server_host = host-name
role.metermaid.enable = 1
role.metermaid.secret (suppressed)
msconfig> ! Yes, MeterMaid basics already configured; 
msconfig> ! so now add a new bad_password_attempts table
msconfig> 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> quit
#

In legacy configuration mode, (assuming basic MeterMaid configuration had already been performed via additional configutil parameters not shown below), this would correspond to a MeterMaid table configured via configutil 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 LOG_ACTION 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|direction|action|SASL-error|username|diagnostics
!
  tcp_*|+|U|Bad$ password$_*|$_*|*   \
$[IMTA_LIB:check_metermaid.so,throttle,bad_password_attempts,$1]$<LOGACTION,$ \
Too$ many$ bad$ password$ attempts$ for$ user$ $1

There is a subtlety in the above, which is that log_diagnostics is shown being set purely to ensure that there is at least one more vertical bar and (possibly empty) field appearing after the username field. Furthermore, asterisk wildcard for matching the username 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.

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
msconfig> show log_connection
role.mta.log_connection = 2
msconfig> 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> 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> 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 bad_user_attempts, configure MeterMaid with a new table via:


# msconfig
msconfig> ! First check if MeterMaid has had basic configuration:
msconfig> show metermaid.*
role.metermaid_client.server_host = host-name
role.metermaid.enable = 1
role.metermaid.secret (suppressed)
msconfig> ! Yes, MeterMaid basics already configured; 
msconfig> ! so now add a new bad_user_attempts table
msconfig> 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> quit
#

In legacy configuration mode, (assuming basic MeterMaid configuration had already been performed via additional configutil parameters not shown below), this would correspond to a MeterMaid table configured via configutil 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 LOG_ACTION 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|direction|action|SASL-error|username|diagnostics|transport-info
! where transport-info is:  TCP|host-IP|host-port|source-IP|source-port
!
  tcp_*|+|U|No$ such$ user|*|*|TCP|$_*|$_*|$_*|*   \
$[IMTA_LIB:check_metermaid.so,throttle,bad_user_attempts,$5]$<LOGACTION,$ \
Too$ many$ wrong$ username$ attempts$ from$ $5$ (username$ attempted:$ $1)
 

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) remove routine of MeterMaid to achieve a "reset" effect after desired "good" occurrences. For instance, with settings as above (including log_diagnostics=3 and log_connection=642):


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|direction|action|SASL-error|username|diagnostics|transport-info
! where transport-info is:  TCP|host-IP|host-port|source-IP|source-port
!
  tcp_*|+|U|Bad$ password|$_*|*    \
$[IMTA_LIB:check_metermaid.so,throttle,bad_password_attempts,$1]$<LOGACTION,$ \
Too$ many$ bad$ password$ attempts$ for$ user$ $1
  tcp_*|+|U|No$ such$ user|*|*|TCP|$_*|$_*|$_*|*    \
$[IMTA_LIB:check_metermaid.so,throttle,bad_user_attempts,$5]$<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_*|+|U|*|*|*authentication$ successful*|TCP|$_*|$_*|$_*|*  $CCLEAR|$2|$7
!
! If the authentication was successful, then the probe is now:
! CLEAR|username|source-ip
!
  CLEAR|*|*  \
$CCLEAR|$0|$1$[IMTA_LIB:check_metermaid.so,remove,bad_password_attempts,$0]
  CLEAR|*|*    $[IMTA_LIB:check_metermaid.so,remove,bad_user_attempts,$1]

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 log_reason=3): as of Messaging Server 7.3-11.01, the reason field in cases of successful authentication would either be "authentication successful" or "authentication successful - switched to channel channel-name". (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'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 ZZ* 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|dest-chan|D|size|env-from|orig-env-to|env-to|filename|queue-time
!
  *|*|D*|*|*|*|*@*|ZZ*|*   $CDEQUEUEDOMAINTIME|$7|$9
!
! Now probing with just DEQUEUEDOMAINTIME|domain|queue-time
!
  DEQUEUEDOMAINTIME|*|*    $CFASTDOMAIN|$`integer($1)<=60'|$0|$1
!
! Now the probe will be FASTDOMAIN|1|domain|queue-time for queue-time<=60s
! or FASTDOMAIN|0|domain|queue-time for queue-time>60
!
  FASTDOMAIN|1|*|*         \
$[IMTA_LIB:check_metermaid.so,remove,slow_delivery,$0]
  FASTDOMAIN|0|*|*         $CSLOWDOMAIN|$`integer($1)>=300'|$0|$1
!
! Now the probe will be SLOWDOMAIN|1|domain|queue-time for queue-time>=300s
! or SLOWDOMAIN|0|domain|queue-time for 60s<queue-time<300s
!
  SLOWDOMAIN|1|*|*         \
$[IMTA_LIB:check_metermaid.so,throttle,slow_delivery,$0]$<LOGACTION,$ \
Domain$ $0$ deliveries$ slow

The above example uses the mapping table expression substitution syntax, $`expression', to perform a test on the value of the queue-time (time in queue) field: such an expression will evaluate to 1 if true, 0 if false, so such an expression substitution inserts the string 1 if the numeric test was true or inserts the string 0 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 LOG_ACTION is to update a MeterMaid table with information relating to message dequeue, which a message enqueue access mapping table can then consult. That is, LOG_ACTION 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> show log_*
role.mta.log_diagnostics = 3
role.mta.log_reason = 3
role.mta.log_username = 3
...and likely additional log_* MTA options settings...

and configutil 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 LOG_ACTION mapping table to track in MeterMaid bad recipient addresses discovered at dequeue time, and a corresponding FROM_ACCESS mapping table that checks that MeterMaid data to decide whether to allow new message submissions, could be:


LOG_ACTION

! source-chan|dest-chan|action|size|env-from|orig-env-to|env-to|
!  username|reason|diagnostics
!
  tcp_local||R*|*|*|*|*|$**|Remote$ SMTP$ server$ has$ rejected$ address|*  \
$[IMTA_LIB:check_metermaid.so,throttle,sends_to_bogus_recipients,$5]
  tcp_local||K*|*|*|*|*|$**|Remote$ SMTP$ server$ has$ rejected$ address|*  \
$[IMTA_LIB:check_metermaid.so,throttle,sends_to_bogus_recipients,$5]

FROM_ACCESS

  TCP|*|*|*|*|SMTP*|MAIL|tcp_auth|*|*   \
$[IMTA_LIB:check_metermaid.so,test,sends_to_bogus_recipients,$6,>=15]$NYou$ \
have$ sent$ to$ too$ many$ bad$ addresses$ today
 

Note that since in the logging (MTA transaction log entries and hence the LOG_ACTION field) the username field resulting from SMTP AUTH authentication is actually the mail attribute value with the asterisk character prefixed, whereas in FROM_ACCESS the "username" field is simply the pure mail attribute value, above in LOG_ACTION 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 FROM_ACCESS 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 LOG_ACTION is to throttle submissions from senders who cause many "J" records (rejections of attempted submissions).

So with deferralrejectlimit 4 set on the tcp_local channel, and with MTA options settings that include:


LOG_CONNECTION=515
LOG_DIAGNOSTICS=3

or in Unified Configuration


msconfig> show log_*
role.mta.log_connection = 515
role.mta.log_diagnostics = 3
...and likely additional log_* MTA options settings...

and configutil 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 LOG_ACTION mapping table to track in MeterMaid "J" records, and a corresponding PORT_ACCESS mapping table that checks that MeterMaid data to decide whether or not to allow connections, could be:


PORT_ACCESS

 *|*|*|*|*  $C$|INTERNAL_IP;$3|$Y$E
 TCP|*|*|*|* \
$:A$C$[IMTA_LIB:check_metermaid.so,test,J-jail,$2,>0]$N$2-blocked2$E
 *  $YEXTERNAL

DONT_JAIL

 $<10.0.0.0/24> $N
 * $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|*|J*|*|rfc822;|*|451$ 4.5.3$ Too$ many$ rejections;$ \
try$ again$ later.*|TCP|*|*|*|*|SMTP \
$C$|DONT_JAIL;$6|\
$[IMTA_LIB:check_metermaid.so,throttle,j-by-ip,$6]\
$[IMTA_LIB:check_metermaid.so,throttle,j-jail,$6]$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 MAX_J_ENTRIES 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_*|+|U|*|535*      $D300

A three second delay would follow any failed authentication attempt.


See also: