IWorx-Dan
09-10-2010, 03:24 PM
While solving a client issue, I made a bash command to simplify the process of checking the email traffic per domain. I felt this may be useful to some of you out there with high incoming SMTP traffic who may want to see which domains get the most email. This will only show you the number of received emails by the SMTP server per @domain over the period that your logs cover.
# cat /var/log/smtp/*.s /var/log/smtp/current | \
grep 'CHKUSER accepted rcpt' | \
cut -d ' ' -f 10 | cut -d '@' -f 2 | sed 's/>$//g' | \
sort | uniq -c | sort -rnIf your logs only hang around for a few hours or so (common on high-traffic servers), you will have to modify the daemontools multilog utility (syslog/logrotate is not used for qmail) to extend the lifetime of the smtp logs before you can see a significant amount of data. You can tell how far your logs go back by running # ls -la /var/log/smtp and seeing whats the oldest time you see for date modified on the logs. In order to extend the amount of time the logs hang around for:
Open up the multilog configuration file for the smtp server. I use vim but you can use what ever text editor you prefer. # vim /service/smtp/log/run
This is what the file looks like: #!/bin/sh
exec /usr/bin/setuidgid qmaill /usr/bin/multilog t s1000000 n5 /var/log/smtp 2>&1 The 's' and 'n' values are what we will need to adjust here. ... exec /usr/bin/setuidgid qmaill /usr/bin/multilog t s1000000 n5 /var/log/smtp 2>&1 s is the max size of a log file in bytes and n is the number to keep around before deleting the oldest one. I'd increase 's' to something like 5000000 for ~5MiB files and bump the 'n' number to 20 or so if you find you are only getting a few hours of data. Use your best judgement for these numbers. You obviously don't want to run out of disk space. Make sure the 's' bytes times 'n' number of log files is not larger then you are willing to sacrifice to the log utility!
Now, restart the multilog qmail service: # svc -t /service/smtp/log
You're Done! Now, wait for enough time to pass for the logs to fill up so they begin to rotate, and check to see if you now have a large enough sample size.
# cat /var/log/smtp/*.s /var/log/smtp/current | \
grep 'CHKUSER accepted rcpt' | \
cut -d ' ' -f 10 | cut -d '@' -f 2 | sed 's/>$//g' | \
sort | uniq -c | sort -rnIf your logs only hang around for a few hours or so (common on high-traffic servers), you will have to modify the daemontools multilog utility (syslog/logrotate is not used for qmail) to extend the lifetime of the smtp logs before you can see a significant amount of data. You can tell how far your logs go back by running # ls -la /var/log/smtp and seeing whats the oldest time you see for date modified on the logs. In order to extend the amount of time the logs hang around for:
Open up the multilog configuration file for the smtp server. I use vim but you can use what ever text editor you prefer. # vim /service/smtp/log/run
This is what the file looks like: #!/bin/sh
exec /usr/bin/setuidgid qmaill /usr/bin/multilog t s1000000 n5 /var/log/smtp 2>&1 The 's' and 'n' values are what we will need to adjust here. ... exec /usr/bin/setuidgid qmaill /usr/bin/multilog t s1000000 n5 /var/log/smtp 2>&1 s is the max size of a log file in bytes and n is the number to keep around before deleting the oldest one. I'd increase 's' to something like 5000000 for ~5MiB files and bump the 'n' number to 20 or so if you find you are only getting a few hours of data. Use your best judgement for these numbers. You obviously don't want to run out of disk space. Make sure the 's' bytes times 'n' number of log files is not larger then you are willing to sacrifice to the log utility!
Now, restart the multilog qmail service: # svc -t /service/smtp/log
You're Done! Now, wait for enough time to pass for the logs to fill up so they begin to rotate, and check to see if you now have a large enough sample size.