Mail traffic accounting

[ispcomm]

Quote:<ispcomm>
-) Count all other SMTP traffic, mapping every destination address to the domain that forwarded it.

<kilburn>
Outgoing (forwarded) deliveries have no info about the original recipient, as in test case 4 (second smtp):
Code:
2008-06-19 08:17:35 me@external.dmn redir@dmn.tld test.server.tld 127.0.0.1 SMTP - 1 778303
2008-06-19 08:17:35 me@external.dmn me@external.dmn test.server.tld mx.external.dmn SMTP - 1 778674

There is no easy way of reverse-mapping "me@external.dmn" to "redir@dmn.tld" (it may seem easy here, but there could be some more deliveries between those lines). We would probably need to modify maillogconvert in order to do it...

Maybe I'm missing something. The hash table that can be constructed using data from the "big" sql query will give you a "forwarded address" -> "local domain" mapping.

You'll have modify the AWK script to also print the original destination in addition to the domains.

Having that destination->domain table you don't need to modify maillogconvert because you can directly map every SMTP ougoing address to a local domain and sum the mail size to the usage.

It does not matter if the delivery is deferred or if there are other deliveries in the middle because you don't need to keep the state.

This is why incoming and outgoing mail size computing is separated from each other: When mail arrives for a local recipient: Count its size once. When mail leaves to a recipient that is a known-forwarded address of a domain, count it once again to that domain.

There's a special case when 2 domains map to a single forwarding address. You will need state information to correctly account this type of situation or you could choose to either add size/number of domains to each of them or size to each of them (counting too-much). Counting size/number of domains would be a good-enough solution because the domains would be related to the same customer anyway.

As the ease of implementation... it's as easy as you did it: me@external.tld is a forward for redir@local.tld so mapping "destination mail" to the local domain that originated is a matter of a lookup in the forwarders table.

Whatever solution you choose, the current accounting is much better than what we started with anyway.

ispcomm.