POSTFIX-LOGWATCH(1)

📦
version 7.15 · 2 versions
, in alpine 3.24, arch rolling, debian trixie, fedora 43, fedora 44, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 postfix-logwatch — bestie edition 💖

okay so you know postfix-logwatch(1), right? it's a Postfix log parser and analysis utility and honestly it's the moment. let's get into it 🫶

✨ NAME ✨

postfix-logwatch — a Postfix log parser and analysis utility 🦋

🌸 SYNOPSIS 🌸

postfix-logwatch [options] [logfile ...]

👑 DESCRIPTION 👑

okay so the postfix-logwatch(1) utility is a Postfix MTA log parser that produces summaries, details, and statistics about how your Postfix is actually doing. it's giving observability, no cap.

you can run it as a standalone program, or you can use it as a Logwatch filter module to produce Postfix summary and detailed reports from inside Logwatch. flexible queen 💅

postfix-logwatch is able to produce a wide range of reports, with data grouped and sorted as much as possible to reduce noise and highlight patterns. brief summary reports give you a quick overview of general Postfix operations and message delivery, calling out warnings that may require attention. detailed reports give you easy to scan, hierarchically-arranged and organized information, with as much or as little detail as you want. you control the vibe check 🔥

postfix-logwatch outputs two principal sections: a Summary section and a Detailed section. for readability and quick scanning, all event or hit counts appear in the left column, followed by a brief description of the event type, and finally additional statistics or count representations may appear in the rightmost column. it's giving organized, fr fr.

the following segment from a sample Summary report illustrates:

    ****** Summary ********************************************

          81   *Warning: Connection rate limit reached (anvil)
         146   Warned

      68.310M  Bytes accepted                        71,628,177
      97.645M  Bytes delivered                      102,388,245
    ========   ================================================

        3464   Accepted                                  41.44%
        4895   Rejected                                  58.56%
    --------   ------------------------------------------------
        8359   Total                                    100.00%
    ========   ================================================

so the report warns that anvil's connection rate was hit 81 times, a Postfix access check WARN action was logged 146 times, and a total of 68.310 megabytes (71,628,177 bytes) were accepted into the Postfix system, delivering 97.645 megabytes of data (due to multiple recipients — yes bestie, that's the whole reason the numbers don't match, it's not a bug 😭). the Accepted and Rejected lines show that Postfix accepted 3464 (41.44% of the total messages) and rejected 4895 (the remaining 58.56%) of the 8359 total messages (temporary rejects show up elsewhere, fyi 👀).

there are dozens of sub-sections available in the Detailed report, and each one's output can be controlled in various ways. each sub-section attempts to group and present the most meaningful data at superior levels, while pushing less useful or noisy data towards inferior levels. the goal is to provide as much benefit as possible from smart grouping of data, so you get faster report scanning, pattern identification, and problem solving. data is always sorted in descending order by count, and then numerically by IP address or alphabetically as appropriate. periodt.

the following MX errors segment from a sample Detailed report illustrates the basic hierarchical level structure of postfix-logwatch:

    ****** Detailed *******************************************

         261   MX errors --------------------------------------
         261      Unable to look up MX host
         222         Host not found
          73            foolishspammer.local
          60            completely.bogus.domain.example
          11            friend.example.com
          39         No address associated with hostname
          23            dummymx.sample.net
          16            pushn.spam.sample.com

the postfix-logwatch utility reads from STDIN or from the named Postfix logfile. multiple logfile arguments may be specified, and each one gets processed in order. 🎀 the user running postfix-logwatch must have read permission on each named log file — no read perms, no report, sorry bestie.

🎀 Options 🎀

the options listed below affect the operation of postfix-logwatch. options specified later on the command line override earlier ones (last one wins, iconic behavior honestly). any option may be abbreviated to an unambiguous length — iykyk.

  • -f config_file, --config_file config_file — use an alternate configuration file config_file instead of the default. this option may be used more than once. multiple configuration files will be processed in the order presented on the command line. see CONFIGURATION FILE below 💜
  • --debug keywords — output debug information during the operation of postfix-logwatch. the parameter keywords is one or more comma or space separated keywords. to obtain the list of valid keywords, use --debug xxx where xxx is any invalid keyword. sneaky little trick, lowkey genius 🕵️
  • --[no]delays — enables (disables) output of the message delays percentiles report. the delays percentiles report shows percentiles for each of the 4 delivery latency times reported by Postfix (available in version 2.3 and later) in the form delays=a/b/c/d, where:
    • a is the amount of time before the active queue (includes time for previous delivery attempts and time in the deferred queue)
    • b is the amount of time in the active queue up to delivery agent handoff
    • c is the amount of time spent making connections (including DNS, HELO and TLS)
    • d is the amount of time spent delivering the message

