Thanks for your reply, Till.
Originally Posted by till
Your findings are partially right, but you mixed up two completely different setups. maildrop is part of the courier based setups only and not required or related to dovecot setups and the same is with the file ispconfig_mailsize which is for courier only too.
My understanding is that there is a standalone implementation
available of maildrop which can also be integrated between MTA and dovecot LDA
. It probably makes more sense to work with sieve filters, though.
About ispconfig_mailsize, I was thinking of *somehow* making dovecot (or something added to dovecot) write out (properly formatted) ispconfig_mailsize files, too, so that the ISPConfig script doesn't need to be expanded/modified and run another 'find' on the file system, slowing down the system unnecessarily during the nightly cron job. Plus, that would mean less code to maintain on the ISPConfig side once it works. On the other hand it might require in a more complex sieve filter / maildrop setup (which could also increase processing overhead per e-mail, and that would be worse than a second 'find').
Originally Posted by till
Dovecot does not support traffic accounting yet and the sieve filtering language which is part of dovecot is not able to write files to the filesystem with traffic information as well. So its currently not possible to get the traffic information from dovecot as there is no such log file. As far as I know, the dovecot developers have planned to add a interface for that in future.
My understanding here is that, while, as you're saying, standard sieve does not allow for writing files to the file system (nor executing external applications which could do so), there are extensions to the sieve filtering language, written and documented by dovecot developers as part of the Piegeonhole project, which allow you to pipe a copy of an e-mail into an external command. Now if this external command is a wrapper around 'wc -c' and writes its output to disk, you have a simplistic implementation for counting mail traffic with little overhead. If needed (such as for only counting the message body), one could use a more intelligent wrapper there, such as one written in PHP.
So I think this should be possible already now. Of course, the plain size of e-mails transferred across IMAP/POP3 differs from the real traffic you're causing there, but I would assume it's close enough (and better than nothing). To get somewhat close to a proper implementation of mail traffic accounting you would also want/need to measure SMTP e-mail traffic. My current understanding is that this is not currently implemented in ISPConfig for any supported MTA (please correct me if wrong).
So I also looked at how this could possibly be done with Postfix. While there can be 'size=...' values in your ESMTP log, this turns out to be an optional flag, i.e. clients/MTAs are not required to send it (and I think most clients actually don't). So the friendly people in #postfix on FreeNode recommended against relying on it and suggested to use a policy (with Postfix policy daemon) instead, because the 'size' parameter is always transferred there.
Here's an incomplete and untested proof of concept shell script which should work for this purpose, logging the sizes of all e-mail it learns about to disk.
IFS=`echo -e "=\r\n"`
while read param value morevalues
if [ "$morevalues" != '' ]
echo 'Error: More input found than expected' >&2
case $param in
domain=`echo $value | cut -d'@' -f2`
user=`echo $value | cut -d'@' -f1`
echo -e 'action=dunno\n\n'
echo "$size" >> /var/vmail/$domain/$user/LOGFILE
This policy should only be used for SMTP mail, and only be applied after successful client authentication has taken place via SASL. This should be possible by placing it at the proper position in the 'restrictions' section of postfix' main.cf
So, while some of this is still theoretical, my general impression is that traffic accounting with all non legacy versions of Postfix and with Dovecot 2 should be achievable. Now "someone" "just" needs to find the time to actually implement and test this. ;-) I can't really promise to do it, though (but will try to find some time).