ispcp-vrl-traff-correction should be disabled

[aseques]

This is part of the ispcp cron, and it's responsible of distributing the traffic that couldn't be assigned after reading the logs.

It my opinion, it should be disabled, the way for a good accounting system should be to fix all the errors in the accouting system instead of distributing the excess to all the customers.

You can follow other issues with the traffic on there:  http://www.isp-control.net/forum/thread-8721.html

[kilburn]

the way for a good accounting system should be to fix all the errors in the accouting system instead of distributing the excess to all the customers.

I totally agree with you, but it is unfeasible in some cases. For instance, I can assure you that there is *no way* to properly account all smtp traffic without heavily modifying postfix itself.

Anyway, distributing excess traffic usage evenly among customers feels really wrong to me. If we are unable to properly account something, we just have to accept the resulting loses.

Hackish solutions like these "distributing among everyone" will only make us seem unprofessional, and hide those accounting problems that can be fixed. With this system, I've some customers accounted for some SMTP traffic... when their mails are handled completely externally! How am I suposed to explain this to them without losing my credibility?

Conclusion: I *totally agree* with the proposal to remove the vrl-traff-correction stuff. Unfortunately, it's a somewhat major change so we need -at least- an ok from benedikt.

[benedikt]

Replying to kilburn:

Conclusion: I *totally agree* with the proposal to remove the vrl-traff-correction stuff. Unfortunately, it's a somewhat major change so we need -at least- an ok from benedikt.

If this step is the correct way to handle this issue, there is the ok from my side. We should test this for a couple of days with deactivated traffic correction. If the statistics look much closer to the reality we can drop the vrl-traff-correction script from repository.

[aseques]

I assume that when kilburn talks about smtp traffic not accounted he means the non delivered messages and that stuff (it shouldn't be big in numbers..

For the rest of stuff that I have looked more in depth:

.- Dovecot IMAP from 1.2 upwards logs the size of every IMAP transfer
.- Dovecot POP3 reports the downloaded bytes without problems
.- Apache2 can log fine using mod_logio otherwise there are heavy deviations.

Also the ftp has always been fine too for me... I don't know about courier, never had the need to configure one.

[marchaos]

You right! When vrl-traff-correction disabled statistics looks much closer to reality. Vrl-traff-correction makes bad things. It makes statistics smaller and smaller during the day.

[kilburn]

I assume that when kilburn talks about smtp traffic not accounted he means the non delivered messages and that stuff (it shouldn't be big in numbers..

Postfix logs aren't that good for traffic accounting. Aside from "undeliverable" traffic (which is not that low on my servers, 183.000 rejects/day), I'm speaking about tracking actually delivered mails. For instance:

What happens when you get an incoming mail to 3 different addresses on the server? And what if one of this addresses is redirected to another address outside the server? Well, these things are hard to follow just using postfix logs, and even impossible on some occasions.

If you want a further insight on this topic, look at the efforts once made in  this thread ;)

[benedikt]

I deactivated ispcp-vrl-traff-correction in r2578 Follow up: #2201 Delete ispcp-vrl-traff-correction