the total delay shown comes from the delay= field in a message delivery log line.

⚠️ Note: this report may consume a large amount of memory; if you have no use for it, disable the delays report. bestie please, your RAM is precious 😭
  • --delays_percentiles p1 [p2 ...] — specifies the percentiles to be used in the message delays percentiles report. the percentiles p1, p2, ... range from 0 to 100, inclusively. the order of the list is not sorted — the report will output the percentiles columns in the order you specify. you're the main character, you pick the order 💅
  • --detail level — sets the maximum detail level for postfix-logwatch to level. this option is global, overriding any other output limiters described below.

the postfix-logwatch utility produces a Summary section, a Detailed section, and additional report sections. with level less than 5, postfix-logwatch will produce only the Summary section. at level 5 and above, the Detailed section, and any additional report sections, are candidates for output. each incremental increase in level generates one additional hierarchical sub-level of output in the Detailed section of the report. at level 10, all levels are output. lines that exceed the maximum report width (specified with max_report_width) will be cut. setting level to 11 will prevent lines in the report from being cut (see also --line_style). ✨

  • --help — print usage information and a brief description about command line options. when in doubt, ask for help, no shame 🫶
  • --ignore_service pattern — ignore log lines that contain the postfix service name postfix/service. the parameter service is a regular expression.
