Re: Logging oddity: no "qmgr removed" issued on body/header rejections

David Landgren:
> Hello,
>
> I've been writing an object-oriented interface in Perl to handle Postfix
> logs. I know this is a rather futile effort giving their wildly changing
> nature from release to release, but hey, it was an itch I needed to scratch.
>
> I'm not trying to deal with old-style logs, which is I believe anything
> 2.0-ish. I'm only aiming for new-style logs, the ones that have these
> sorts of messages:
>
> Oct 6 18:44:34 relay postfix/qmgr[44170]: 562862A511: removed
>
> It's through this line that you're able to determine when an SMTP
> transaction has been finished, which lets you get on with the job.
> Without that it's just messy heuristics.

This is inaccurate. This line indicates that Postfix has completed
mail DELIVERY. It has nothing to do with SMTP. It also says nothing
about RECEIVING mail.

> Anyway, I've just tracked down a bug in my code, based on the false
> assumption that the above "qmgr removed" messages above always appear.
> It turns out, at least for mail_version = 2.2-20040829 that this doesn't
> always hold. If the case of rejecting messages based on header or body
> checks, no qmgr removed message will be issued.
>
> For instance:
>
> Oct 1 00:54:19 relay postfix/cleanup[527]: 0A0782A496: reject: header
> Content-Type: application/octet-stream;??name="id_yours.doc.com" from
> ASt-Lambert-151-1-22-53.w82-120.abo.wanadoo.fr[82.120.235.53];
> from=<31800173@mwinf0512.wanadoo.fr> to=<point@example.com> proto=ESMTP
> helo=<example.com>: extension ".com" of attachement [id_yours.doc.com]
> indicates Microsoft executable content (or similar) and is a security risk
>
> If I grep for '0A0782A496' that's the last line I get.

You never have any guarantee whatsoever that the queue manager will
always log the "deleted" record. A robust logfile processor must
be able to deal with the absence of such a record.

Wietse

> Anyway, I have my work-around, but it might be worthwhile to issue a
> removed message anyway, according to the Principle of Least Surprise.
>
> Regards,
> David
>
>