On 1/8/2011 12:13 AM, Ramprasad wrote:
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
Milters run on input.
You should be able to use Sahil's tcp header checks service
with smtp_header_checks, which works on output.
http://www.postfix.org/postconf.5.html#smtp_header_checks
But note that delivery is not guaranteed at that point; the
message can still be rejected or deferred by the remote site
after the header has been logged, or there could be several
minutes delay between when the message is logged and final
delivery is accepted.
Consider this a stop-gap measure until you can implement a
better design that doesn't depend on an ID at the end of the
Subject line.
-- Noel Jones
