OK, I included this information in a follow-up a few minutes ago and
almost immediately got a request/suggestion to re-post so it's not lost
in the other message history.
The issue being brought up was one of 3rd party "tools" that help in
managing a QMT installation.
Erick brought up one, *qmlog*, that does a GREAT job of helping manage
QMT log files -- especially since the standard timestamps on those qmail
logs are in an unusual format, not easily human decipherable. (*qmlog
*is included in the *QTP *-- Qmail Toaster Plus -- package).
The one I was adding is called *mtrack *(and a sister, called
*strack*)... and I mentioned that I stick a pre-fix on them in my
systems to keep my feeble little head on straight, so to me they're
/*qmtrack */and /*qmstrack*/.
[q]*mtrack *groups together log entries from qmail-send (either raw, or
output from qmlog -- I prefer the latter). [qm]*strack *does the same
for qmail-smtpd log files.
As an example -- to make finding "bad actors" easier, I use qmlog, grep,
and wc to count (every 15 minutes) how many failed attempts have
happened today (so far)... when they reach a certain threshold, I send
an automated email to my cell phone and run a [q]mtrack on the log files
over the same time which shows me the same messages, but grouped by
failed attempt.
To show you the value of this, let me show you a snippet (redacted to
protect client data):
11-01 14:13:17 new msg 135400183
11-01 14:13:17 info msg 135400183: bytes 20503 from <f...@m.com> qp
29365 uid 89
11-01 14:13:17 starting delivery 10363: msg 135400183 to remote
c...@mk.com
11-01 14:13:41 delivery 10363: deferral:
Connected_to_xx.xx.xx.xx_but_sender_was_rejected./Remote_host_said:_452_4.1.0_..._temporary_failure/
11-01 14:19:58 starting delivery 10560: msg 135400183 to remote
c...@mk.com
11-01 14:20:55 delivery 10560: success:
User_and_password_not_set,_continuing_without_authentication./<c...@mk.com>_xx.xx.xx.xx_accepted_message./Remote_host_said:_250_ok:__Message_505069548_accepted/
11-01 14:20:55 end msg 135400183
This snipped is pulled from a log file containing over 100K lines of
messages (and the full output of my [q]mtrack query shows 30+ failed
messages) -- but here I can see QUICKLY (and grouped together) that THIS
message had only a temporary failure, and was delivered with only a
7-minute delay ... a delay caused by the remote server (I suspect a
grey-listing similar to what a QMT install does!).
My only real issue with [q]mtrack and [qm]strack is that both sometimes
have perl-script errors (due to unexpected line formats)... which I
conveniently send to /dev/null.
I have not attempted to reach the guy who wrote these (see
http://qmail.jms1.net/scripts/) -- in part because they haven't been
updated in SOOO long (though he did update the (C) notice to 2013
<grin>).... in any case, I'm afraid if I point out problems he may take
the site (or the scripts) down... and I've only just begun to mine the
plethora of stuff he's got on there...
I might suggest some of these make it into the QTP package at some
further date... or something like them.... withouth [q]mtrack, I don't
know how many hours I'd spend tracking messages through the log files...
since I've got a client with users who love to get us blacklisted, it
has saved me countless hours!
Just my ideas...
Dan McAllister
IT4SOHO
QMT DNS/Mirror Admin (at least for as long as there are still mirrors)
--
PLEASE TAKE NOTE OF OUR NEW ADDRESS
===================================
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
