Hello Frank,
On 2013-04-01 08:41, Frank Ellebrecht wrote:
I see. Although that won't be a problem for me, there will be cases
where the database size matters. Therefore it would make sense to make
such a log file optional (like the audit log).
I also thought that it should be disabled by default
How long would you keep this data?
Well, you have to keep emails for 6 or 10 years (depending on the
content, so the advice is to always go for 10 years). But as the
retention period doesn't necessarily start when you receive a message,
hmm, that's a surprise to me. In that case you shouldn't use the
pilerpurge
utility because it's based on a calculated timestamp when you receive
the message.
it may very well be 14 or 15 years. For this time I would have to keep
the information about the processed messages, too.
ok, what about if I don't make a log purging utility?
Which do you prefer: inserting the
corresponding
records on the fly to the database right after processing, or post
processing
of the maillog file via a perl/php/... script?
As I understand the law, I would have to go with the former. Parsing
the log file afterwards would make it possible to fiddle with the log
before it gets parsed.
ok, then it will be on the fly when the message is processed.
The more I think about it, I'd try to strike a balance between the
wishes of the tax authorities and the database size. Messages which
enter the archive the usual way, i.e. via SMTP, can always be
displayed
to and analyzed by the authorities. I'll only have to explain those
messages wo didn't make it there. It should be enough to generate log
entries for »unusual« cases.
From that point of view, pilerimport isn't the usual way to enter the
archive, so I would go for log file entries when messages are imported
with pilerimport.
just to clarify: you don't need to create log for archived messages via
smtp, rather you want logging only for pilerimport processed messages,
right?
I propose the following table (or perhaps view) format:
id*, sender, recipients, subject, date**, action***
*: unique, autoincrement number
**: which date? Date in the header or the archiving date?
***: this should be a number, eg. 0: ok, 1: duplicate, 2: error, ...
There isn't that much information available about archive solutions,
whose producers claim compliance with the German law. :-(
I guess you tried to contact some of them. Didn't they reveal any
detail on how (or to what extent) they comply?
Janos
