new email logging format

[Joost van Baal]

Hi,

On Wed, Sep 07, 2005 at 09:59:24PM +0300, Konstantinos Koukopoulos wrote:
> 
> I have been looking into the proposed change in the email service model. 
> Specificaly it's been mentioned that the exim logging model would be suitable 
> where one separate line appears for each of the following events:
> 
> Message arrival,
> Normal Message delivery,
> Additional address in same delivery,
> Delivery failed/address bounced, and
> Delivery deferred/temporary problem.
> 
> It was also mentioned that for this change to happen the email schema needs 
> altering so that it properly supports all the major daemons (sendmail, 
> postfix, etc.). I have looked at log files from sendmail, postfix and exim 
> and I can't see what the current schema lacks.
> From my point of view the basic necessary fields that appear in the log lines 
> of these daemons are:
> 
> Time of event,
> Connecting host,
> Authentication ID,
> Queue ID,
> From address,
> Message size,
> Relay host,
> Delay until delivery
> Status result
> 
> These are already in the schema, correct? Am I missing something?

The current BUGS file in CVS explains this:


- wishlist: the email dlf format could better have a dlf record for _all_
  message-queued events.  We now only record the final action taken on the
  message.  Only when the logfile doesn't contain the last action taken on the
  message at hand, a stat=queued events makes it into the dlf now.  Queueing
  events migth very well be interesting information, and might be needed for
  some useful reports.  Thanks Mark Huizer for reminding me about this.
                                                     JvB, 31 May 2002

  Even better: we should probably redesign the email DLF format to be more in
  line with what actual email logs contain, that is records for
  receiving, queued, sending, forwarding, bouncing, etc. events. This could be
  modelled after the exim logging model that is very clean (compared to all
  the others
  we support now). This would simplify the email DLF converters a lot,
  since the flow analysis can be moved to generic modules instead of
  having to be reimplemented in each of DLF converter. This would make all
  sorts of reports possible (bounce, forwarding, anomalies).

  It is possible to implement this in the current "single schema model"
  by using something like we did in the firewall superservice where some
  field are only relevant to IDS type of event and others only to packet
  accounting type of events.
                                                      FLJ, 31 May 2002


So: the current schema is not really broken, but it's optimized
neither...

Bye,

Joost

-- 
.    .                                        http://logreport.com/
| '.|                        /^LogReport$/
| Lire                                        http://logreport.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.logreport.org/pipermail/development/attachments/20050908/c2d97b71/attachment.bin