On Fri, 2011-01-07 at 09:18 -0500, Wietse Venema wrote: > Wietse: > > Postfix truncates EVERYTHING, especially when it is logged. The > > intention is to protect your file system against logfile flooding > > attack. > > Ram: > > That seems absolutely reasonable from a tech point of view. > > > > Unfortunately people have designed business processes based on > > reports of mails from applications that send mails. > > > > If this max_size_limit can be set to 100 chars then that should be enough. > > Anyway these are app generated mails sending transaction receipt info > > inside the Subject. > > So there is no security issue of log flooding in this controlled > > environment. > > > > I wont mind a recompile of postfix. > > I was also wondering ... If there a truncation of subject logging via > > smtpd/cleanup too, Apparently there seems to be none. > > You could ask your users to put the ticket number at the beginning > of the Subject: line. > I know, but making a change to the system when it has been working for most of the times is a pain to say the least.
> If you need precise control over content logging, for example > because you use it to maintain a database of some sorts, then > Postfix built-in logging is not designed for that purpose. > > Instead, you need a more focused tool. Sahil Tandon posted a > tcp-based header_checks tool a while ago. > Sahil Tandon's header_checks works at smtpd level ( I assume). Can the same be implemented at smtp level when the mail is actually sent. The idea is the mail may be queued and the syslog of the transaction info should happen when the mail is being sent not when received. Or would you suggest writing a custom smtp milter to do the same job