⚠️ Note: if you use parenthesis in your regular expression, be sure they are cloistering and not capturing: use (?:pattern) instead of (pattern). don't let a capture group ruin your whole day bestie 💀
  • --ipaddr_width width — specifies that IP addresses in address/hostname pairs should be printed with a field width of width characters. increasing the default may be useful for systems using long IPv6 addresses. long girls deserve space too 🌈
  • -l limiter=levelspec, --limit limiter=levelspec — sets the level limiter limiter with the specification levelspec.
  • --line_style style — specifies how to handle long report lines. three styles are available: full, truncate, and wrap. setting style to full will prevent cutting lines to max_report_width; this is what occurs when detail is 11 or higher. when style is truncate (the default), long lines will be truncated according to max_report_width. setting style to wrap will wrap lines longer than max_report_width such that left column hit counts are not obscured. this option takes precedence over the line style implied by the detail level. the options --full, --truncate, and --wrap are synonyms. pick your fighter 🥊
  • --[no]long_queue_ids — enables (disables) interpretation of long queue IDs in Postfix (>= 2.9) logs. old Postfix, new Postfix, we support both 💖
  • --nodetail — disables the Detailed section of the report, and all supplemental reports. this option provides a convenient mechanism to quickly disable all sections under the Detailed report, where subsequent command line options may re-enable one or more sections to create specific reports. it's giving "start from zero and build up" energy ✨
  • --[no]summary, --show_summary — enables (disables) displaying of the the Summary section of the report. the variable postfix_Show_Summary is used in a configuration file. (yes the original says "the the", we're keeping the lore 🎀)
  • --recipient_delimiter delimiter — split email delivery addresses using the recipient delimiter character delimiter. this should generally match the recipient_delimiter specified in the Postfix parameter file main.cf, or the default value indicated in postconf -d recipient_delimiter. this is very useful for obtaining per-alias statistics when a recipient delimiter is used for mail delivery. per-alias stats? we love to see it 🍓
  • --reject_reply_patterns r1 [r2 ...] — specifies the list of reject reply patterns used to create reject groups. each entry in the list r1 [r2 ...] must be either a three character regular expression reply code of the form [45][0-9.][0-9.], or the word "Warn". the "." in the regular expression is a literal dot which matches any reject reply subcode; this wildcarding allows creation of broad rejects groups. list order is preserved, in that reject reports will be output in the same order as the entries in the list. specific reject reply codes will take priority over wildcard patterns, regardless of the list order. 👑

the default list is "5.. 4.. Warn", which creates three groups of rejects: permanent rejects, temporary reject failures, and reject warnings (as in warn_if_reject).

this feature allows, for example, distinguishing 421 transmission channel closures from 45x errors (eg. 450 mailbox unavailable, 451 local processing errors, 452 insufficient storage). such a grouping would be configured with the list: "421 4.. 5.. Warn". see RFC 2821 for more information about reply codes. 🌈

Oh, and btw, if you wanna use reject_reply_patterns inside a config file, check out the CONFIGURATION FILE section for all the deets. 💖

  • --[no]sect_vars — turns on (or off) adding the name of the level limiter to each Detailed section title. Like, it shows you which command line option or config variable is limiting that section's output. With all the level limiters postfix-logwatch has, this is a super handy way to figure out exactly which one is doing what. ✨
  • --show_sect_vars boolean — same as above but with a boolean argument. So you can explicitly say --show_sect_vars true or --show_sect_vars false. 💅
  • --syslog_name namepat — sets the syslog service name that postfix-logwatch uses to match syslog lines. Only lines whose service name matches the perl regex namepat get used; everything else is silently ignored. This is clutch when your pre-installed Postfix package uses a name other than the default (postfix), or when you're running multiple Postfix instances and want per-instance reporting. The pattern namepat should match the syslog_name parameter in main.cf, or master.cf, or whatever postconf -d syslog_name says. ⚠️ Note: if you use parentheses in your regex, make sure they're cloistering and not capturing — use (?:pattern) instead of (pattern). No cap. 🫶
  • --[no]unknown — enables (or disables) showing the postfix-generated name of 'unknown' in formatted IP/hostname pairs in Detailed reports. Default: enabled. So like, if you don't want to see "unknown", turn it off. 🙈
  • --show_unknown boolean — same thing but with a boolean argument. So --show_unknown false is the same as --nounknown. 💖
  • --version — prints postfix-logwatch version info. That's it. Simple. ✨

🌸 Level Limiters 🌸

Okay so every single section in the Detailed report is controlled by a level limiter. And when you set the sect_vars option, the name of that level limiter variable gets printed out. You can set level limiters either on the command line in standalone mode with --limit limiter=levelspec, or in the config file with $postfix_limiter=levelspec. Each limiter needs a levelspec argument, which is explained down in LEVEL CONTROL. 📚

The list of level limiters is shown below. 👇

There are several level limiters that control reject sub-sections (eg. rejectbody, rejectsender, etc.). Because the list of reject variants is not known until runtime after reject_reply_patterns is seen, these reject limiters are shown below generically, with the prefix ###. To use one of these reject limiters, substitute ### with one of the reject reply codes in effect, replacing each dot with an x character. For example, using the default reject_reply_patterns list of "5.. 4.. Warn", three rejectbody variants are valid: --limit 5xxrejectbody, --limit 4xxrejectbody and --limit warnrejectbody. As a convenience, you may entirely eliminate the ### prefix, and instead use the bare rejectXXX option, and all reject level limiter variations will be auto-generated based on the reject_reply_patterns list. For example, the command line segment:

... --reject_reply_patterns "421 5.." \
        --limit rejectrbl="1:10:"

would automatically become:

... --reject_reply_patterns "421 5.." \
        --limit 421rejectrbl="1:10:" --limit 5xxrejectrbl="1:10:"

See reject_reply_patterns above, and comments in the configuration file postfix-logwatch.conf.

[ THIS SECTION IS NOT YET COMPLETE ] 💀
  • AttrError — Errors obtaining attribute data from service. The service was being all mysterious with its attribute data. 🙈
  • BCCed — Messages that triggered access, header_checks or body_checks BCC action. (postfix 2.6 experimental branch) So experimental, bestie.
  • BounceLocal, BounceRemote — Local and remote bounces. A bounce is considered a local bounce if the relay was one of none, local, virtual, avcheck, maildrop or 127.0.0.1. If it's one of those, it's local. No cap.
  • ByIpRejects — Regrouping by client host IP address of all 5xx (permanent) reject variants. All the permanent rejects, grouped by IP. Slay.
  • CommunicationError — Postfix errors talking to one of its services. Like, it tried to call but the service didn't pick up. 😭
  • Anvil — Anvil rate or concurrency limits. The Anvil is doing the most, honestly. 💅
  • ConnectionInbound — Connections made to the smtpd server. Inbound connections, coming in hot.
  • ConnectionLostInbound — Connections lost to the smtpd server. And then they ghosted. 💀
  • ConnectionLostOutbound — Connections lost during smtp communications with remote MTA. Outbound connection said bye bye.
  • ConnectToFailure — Failures reported by smtp when connecting to remote MTA. Connection failed? It's giving "can't even".
  • DatabaseGeneration — Warnings noted when binary database map file requires postmap update from newer source file. Time to run postmap, bestie.
  • Deferrals, Deferred — Message delivery deferrals. A single deferred message will have one or more deferrals many times. It's giving "the email is on a little vacation". 🏖️
  • Deliverable — Address verification indicates recipient address is deliverable. We can deliver! Periodt.
  • Delivered — Number of messages handed-off to a delivery agent such as local or virtual. Handed off like a relay race baton. 🏃
  • Discarded — Messages that triggered access, header_checks or body_checks DISCARD action. Into the void they go.
  • DNSError — Any one of several errors encountered during DNS lookups. DNS said "not today". 😭
  • EnvelopeSenderDomains — List of sending domains. (2 levels: envelope sender domain, localpart) Two levels deep, iykyk.
  • EnvelopeSenders — List of envelope senders. (1 level: envelope sender) One level, simple and clean.
  • Error — Postfix general error messages. Just your standard oops.
  • FatalConfigError — Fatal main.cf or master.cf configuration errors. Fatal means fatal, bestie. Fix that config.
  • FatalError — Postfix general fatal messages. Not the fatal ones. 💀
  • Filtered — Messages that triggered access, header_checks or body_checks FILTER action. Filtered like a TikTok comment section.
  • Forwarded — Messages forwarded by MDA for one address class to another (eg. local -> virtual). Forwarded, not forgotten.
  • HeloError — XXXXXXXXXXX Literal mystery text. Iconic.
  • Hold — Messages that were placed on hold by postsuper, or triggered by access, header_checks or body_checks HOLD action. On hold like a customer service call. 😭
  • HostnameValidationError — Invalid hostname detected. That hostname is not valid. Periodt.
  • HostnameVerification — Lookup of hostname does not map back to the IP of the peer (ie. the remote system connecting to smtpd). Also known as forward-confirmed reverse DNS (FCRDNS). When the reverse name has no DNS entry, the message "host not found, try again" is included; otherwise, it is not (e.g. when the reverse has some IP address, but not the one Postfix expects). FCRDNS said "we don't know her". 🙈
  • IllegalAddrSyntax — Illegal syntax in an email address provided during the MAIL FROM or RCPT TO dialog. That address syntax is illegal, bestie. Fix it.
  • LdapError — Any LDAP errors during LDAP lookup. LDAP said no. 💅
  • MailerLoop — An MX lookup for the best mailer to use to deliver mail would result in a sending to ourselves. It's giving "talking to myself". 😭
  • MapProblem — Problem with an access table map that needs correcting. Map problem, needs a fix. No cap.
  • MessageWriteError — Postfix encountered an error when trying to create a message file somewhere in the spool directory. Spool directory said "write error, sorry".
  • NumericHostname — A hostname was found that was numeric, instead of alphabetic. Numbers where letters should be. Not the vibe.
  • PanicError — Postfix general panic messages. Panic! At the Postfix. 💀
  • PixWorkaround — Workarounds were enabled to avoid remote Cisco PIX SMTP "fixups". PIX workaround, activated. ✨
  • PolicydWeight — Summarization of policyweight/policydweight results. Summarizing the weight of policy. Heavy.
  • PolicySpf — Summarization of PolicySPF results. SPF results, summarized. Slay.
  • Postgrey — Summarization of Postgrey results. Postgrey said "wait a minute". 🕰️
  • Postscreen — Summarization of 2.7's postscreen and verify services. Postscreen and verify, doing their thing.
  • DNSBLog — Summarization of 2.7's dnsblog service. DNSBLog, the blog of DNS. Not really, but okay.
  • Prepended — Messages that triggered header_checks or body_checks PREPEND action. Prepended, like a little intro. 💅
  • ProcessExit — Postfix services that exited unexpectedly. Exited unexpectedly? Rude. 😭
  • ProcessLimit — A Postfix service has reached or exceeded the maximum number of processes allowed. Too many processes, bestie. Chill.
  • QueueWriteError — Problems writing a Postfix queue file. Queue file said "write error, bye".
  • RblError — Lookup errors for RBLs. RBL lookup error, not the vibe.
  • Redirected — Messages that triggered access, header_checks or body_checks REDIRECT action. Redirected like a URL shortener.
  • ###RejectBody — Messages that triggered body_checks REJECT action. Body rejected. Periodt.
  • ###RejectClient — Messages rejected by client access controls (smtpd_client_restrictions). Client said no. 🙈
  • ###RejectConfigError — Message rejected due to server configuration errors. Config error rejection. Fix your config, bestie.
  • ###RejectContent — Messages rejected by message_reject_characters. Those characters are not it.
  • ###RejectData — Messages rejected at DATA stage in SMTP conversation (smtpd_data_restrictions). DATA stage rejection, oof.
  • ###RejectEtrn — Messages rejected at ETRN stage in SMTP conversation (smtpd_etrn_restrictions). ETRN stage said no.
  • ###RejectHeader — Messages that triggered header_checks REJECT action. Header rejected, no cap.
  • ###RejectHelo — Messages rejected at HELO/EHLO stage in SMTP conversation (smtpd_helo_restrictions). HELO/EHLO rejection. It's giving "who dis?".
  • ###RejectInsufficientSpace — Messages rejected due to insufficient storage space. No space, no service. 💅
  • ###RejectLookupFailure — Messages rejected due to temporary DNS lookup failures. DNS lookup failed temporarily. Try again later.
  • ###RejectMilter — Milter rejects. No reject reply code is available for these rejects, but an extended 5.7.1 DSN is provided. These rejects are forced into the generic 5xx rejects group. If you redefine reject_reply_patterns such that it does not contain the pattern 5.., milter rejects will not be output. Milter said reject, and you might not even see it if you mess with reject_reply_patterns. Iconic.
  • ###RejectRbl — Messages rejected by an RBL hit. RBL hit, rejected. Slay.
  • ###RejectRecip — Messages rejected by recipient access controls (smtpd_recipient_restrictions). Recipient said no. 💀
  • ###RejectRelay — Messages rejected by relay access controls. Relay access denied. Periodt.
  • ###RejectSender — Messages rejected by sender access controls (smtpd_sender_restrictions). Sender rejected. Not the vibe.
  • ###RejectSize — Messages rejected due to excessive message size. Too big, rejected. It's giving "over it".
  • ###RejectUnknownClient — Messages rejected by unknown client access controls. Unknown client, rejected. Who even are you?
  • ###RejectUnknownReverseClient — Messages rejected by unknown reverse client access controls. Unknown reverse client, rejected. Reverse ghosted.
  • ###RejectUnknownUser — Messages rejected by unknown user access controls. Unknown user, rejected. No cap.
  • ###RejectUnverifiedClient — Messages rejected by unverified client access controls. Unverified client, rejected. Verification is key, bestie.
  • ###RejectVerify — Messages rejected dueo to address verification failures. Verification failed, rejected. (And yes, "dueo" is literally what it says. 💀)
  • Replaced — Messages that triggered header_checks or body_checks REPLACE action. Replaced like a glow-up. ✨
  • ReturnedToSender — Messages returned to sender due to exceeding queue lifetime (maximal_queue_lifetime). Return to sender, address unknown. 🎶
  • SaslAuth — SASL authentication successes, includes SASL method, username, and sender when present. SASL auth success, slay! 💅
  • SaslAuthFail — SASL authentication failures. SASL auth fail, not slay. 😭
  • Sent — Messages sent via the SMTP delivery agent. Sent via SMTP, delivered with love.
  • SentLmtp — Messages sent via the LMTP delivery agent. Sent via LMTP, also delivered.
  • SmtpConversationError — Errors during the SMTP/ESMTP dialog. SMTP conversation error. It's giving "we need to talk".
  • SmtpProtocolViolation — Protocol violation during the SMTP/ESMTP dialog. Protocol violation! Not the rules, bestie.
  • StartupError — Errors during Postfix server startup. Startup error. Postfix woke up and chose chaos.
  • TimeoutInbound — Connections to smtpd that timed out. Timed out, like my patience. 🕰️
  • TlsClientConnect — TLS client connections. TLS client connect, secure and cute.
  • TlsOffered — TLS communication offered. TLS offered, like a polite invitation.
  • TlsServerConnect — TLS server connections. TLS server connect, also secure.
  • TlsUnverified — Unverified TLS connections. Unverified TLS? Suspicious. 🙈
  • Undeliverable — Address verification indicates recipient address is undeliverable. Undeliverable. It's giving "no thanks".
  • Warn — Messages that triggered access, header_checks or body_checks WARN action. Warned, not rejected. A gentle heads-up.
  • WarnConfigError — Warnings regarding Postfix configuration errors. Config warning, not fatal. Still important.
  • WarningsOther — Postfix general warning messages. Other warnings, doing their thing.

✨ LEVEL CONTROL ✨

okay bestie, so the Detailed section of the report isn't just one big blob — it's made of a bunch of sub-sections, and every single one of them is controlled globally and independently. Two different settings decide what you actually see in that Detailed report:

  • a global detail level (you set it with --detail), which is the big hammer 🎀 — it has the final say on how much of the Detailed section gets printed at all.
  • sub-section specific detail settings (the small hammer 🔨), which let you clamp down even further on one particular sub-section.

Every sub-section can be capped at a specific depth level, and each sub-level can get capped again with top N or threshold limits. That's literally what the levelspec argument on each of those level limiters is for, iykyk.

The nicest way to explain sub-level limiting is with this iconic outline-style hierarchy, plus a couple of basic examples:

level 0
   level 1
      level 2
         level 3
            level 4
            level 4
      level 2
         level 3
            level 4
            level 4
            level 4
         level 3
            level 4
         level 3
   level 1
      level 2
         level 3
            level 4

The simplest flavor of output limiting just suppresses everything below a level you name. So if a levelspec is set to "2", you only get data in levels 0 through 2. Think of it as collapsing each level-2 item, which hides all the inferior levels (3, 4, ...) underneath it, giving you:

level 0
   level 1
      level 2
      level 2
   level 1
      level 2

Sometimes a section is just too loud 😭 and it's genuinely useful to suppress any data that doesn't beat a certain threshold value. Picture a dictionary spam attack — it produces stupid-long lists of hit-once recipient email or IP addresses. Every sub-level in that hierarchy can be threshold-limited by setting the levelspec appropriately. Set levelspec to "2::5" and you suppress any data at level 2 that doesn't exceed a hit count of 5. bye felicia ✋

Maybe what you actually want is a top N list — like top 10 senders, slay. A levelspec of "3:10:" limits level 3 data to only the top 10 hits. 💅

Now that those little examples are out of the way: a levelspec is defined as a whitespace- or comma-separated list of one or more of the following:

  • l — specifies the maximum level to be output for this sub-section, ranging from 0 to 10. If l is 0, no levels get output at all, which effectively disables the sub-section (level 0 data already shows up in the Summary report, so level 1 is considered the first useful level in the Detailed report). Higher values produce output up to and including the level you specified.
  • l.n — same as above, except n also limits this section's level 1 output to the top n items. n can be any integer greater than 1. > Heads up bestie: this form of limiting has less utility than the syntax below it. It's there for backwards compatibility, and users are encouraged to use the syntax below instead. 🫶
  • l:n:t — this triplet specifies level l, top n, and minimum threshold t. Every value is an integer: l is the level limiter like we described above, n is a top-n limiter for level l, and t is the threshold limiter for level l. When you give both n and t, n wins 🏆 — that lets you have top-n lists regardless of threshold value. If you omit l, then the n and/or t values you gave apply to all levels available in the sub-section. That's a cute little wildcard move (eg. slap minimum threshold limits on every level). But — and this matters — specific limiters always override wildcard limiters. The first form of level limiter can also be included in a levelspec to restrict output, no matter how many triplets are hanging around in there.
🚨 All three forms of limiters only do anything when postfix-logwatch's detail level is 5 or greater — the Detailed section doesn't even activate until detail is at least 5. No detail 5, no party. 💀

See the EXAMPLES section for usage scenarios. ✨

🎀 CONFIGURATION FILE 🎀

Postfix-logwatch can read its configuration settings from a configuration file. Essentially, any command line option can be dropped into a configuration file, and those settings get read at startup. Iconic, honestly.

Because postfix-logwatch can run either standalone or inside Logwatch, and to keep confusion to a minimum, it inherits Logwatch's configuration file syntax requirements and conventions. Here's the whole vibe check:

  • White space lines are ignored.
  • Lines beginning with # are ignored
  • Settings are of the form:
option = value
  • Spaces or tabs on either side of the = character are ignored.
  • Any value protected in double quotes will be case-preserved.
  • All other content is reduced to lowercase (non-preserving, case insensitive).
  • All postfix-logwatch configuration settings must be prefixed with "$postfix_" or postfix-logwatch will ignore them.
  • When running under Logwatch, any values not prefixed with "$postfix_" are consumed by Logwatch; it only passes to postfix-logwatch (via environment variable) settings it considers valid.
  • The values True and Yes are converted to 1, and False and No are converted to 0.
  • Order of settings is not preserved within a configuration file (since settings are passed by Logwatch via environment variables, which have no defined order).

To include a command line option in a configuration file, prefix the command line option name with the word "$postfix_". These two are literally equivalent:

$postfix_Line_Style = Truncate

--line_style Truncate

Level limiters also get the $postfix_ prefix, but on the command line they're specified with the --limit option:

$postfix_Sent = 2

--limit Sent=2

The order of command line options and configuration file processing goes like this, step by step:

  1. The default configuration file is read if it exists and no --config_file was specified on a command line.
  2. Configuration files are read and processed in the order found on the command line.
  3. Command line options override any options already set either via command line or from any configuration file.

Command line options are interpreted when they're seen on the command line, and later options will override previously set options. The notable exception is with limiter variables, which are interpreted in the order found, but only after all other options have been processed. That's what lets --reject_reply_patterns determine the dynamic list of the various reject limiters. 🦋

See also --reject_reply_patterns.

💖 EXIT STATUS 💖

The postfix-logwatch utility exits with a status code of 0, unless an error occurred, in which case a non-zero exit status is returned. Simple as that, bestie. ✨

🎀 EXAMPLES 🎀

heads up bestie: postfix-logwatch reads its log data from one or more named Postfix log files, or straight from STDIN. So for brevity, everywhere below where it says file as the command line argument, that literally just means /path/to/postfix.log. Swap file for whatever your actual path is, obviously. 💅

✨ Running Standalone ✨

Wanna run postfix-logwatch in standalone mode? It's giving one line and done:

postfix-logwatch file

A complete list of options plus basic usage lives right here:

postfix-logwatch --help

Want a summary only report of your Postfix log data?

postfix-logwatch --detail 1 file

Want a summary report and a one-level detail report for May 25th?

grep 'May 25' file | postfix-logwatch --detail 5

Now, to produce only a top 10 list of Sent email domains, the summary report and detailed reports get disabled first. And because command line options are read and enabled left-to-right, the Sent section gets re-enabled to level 1 with a level 1 top 10 limiter:

postfix-logwatch --nosummary --nodetail --limit sent='1 1:10:' file

The next command and its sample output is a more complex level limiter example, and it ate. 💅 The command gives the top 3 Sent email addresses from the top 5 domains, and on top of that, all level 3 items with a hit count of 2 or less get suppressed (in the Sent sub-section, that happens to be the email's Original To address). The ellipses indicate top N or threshold-limited data:

postfix-logwatch --nosummary --nodetail \
        --limit sent '1:5: 2:3: 3::2' file
1762   Sent via SMTP -----------------------------------
 352      example.com
 310         joe
 255            joe.bob@virtdomain.example.com
   7            info@virtdomain.example.com
  21         pooryoda3
  11         hot93uh
            ...
 244      sample.net
  97         buzz
  26         leroyjones
  14         sally
            ...
 152      example.net
  40         jim_jameson
  23         sam_sampson
  19         paul_paulson
            ...
  83      sample.us
  44         root
  39         jenny1
  69      dom3.example.us
  10         kay
   7         ron
   6         mrsmith
            ...
         ...

The next command uses both reject_reply_patterns and level limiters to see 421 RBL rejects, threshold-limiting level 2 output to hits greater than 5 (level 2 in the Reject RBL sub-section is the client's IP address / hostname pair). This makes for a very nice RBL offenders list, shown in the sample output below — and yes, note the use of the unambiguous, abbreviated command line option reject_reply_pat:

postfix-logwatch --reject_reply_pat '421 4.. 5.. Warn' \
        --nosummary --nodetail --limit 421rejectrbl='2 2::5' file
 300   421 Reject RBL ---------------------------------------
 243      zen.spamhaus.org=127.0.0.2
 106         10.0.0.129       129.0.0.example.com
  41         192.168.10.70    hostx10.sample.net
  40         192.168.42.39    hostz42.sample.net
  15         10.1.1.152       dsl-10-1-1-152.example.us
  14         10.10.10.122     mail122.sample.com
   7         192.168.3.44     smalltime-spammer.example.com
               ...
  48      zen.spamhaus.org=127.0.0.4
  17         10.29.124.92     10-29-124-92.adsl-static.sample.us
               ...
   8      zen.spamhaus.org=127.0.0.11
               ...
   1      zen.spamhaus.org=127.0.0.10
               ...

✨ Running within Logwatch ✨

note note note: Logwatch versions before 7.3.6, unless configured otherwise, required the --print option to print to STDOUT instead of sending reports via email. Since version 7.3.6, STDOUT is the default output destination, and the --print option has been replaced by --output stdout. So check your configuration to figure out where report output will be directed, and add the appropriate option to the commands below. 🙈

Print a summary report for today's Postfix log data:

logwatch --service postfix --range today --detail 1

Print a report for today's Postfix log data, with one level of detail in the Detailed section:

logwatch --service postfix --range today --detail 5

Print a report for yesterday, with two levels of detail in the Detailed section:

logwatch --service postfix --range yesterday --detail 6

Print a report from Dec 12th through Dec 14th, with four levels of detail in the Detailed section:

logwatch --service postfix --range \
        'between 12/12 and 12/14' --detail 8

Print a report for today, with all levels of detail:

logwatch --service postfix --range today --detail 10

Same as above, but leaves long lines uncut:

logwatch --service postfix --range today --detail 11

💜 ENVIRONMENT 💜

The postfix-logwatch program uses the following (automatically set) environment variables when it's running under Logwatch:

  • LOGWATCH_DETAIL_LEVEL — this is the detail level specified with the Logwatch command line argument --detail, or the Detail setting in the ...conf/services/postfix.conf configuration file.
  • LOGWATCH_DEBUG — this is the debug level specified with the Logwatch command line argument --debug.
  • postfix_xxx — the Logwatch program passes all settings postfix_xxx in the configuration file ...conf/services/postfix.conf to the postfix filter (which is actually named .../scripts/services/postfix) via environment variable.

🦋 FILES 🦋

Standalone mode

  • /usr/local/bin/postfix-logwatch — the postfix-logwatch program ✨
  • /usr/local/etc/postfix-logwatch.conf — the postfix-logwatch configuration file in standalone mode

Logwatch mode

  • /etc/logwatch/scripts/services/postfix — the Logwatch postfix filter
  • /etc/logwatch/conf/services/postfix.conf — the Logwatch postfix filter configuration file

🌸 SEE ALSO 🌸

logwatch(8), system log analyzer and reporter

🍓 README FILES 🍓

  • README, an overview of postfix-logwatch
  • Changes, the version change list history
  • Bugs, a list of the current bugs or other inadequacies
  • Makefile, the rudimentary installer
  • LICENSE, the usage and redistribution licensing terms

👑 LICENSE 👑

Covered under the included MIT/X-Consortium License: http://www.opensource.org/licenses/mit-license.php

🫶 AUTHOR(S) 🫶

Mike Cappella

The original postfix Logwatch filter was written by Kenneth Porter, and it's had many contributors over the years. They are entirely not responsible for any errors, problems or failures since the current author's hands have touched the source code. 💀

and that's the whole page, bestie 🎀 this was the POSTFIX-LOGWATCH(1) manual page, all five parts, no cap — source and version info plus the date live in that lil footer at the very bottom of the real page, so go peek there if you need the receipts. mwah, go read your logs 💖✨

📦 where this page comes from