]> git.sven.stormbind.net Git - sven/pflogsumm.git/blobdiff - pflogsumm-faq.txt
Imported Upstream version 1.1.3
[sven/pflogsumm.git] / pflogsumm-faq.txt
diff --git a/pflogsumm-faq.txt b/pflogsumm-faq.txt
new file mode 100644 (file)
index 0000000..b96085a
--- /dev/null
@@ -0,0 +1,754 @@
+
+FAQ for Pflogsumm.pl - A Log Summarizer/Analyzer for the Postfix MTA
+
+Introduction
+
+    I wouldn't have believed it.  What started out mostly as a light-
+    hearted exercise in improving my facility with Perl--with the hope
+    that something useful would come out of it as well--has turned out to
+    be a somewhat popular utility.  And as more Admins find out about
+    postfix, and more end up trying pflogsumm.pl,  many of the questions,
+    suggestions, and enhancement requests are becoming "frequently
+    asked".  So odd as it seems (to me, at any rate), it looks like it's
+    time for a FAQ.
+
+
+Index of pflogsumm.pl Frequently Asked Questions (in no particular order)
+
+     1. Project Status
+     2. "Could You Make" or "Here's A Patch To Make" Pflogsumm Do ...
+     3. Requires Date:Calc Module
+     4. Built-In Support for Compressed Logs
+     5. Processing Multiple Log Files
+     6. Time-Based Reporting and Statistics
+     7. By-domain Listings
+     8. Reject, Deferred and Bounced Detail Info
+     9. "Orphaned" (no size) Messages
+    10. Pflogsumm misses/mis-diagnoses/mis-reports, etc. <whatever>
+    11. Pflogsumm is generating lots of "uninitialized value" warnings
+    12. Pflogsumm just doesn't work or doesn't report anything
+    13. Postfix Rejects Pflogsumm Reports Because Of Body Checks
+    14. Pflogsumm Reports Double Traffic When Anti-Virus Scanner Used
+    15. Pflogsumm's numbers don't add up
+    16. Hourly stats for reports run without "-d" option are halved
+    17. How Do I Get Pflogsumm To Email Reports To Me Daily/Weekly/etc.?
+    18. How Can I View Pflogsumm's Reports In My Web Browser?
+    19. New Red Hat install - Pflogsumm no longer works!
+    20. How can I best format my custom reject messages for display in
+        Pflogsumm's output?
+    21. Pflogsumm doesn't understand my log file format
+    22. Why Isn't There Any Mention Of "Monkey Butler" In The FAQ?
+    23. Translating Pflogsumm (Support for Internationalization)
+    24. Pflogsumm may sometimes calculate "yesterday" incorrectly
+    25. Sending Logfile Samples
+    26. From Where Can I  Obtain Pflogsumm?
+
+
+1. Project Status
+
+    New work on Pflogsumm is sporadic.  It pretty much does everything I
+    need it to do and, so far as I can tell, pretty much what most other
+    people need it to do.  And my time is limited.
+
+    I'll still take bug reports.  I'll still fix bugs.  (But I promise no
+    time-line.)  I'll still answer questions (as time allows).  And I
+    *may* add the occasional enhancement or whatever--as the mood
+    strikes--but Pflogsumm is pretty much a "finished work" as far as I'm
+    concerned.
+
+
+2. "Could You Make" or "Here's A Patch To Make" Pflogsumm Do ...
+
+    Unless it's a *bug* fix, please see: "1. Project Status"
+
+    To the argument "But it's a patch, all you have to do is...," the
+    answer is: "Not quite."  Every time I make a change to Pflogsumm I
+    have to run it through a series of regression checks to make sure the
+    change didn't break something.  Then there's the commit,
+    documentation, web page update, etc. cycle.
+
+    I'm particularly unlikely to add code to Pflogsumm to account for
+    non-standard Postfix log entries.  "Non-standard" being defined as
+    "other than what Wietse's code does."  Or additional stats gathering
+    that nobody else has requested and strikes *me* as of limited interest
+    or use.  In addition to the development cycle, there's the issue of
+    "code bloat."  Pflogsumm already takes enough (too much?) time and
+    memory on busy machines with large logs.  I'm not prone to make this
+    worse for the sake of these things.
+
+    See Also: 21. Pflogsumm doesn't understand my log file format
+
+
+3. Requires Date::Calc Module
+
+    Pflogsumm requires the Date::Calc module.  You can download and
+    install the Date::Calc module from CPAN.  It can be found at:
+
+       http://search.cpan.org/search?module=Date::Calc
+
+    Or you can remove the code that's dependent on the Date::Calc module.
+    For the convenience of folks that would prefer to take this approach,
+    I've "fenced" all such code like this:
+
+       # ---Begin: SMTPD_STATS_SUPPORT---
+             .
+             .
+             .
+       <bunch of code>
+             .
+             .
+             .
+       # ---End: SMTPD_STATS_SUPPORT---
+
+    However, if you do this you will lose support for --smtpd_stats.
+
+    Later versions of the Pflogsumm distribution include a script to
+    semi-automate removing smtpd stats support, if you so-desire.
+
+    As of Pflogsumm-1.1.1, the presence of Date::Calc is optional.  If you
+    don't want to use the Pflogsumm options that depend upon it, you
+    neither need Date::Calc, nor is it necessary to manually remove the
+    code that depends upon it.
+
+
+4. Built-In Support for Compressed Logs
+
+    I took a look at this.  There is a Perl module (which I downloaded,
+    built, and installed here) to interface to libz, but after considering
+    the changes that would be necessary--and the fact that those changes
+    would require that potential users have to download/build/install libz
+    (and of the correct version) and the additional Perl module, I decided
+    to forego this enhancement.
+
+    I could just open a pipe within Pflogsumm and use zcat/gunzip/gzip.
+    That would depend upon a) them being there [probably a safe bet--
+    considering the logs somehow got into that format :-), but...] and b)
+    one of these either being in the path or having an environment
+    variable or a script variable or...
+
+    The thing is, in the latter case there's really no "savings" over
+    simply piping into Pflogsumm in the first place.  Multiple processes
+    get spawned, pipes opened, etc. either way.  It would add a little
+    convenience, is all.
+
+    So I could do it.  And there are a couple of ways I could do it.  And
+    my mind is certainly still open on the issue.  I'm just not convinced
+    there's a good reason to do it, is all.  And I'd like to avoid
+    "creeping over-feature-itis" if I can.  My position is *not* set in
+    stone on this issue.  In the mean-time:
+
+       zcat /var/log/maillog.0.gz |pflogsumm.pl <args...>
+
+       or
+
+       gunzip </var/log/maillog.0.gz |pflogsumm.pl <args...>
+
+    should do the trick quite nicely for you.
+
+    If you've a complex situation, for example: your logs aren't rotated
+    exactly at midnight, you might try something like:
+
+       (zcat /var/log/maillog.0.gz; cat /var/log/maillog) \
+           |pflogsumm.pl -d yesterday
+
+    See Also:  5. Processing Multiple Log Files
+              17. How Do I Get Pflogsumm To Email Reports To Me
+                 Daily/Weekly/etc.?
+
+
+5. Processing Multiple Log Files
+
+    When processing multiple log files (say: an entire weeks worth of logs
+    that are rotated daily), it is important that Pflogsumm be fed them in
+    chronological order.  For performance and memory conservation reasons,
+    Pflogsumm relies on log messages "arriving" in the order in which they
+    were created.
+
+    If you do something like this:
+
+       pflogsumm /var/log/maillog*
+
+    you might not get what you expect!  Instead, try something like:
+
+       pflogsumm `ls -rt /var/log/maillog*`
+
+    A more complex example, where compressed logs are involved:
+
+       (zcat `ls -rt /var/log/maillog.*.gz`; cat /var/log/maillog) \
+           |pflogsumm.pl
+
+    Obviously, this depends on the file modification times for your logs
+    being reflective of their chronological order.  If that can't be
+    trusted, you're gonna have to get ugly.  Like in enumerating each
+    file, or as in:
+
+       (for each in 3 2 1 0; do
+            zcat "/var/log/maillog.$each.gz"
+        done
+        cat /var/log/maillog) |pflogsumm.pl
+
+    or (somewhat more efficiently--by running zcat only once):
+
+       (zcat `for ea in 3 2 1 0; do echo "/var/log/maillog.$ea.gz";
+        done`; cat /var/log/maillog) |pflogsumm.pl
+
+    [Note: I didn't actually run these.  So you would be well-advised
+     to double-check them.]
+
+    See Also:  4. Built-In Support for Compressed Logs
+              17. How Do I Get Pflogsumm To Email Reports To Me
+                 Daily/Weekly/etc.?
+
+
+6. Time-Based Reporting and Statistics
+
+    There has been a small assortment of requests for different time
+    statistics reporting.  And adding this would be relatively straight-
+    forward.  (Just have to reach a consensus on exactly *what* should be
+    reported, and how.  This could easily get out of hand!)
+
+    There's only one *small* problem.  Ironically, it's time.
+
+    I've experimented with Pflogsumm grokking the log timestamps.  As a
+    matter-of-fact: the enhancement added in the 19990110-05 version
+    required that I do some of this.  My first pass was to use the Perl
+    timelocal() function to convert those sub-strings to an integer for
+    subsequent comparison operations.  Imagine my surprise when
+    performance of the resulting code was a factor of five (5) times
+    slower than that of its predecessor.  After a "remove the statements
+    until it got fast again" exercise, I found that the culprit was
+    timelocal().
+
+    As of version 19990321-01, Pflogsumm does by-domain stats reporting of
+    average and maximum delivery time by host/domain.  And an even earlier
+    version added by-hour and by-day message count reporting.  Anything
+    much beyond these is going to get "expensive."
+
+    If/when any additional time-based stats reporting is added: I think
+    they are definitely going to be optional.
+
+    One way you can make up for Pflogsumm's deficiency in this respect is
+    to use good ol' Unix tools like "grep" to pre-process your log files
+    before feeding them to Pflogsumm.  E.g.:
+
+       grep "Feb  9" /var/log/maillog |pflogsumm what_ever_args
+
+    Note that single-digit days-of-the-month have an additional leading
+    space in the logfiles, where the digit for two-digit dates would be.
+
+
+7. By-domain Listings
+
+    I figured on the desire for this one from the start.  There are many
+    possibilities:
+
+       1) A single report, split by domain
+       2) An option to limit reporting to a particular domain
+
+    This issue is kind of tricky.  The popularity of Unix amongst
+    SysAdmins is testimony to the beauty of being able to wire- together
+    small, simple tools so that one can generate output to ones taste.
+    Anything I do is likely to make some Admins happy and others wishing
+    I'd done it "the other way".
+
+    One thought that occurred is to perhaps provide a couple of options
+    that would allow one to limit a particular report to
+
+       sender=regular_expression and/or recipient=regular_expression
+
+    The problem with this solution is that an Admin desiring to emit
+    custom reports for multiple domains would have to re-process the same
+    log multiple times--once for each desired domain.
+
+    So I'm still thinking about this one.
+
+
+8. Reject, Deferred and Bounced Detail Info
+
+    I've actually only received one query about this so far, but there are
+    bound to be more.  So...
+
+    The "detailed" information in the "Reject", "Deferred" and "Bounced"
+    reports is a compromise.  Just take a stroll through your postfix logs
+    some day and observe the variation in how the "reason" for a
+    particular reject, defer, or bounce is reported.  Without putting a
+    lot of static comparisons for each-and-every case into the analyzer, I
+    have absolutely no hope is doing this very well.
+
+    Emitting the entire "reason" is not good, either.  The entire "reason"
+    string can be very long.  Depending on what somebody is using to
+    display Pflogsumm's output, the lines may well wrap-- producing output
+    that is no more readable than just grepping the logs.
+
+    And anything more I do to this end may soon be rendered moot.  After
+    Wietse gets most of the more important functional stuff out of the
+    way, Postfix logging is going to be completely re-written.  (Oh boy,
+    won't that be fun!)  I'm hoping I'll be able to get some input into
+    the process so the formatting is more amenable to automated
+    processing.  Wietse has indicated that such would be the case.
+
+    Also, please note my primary objective behind Pflogsumm (besides the
+    entertainment value): "just enough detail to give the administrator a
+    ``heads up'' for potential trouble spots."  It's not *supposed* to do
+    away with manual inspection entirely.
+
+    For those that really want all that extra detail in the log summary
+    reports, specify the "--verbose_msg_detail" switch.
+
+    See Also: 25. Sending Logfile Samples
+
+
+9. "Orphaned" (no size) Messages
+
+    The Problem:
+
+       Message size is reported only by the queue manager.  The message
+       may be delivered long-enough after the (last) qmgr log entry that
+       the information is not in the log(s) processed by a particular run
+       of pflogsumm.pl.
+
+    The Result:
+
+       "Orphaned" messages.  These are reported by Pflogsumm as "Messages
+       with no size data."
+
+       This, of course, throws off "Recipients by message size" and the
+       total for "bytes delivered."  ("bytes in messages" in earlier
+       versions.)
+
+    The Solution:
+
+       "Memorize" message sizes by queue i.d.  Easy in theory.  Difficult
+       in practice.  At least at the moment.
+
+       You see, if Pflogsumm's going to "memorize" message sizes, it has
+       to have some definitive way to know when to delete a no-
+       longer-needed reference.  Otherwise the memory file will just grow
+       forever.
+
+    As with the "Reject, Deferred and Bounced Detail Info" issue above,
+    I'm hoping the get some input into future changes in logging issues.
+    In any event: maybe whatever comes out of the logging redesign will
+    provide a solution.
+
+    As of Pflogsumm version 1.0.12, the "Messages with no size data" report
+    can be turned off.
+
+
+10. Pflogsumm misses/mis-diagnoses/mis-reports, etc. <whatever>
+
+    Are you using a real old version of VMailer?  As of pflogsumm.pl
+    version 19990220-06, versions of VMailer prior to 19981023 are no
+    longer supported.  Sorry.  Pflogsumm-19990121-01.pl will be made
+    permanently available from now on for those with out-of-date versions
+    of VMailer prior to 19981023.
+
+    Are you processing your log files in chronological order?  See item
+    "5: "Processing Multiple Log Files".
+
+    Pflogsumm.pl is being developed by me on my rather small-scale server
+    at home.  There are only two users on the system.  And I do no
+    mail-forwarding.  So the log samples I have to work with are
+    commensurately limited.
+
+    If there's something that Pflogsumm is not doing, or not doing right,
+    let me know what it is, what you think it ought to do, and send me a
+    representative sample of *real* log entries with which to work.
+
+    See Also: 5. Processing Multiple Log Files
+             12. Pflogsumm just doesn't work or doesn't report anything
+             15. Pflogsumm's numbers don't add up
+              19. New Red Hat install - Pflogsumm no longer works!
+             21. Pflogsumm doesn't understand my log file format
+              25. Sending Logfile Samples
+
+
+11. Pflogsumm is generating lots of "uninitialized value" warnings
+
+    Are you using a version of Perl lower than 5.004_04?  Perhaps with a
+    "beta" version of pflogsumm.pl?  If so, try turning off the "-w"
+    switch.  Pflogsumm as of 19990413-02beta appeared to work correctly
+    with Perl 5.003 in spite of the warnings.  (Those warnings didn't
+    appear with Perl 5.004.)
+
+    I don't guarantee that I'll remember to test future versions of
+    pflogsumm.pl against 5.003, but I'll try to :-).
+
+    You really should consider upgrading your Perl to 5.004 or later.
+
+
+12. Pflogsumm just doesn't work or doesn't report anything
+
+    Did you *download* Pflogsumm as opposed to grabbing it by
+    "copy-and-paste" from a browser?  Copy-and-paste can result in lines
+    being unintentionally wrapped and hard-tabs being converted to
+    spaces.  This will break Pflogsumm.
+
+    Also, I've received a couple of reports by people downloading
+    Pflogsumm with Lynx that the download has long lines wrapped.
+    Naturally, this breaks Pflogsumm.
+
+    See Also: 10. Pflogsumm misses/mis-diagnoses/mis-reports, etc.
+              <whatever>
+              19. New Red Hat install - Pflogsumm no longer works!
+             21. Pflogsumm doesn't understand my log file format
+
+
+13. Postfix Rejects Pflogsumm Reports Because Of Body Checks
+
+    You configure Postfix to do body checks, Postfix does its thing,
+    Pflogsumm reports it and Postfix catches the the same string in the
+    Pflogsumm report.  There are several solutions to this.
+
+    Wolfgang Zeikat contributed this:
+
+       #!/usr/bin/perl
+       use MIME::Lite;
+
+       ### Create a new message:
+       $msg = MIME::Lite->new(
+           From     => 'your@send.er',
+           To       => 'your@recipie.nt',
+           # Cc     => 'some@other.com, some@more.com',
+           Subject  => 'pflogsumm',
+           Date     => `date`,
+           Type     => 'text/plain',
+           Encoding => 'base64',
+           Path     =>'/tmp/pflogg',
+       );
+
+       $msg->send;
+
+    Where "/tmp/pflogg" is the output of Pflogsumm.  This puts Pflogsumm's
+    output in a base64 MIME attachment.
+
+    In a follow-up to a thread in the postfix-users mailing list, Ralf
+    Hildebrandt noted:
+
+       "mpack does the same thing."
+
+    The canonical FTP site for mpack is ftp.andrew.cmu.edu:pub/mpack/
+
+    The solution I came up with is to modify the body_checks statements to
+    ignore the strings when they're in a Pflogsumm report, as follows:
+
+    Bounce anything with 6 or more "$"s in a row...
+
+       /\${6,}/    REJECT
+
+    Which, of course, catches the line in the Pflogsumm report too.
+    So...
+
+       /^(?!\s+[0-9]+\s+).*?\${6,}/    REJECT
+
+    which reads "anything with 6 or more '$'s in a row that is not a line
+    beginning with one or more whitespace characters, followed by one or
+    more digits, followed by one or more whitespace characters."
+
+    (This is using PCRE's, btw.)
+
+    Note that my solution will be more computationally expensive, by a
+    *long* way, than encoding Pflogsumm's output into a format that
+    body_checks won't catch.
+
+    Robert L Mathews suggested the following solution
+
+       /^ {6,11}[[:digit:]]{1,6}[ km] /    OK
+
+    Placed at the beginning of a body_checks file, this will "pre-approve"
+    lines in Pflogsumm's output that might otherwise get caught.  That's
+    a POSIX regexp version.  A PCRE version of the same thing would be:
+
+       /^ {6,11}\d{1,6}[ km] /    OK
+
+
+14. Pflogsumm Reports Double Traffic When Anti-Virus Scanner Used
+
+    Sadly, there's absolutely nothing I can do about this :-(.
+
+    The problem arises because of the way in which anti-virus scanning is
+    handled by Postfix.  Basically, Postfix "delivers" each email to the
+    anti-virus scanner and the anti-virus scanner re-sends it through
+    Postfix.  So each email really is received twice and sent/delivered
+    twice.
+
+    And yes, I tried.  I really, really tried.  If I recall correctly, I
+    spent come two days mucking-about with this problem.  Actually thought
+    I had it once or twice.  But the results inevitably failed regression
+    testing.  At the end of this, and with some more careful thought, I
+    realized it just wasn't possible.  If you think you can prove me
+    wrong, please do so.  I'd be quite pleased to be proven wrong on this
+    one.
+
+    johnfawcett at tiscali-dot-it believes he's done it.  You may find
+    prefiltering your log with his "prepflog" does it for you.  You can
+    find it at <http://web.tiscali.it/postfix/>.
+
+
+15. Pflogsumm's numbers don't add up
+
+    Pflogsumm reports more "delivered" than "received"
+
+       Naturally.  A single email message can have multiple recipients.
+
+    Pflogsumm reports more "rejected" than "received"
+
+    Why doesn't delivered + deferred + bounce + rejected = received?
+
+       Some rejects (header and body checks, for example) happen in
+       "cleanup," after alias lists are expanded.  Thus a single received
+       message will be rejected multiple times: once for each recipient.
+
+    The "size=" fields, multiplied by their "nrcpt=" fields, when added-up
+    yields a total higher than Pflogsumm's "bytes delivered" total.
+
+       Pflogsumm doesn't count something delivered until it actually *is*
+       delivered.  Nrcpt only suggests the number of intended recipients,
+       not how many are actually deliverable.  Only if there were no
+       bounces, rejects, defers or other undeliverables for everything
+       that was received would a calculation such as that above yield the
+       proper value.
+
+    Pflogsumm's "% rejected" doesn't add up
+
+       The "percent rejected" and "percent discarded" figures are only
+       approximations.  They are calculated as follows (example is for
+       "percent rejected"):
+
+           percent rejected =
+
+               (rejected / (delivered + rejected + discarded)) * 100
+
+       Given the issues discussed above, this is really the best that can
+       be hoped-for, IMO.
+
+    I consistently see more "delivered" than "received."  How is that
+    possible?
+
+       Any message that's got multiple recipients in the "To:,"
+       "Cc:," and "Bcc:" fields will result in a single "received"
+       with multiple "delivered"s, as well as, possibly, multiple
+       "rejects" (or reject warnings, discards or holds), depending
+       on where in Postfix' processing the rule was that resulted
+       in the reject, etc.
+
+    See Also: 10. Pflogsumm misses/mis-diagnoses/mis-reports, etc.
+                 <whatever>
+
+
+16. Hourly stats for reports run without "-d" option are halved
+
+    Scenario: On day #1 of a fresh logfile, you run Pflogsumm with "-d
+    today" and the next day you run it with no "-d" option.  The "Per-Hour
+    Traffic" statistics are approximately halved.  How can this be?
+
+    Note that when you run Pflogsumm on a logfile that contains multi-day
+    logfile entries, Pflogsumm automatically changes the per-hour stats to
+    daily traffic averages.  If there's even *one* logfile entry from
+    another day, all of the per-hour stats will be divided by two.  Unless
+    you rotate logfiles *precisely* at midnight--and it's unlikely you can
+    guarantee that happening--there's no way to prevent this.
+
+
+17. How Do I Get Pflogsumm To Email Reports To Me Daily/Weekly/etc.?
+
+    Excuse me?  You're running a mailserver and you don't know how to use
+    cron to run things on a scheduled basis and pipe the output to
+    something that'll email it to you?
+
+    Oh. My. Lord.
+
+    *sigh*
+
+    Here's my crontab entries:
+
+    10 0 * * * /usr/local/sbin/pflogsumm -d yesterday /var/log/syslog \
+       2>&1 |/usr/bin/mailx -s "`uname -n` daily mail stats" postmaster
+
+    10 4 * * 0   /usr/local/sbin/pflogsumm /var/log/syslog.0 \
+       2>&1 |/usr/bin/mailx -s "`uname -n` weekly mail stats" postmaster
+
+    (Those are actually each a single line.  I line-broke them [and
+    signified that with the "\"s] for readability.)
+
+    The first generates stats for the previous day and is run *after*
+    midnight.  The second is run against the previous week's entire log.
+    (I rotate my logs weekly.)
+
+    If you rotate your logs on a different schedule, want monthly reports,
+    etc., I leave it as an exercise to you, the reader, to figure out how
+    to concatenate several logs to stdout and feed that to Pflogsumm.
+
+    See Also: 4. Built-In Support for Compressed Logs
+             5. Processing Multiple Log Files
+             The Unix manual pages for "cron," "crontab," "cat,"
+             "zcat," "gzip," "gunzip," "mail," "mailx," etc.
+
+
+18. How Can I View Pflogsumm's Reports In My Web Browser?
+
+    Just direct Pflogsumm's output to a file, call it "something.txt" or
+    whatever, and look at it with your browser :).  If you want to get
+    fancy, create a post-processing shell script that'll create a
+    date-tagged file, like "mailstats-20030216.txt".  It's easy.
+
+    See Also: Pflogsumm Through A Browser, on Pflogsumm's home page.
+
+
+19. New Red Hat install - Pflogsumm no longer works!
+
+    From some email exchanges with a couple of people that reported
+    this...
+
+       "It appears the Pflogsumm is broken with RedHat9.  I can take
+        the same log file and run it under Solaris9/RedHat 7.3 (perl 5.8
+        on both) without a problem, but it breaks on RH9."
+
+       "Oops.  Sorry about the false alarm.  This is an issue with
+        some of the other Perl scripts that are out there due to Red Hat
+        8/9 using LANG=en_US.UTF-8
+
+        Changing the locale to "POSIX" fixes this...
+            LANG=C
+
+        Note that Pflogsumm works fine when run through cron.daily, as
+        cron has different environment settings."
+
+       "Ah, the good old RH8/9 UTF-8 strikes again.  I should have
+        known. Setting  LANG to either en_US or C fixes the problem."
+
+    What the above means is that you have to change the "LANG" environment
+    variable from "en_US.UTF-8" to "en_US" or "C".  E.g.:
+
+       LANG="en_US"
+       export LANG
+
+    in your shell.  Or you could add these commands to your login
+    profile.  (I.e.: $HOME/.bash_profile, if you're using bash.)  Or set
+    the system-wide default in /etc/sysconfig/i18n.  My RH boxes have LANG
+    set to "en_US" there, and everything seems to work fine.  (If you set
+    it in your profile or the system-wide default, you'll need a fresh
+    login for it to take effect, obviously.)
+
+    See Also: 10. Pflogsumm misses/mis-diagnoses/mis-reports, etc.
+              <whatever>
+              12. Pflogsumm just doesn't work or doesn't report anything
+             21. Pflogsumm doesn't understand my log file format
+
+
+20. How can I best format my custom reject messages for display in
+    Pflogsumm's output?
+
+    Reject reason strings found in the mail log will be truncated at the
+    first comma (","), colon (":") or semi-colon (";").  If you want a
+    "clause" in your reject message to appear in Pflogsumm's output,
+    without having to specify --verbose_msg_detail, use a punctuation mark
+    other than one of those three, such as a dash ("-").
+
+
+21. Pflogsumm doesn't understand my log file format
+
+    I've received several requests to modify Pflogsumm's log file format
+    regular expression matching to accommodate "non-standard" log file
+    formats.  I'm not inclined to honour such requests.  The regexp that
+    identifies Postfix' log file entries is nearly incomprehensible as it
+    is.  If your log file format has extra fields (e.g.: FreeBSD syslogd
+    with "-v -v" specified), or, as in one case (metalog), is lacking
+    fields, and you insist on doing things that way, I recommend you
+    code-up a little pre-filter to mung the format into a standard one.
+
+    See Also: 10. Pflogsumm misses/mis-diagnoses/mis-reports, etc.
+              <whatever>
+              12. Pflogsumm just doesn't work or doesn't report anything
+              19. New Red Hat install - Pflogsumm no longer works!
+
+
+22. Why Isn't There Any Mention Of "Monkey Butler" In The FAQ?
+
+    A friend of mine asked me if I'd put the phrase "monkey butler" in
+    the FAQ.  The answer is no.  Pflogsumm is used by some rather large
+    corporations.  There are credibility issues.  Sorry. :)
+
+
+23. Translating Pflogsumm (Support for Internationalization)
+
+    Unfortunately, Pflogsumm doesn't currently have i18n support.
+
+    It wasn't until at least Perl 5.6 that i18n was included as part of
+    the base distribution.  Since, last time I looked, 5.005* was still
+    the most widely-used version of Perl (that's what I'm still running
+    everywhere, too), I can't put i18n in without chancing breaking
+    things right-and-left for the majority of my customers.
+
+    Even with Perl 5.6 and above, it was mentioned in postfix-users, by
+    Liviu Daia, that
+
+       "Perl 5.6+ has locales.  Locales can give you localized
+        dates, charsets, standard error messages etc., but it
+        won't automatically switch languages of the strings
+        defined in your program.  For that, you still need
+        gettext or something equivalent."
+
+    So I'm not clear on the future of i18n support in Pflogsumm.  But I'm
+    keeping an eye on things.  Proper i18n support has long been one of
+    the top things on my own wish list!
+
+    Prospective translators are urged to translate *only* the
+    stable/production versions.  Beta and Alpha versions can sometimes
+    change rapidly.
+
+    If you do translate Pflogsumm, let me know and I'll put a link to it
+    on Pflogsumm's main web page.
+
+
+24. Pflogsumm may sometimes calculate "yesterday" incorrectly
+
+    As Wieland Chmielewski aptly noted:
+
+       Subroutine get_datestr incorrectly assumes that each day of
+       the year comprises 24 hours. In those countries which
+       participate in Daylight Saving Time policy there is one day
+       with 23 hours and one day with 25 hours. So, chances are (for
+       1 hour within those days) that get_datestr actually returns
+       either "the day before yesterday" or "today" instead of
+       "yesterday" as requested.
+
+    Right you are, Wieland, and thanks for the catch.
+
+    Problem is, of course, there's really no clean, easy, certain fix.
+    The work-around is to stay well clear of DST never-never land with
+    your cron jobs.
+
+
+25. Sending Logfile Samples
+
+    Here's the deal with whatever you may send me in the way of log
+    samples:
+
+       . Obfuscate them if you want.  But take care not alter them
+         in such a manner that they're not accurate wrt the "realism" of
+         the data, make sure the field formatting is not altered, and
+         that the order of the log entries is not altered.
+
+       . The world is an unsafe place for your data, no matter where
+         it might reside.  But I'll do my level best to ensure that your
+         data does not fall into the hands of others.
+
+       . If you want, I'll PGP-encrypt the data when it's not in
+         use.
+
+       . You can PGP-encrypt it when you send it to me if you're
+         concerned.  My PGP public key can be found on my Web site and at
+         the PGP public key servers.
+
+       . If you want, I'll delete the sample data when the work is
+         done.  But I would *like* to keep it around for future
+         regression-testing.  It's your call.  Let me know.
+
+
+26. From Where Can I  Obtain Pflogsumm?
+
+    http://jimsun.LinxNet.com/postfix_contrib.html
+
+
+Created: 15 Feb., 1999 / Last updated: 10 April, 2004