7 thoughts on - Apparent Bug In Logwatch’s Reporting Of Number Of Email By Sendmail

• ken wrote on 3/13/2015 11:36 AM:

  Ken, the bytes transferred looks to be the size of the first two log entries (2485 + 2756 = 5241). I’m not sure what logwatch considers individual messages in its sendmail stats, but a unique message ID does indicate a unique message. I also want to point out that if your logwatch is generating an email, this may be counted in the stats also
  (how, I’m not sure). If logwatch is running at 4AM, when these emails are being sent, I could also anticipate some problems, depending on the timing involved and when log entries are committed to the log. Overall, I wouldn’t be concerned.

  –Blake

• My major concern is accuracy. I mean, there’s not much sense in using logwatch if what it’s telling me is wrong.

  The fact that logwatch runs at 4am shouldn’t be the problem here, as logwatch is culling data from the previous day. So no conflict there
  (if that’s what you were implying).

  You’re right about the Bytes Transferred number. “size” is mentioned
  *three* times in maillog. It’s just another curiosity how logwatch picked the two numbers that it did. However it did it, obviously it’s double-counting, so logwatch is getting that number wrong as well.

• First email is sent locally to root.

  Root I guess forwards through an alias so it resends to target.

  I’m guessing it simply parses the message sent lines. Whether or not treating locally delivered emails is correct or not – I’m inclined to think it is. Either way it would probably be difficult to exclude it – and then you would never be able to track locally sent emails.

  Jason

• And that email would be the logwatch report itself, but from 24 hours before.

  That would be my guess too.

• I see that it’s sent *from* root. Where does it say it’s sent *to* root?

  /etc/logwatch.conf is configured to send to , so no aliasing and no resending.

  Tracking where/how emails are sent would be done in maillog, not in logwatch.

  I’d disagree. If one email is sent, saying two are sent is not correct.
  If one email is sent with one recipient, the total number of recipients is one. If I hold up two fingers and ask someone how many fingers I’m holding up and she says “four”, that too is incorrect.

  Yes, it might be difficult to machine-parse the maillog, but then the software– here logwatch– should either be fixed or its data described accurately (and hopefully too, meaningfully). It shouldn’t post erroneous data.

• Based on the day of ‘Mar 12’, I agree with the bytes transferred. Logwatch’s sendmail component appears to be using the sendmail queue ID
  (vs the message ID) as an identifier for a unique message. Using this identifier, I too count 2 messages (t2C82IiB027383 and t2C82Bjr027151). Looking at recipients, I also count two: recip@dest and .

  What criteria to use as a means of identifying a unique message is certainly a choice. I can see how some would choose the MUA’s message ID
  instead. However, that may be more error prone given that this is not guaranteed to be a unique value within a data set. Sendmail’s queue ID
  should be unique in a day’s data on a single server.

  –Blake

• If someone knew absolutely nothing about email, then yes, recip@dest and
  might be seen as two recipients. But sendmail, an inert body of code, knows that those are two ways of addressing one and the same recipient and indeed sends me just one email, not one to recip@dest and another to recip@dest.com. Logwatch, however, lacks the sophistication to understand that these are simply two ways of
  *addressing*, or *referring* to, one and the same recipient.

  Similarly, simply because there are two different numerical identifiers, both *referring* to one and the same email doesn’t mean there are two emails. If there were a third number referring to that one email would we then magically have three emails? I’m wondering, then, what would happen in logwatch if an administrator changed sendmail’s loglevel to something other than the default…?

  I’ll leave the criteria selection as well as the logic to interpret that up to the logwatch developer(s). Perhaps sendmail’s logging would need to be made less ambiguous for logwatch (and other possible diagnostic programs). Whatever fixes the problem is fine with me.

  Blake, thanks for playing devil’s advocate and pointing out the probable sources of unwarranted conflation. At first I was a bit unsure, but after this conversation we can with certainty conclude that, yes, this is a bug.