>>> >>> --------------------- sendmail Begin ------------------------ >>> >>> STATISTICS >>> ---------- >>> >>> Bytes Transferred: 5241 >>> Messages Processed: 2 >>> Addressed Recipients: 2 >>> >>> ---------------------- sendmail End ------------------------- >>> >>> I'd also like to know where/how logwatch is getting the number for >>> "Bytes Transferred"; it doesn't seem to correspond to anything. >>> >>> So, unless I'm missing something, that's two problems. Does anyone >>> see any others...? or have a plausible explanation for these >>> inconsistencies? >>> >>> tia. >> >> 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. > 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 at dest and <recip at dest.com>. 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