For efficiency, I'm responding to several messages, posted by more than
one person.
> i would suggest to use <== and S= as a filter and then parse the size
> out of S=
Note that you can request S= on => lines by the log selector
"delivery_size".
> and would tailing and grepping with complex filters not be slower than
> just dumping out the messagesize to a file?
Exim works with multiple independent processes. Each process, for each
delivery, would have to open the file, lock it, and then update it. This
will slow down mail delivery because it introduces a synchronization
point.
> but quota management has also information abut mailsize, this would be
> enough.
Each Exim process knows how big each mail is. But this information is
not in a central process.
> Hm, that's very uncomfortable to parse, when messages are spreaded
> across multiple lines!
log_selector = +delivery_size
(as mentioned above) puts a S=xxxx entry on each => line. Does that
help?
> 1) How long should I store the message ID entries? Can I rely on a
> "Completed" message to be written? What about frozen messages that were
> never actually delivered?
They won't have "Completed" until they are unfrozen and removed. But
Exim should write "Completed" for every message, at the time it removes
the files from its spool.
> 2) How can I determine what log lines were already processed, when the
> parser is restarted? Maybe I'd have to note the date anywhere and only
> count traffic logged after this date.
Yes.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
