Tracking mail proccess in logfiles

[Morons]

I need to sometime check the progress of messages through the system using the logfiles but the moment it enters procmail - all logging seem to stop! Can this part be enabled? is it perhaps logged elseware, if so how do I change the logging nt the same logfile.
Extraction of sample out of /var/log/mail/info

Jan 25 09:15:23 hera postfix/smtpd[28672]: 7D844334C01: client=unknown[sanitized-IP]
Jan 25 09:15:23 hera postfix/cleanup[28674]: 7D844334C01: message-id=<004201c74050$858c1520$930aa8c0@uranus>
Jan 25 09:15:25 hera postfix/qmgr[27827]: 7D844334C01: from=<from@domain.tld>, size=39247, nrcpt=1 (queue active)
Jan 25 09:15:25 hera postfix/smtpd[28672]: disconnect from unknown[sanitized-IP]
Jan 25 09:15:25 hera postfix/local[28677]: 7D844334C01: to=<web33_tegnies@domain.tld>, orig_to=<tegnies@domain.tld>, relay=local, delay=1.8, delays=1.8/0/0/0.07, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)
Jan 25 09:15:25 hera postfix/qmgr[27827]: 7D844334C01: removed

I can therefore NOT see the spamassasin and results of the clamav!

[martinfst]

Yes you can. In your mail client, you can view the headers of received emails. You will thus see all the rule hits of spamassasin/clam.

Don't know if you can tweak your procmail settings to make it more verbose

[Morons]

hmmmm, I thought its obvious that Im running the server and not the client! My question is about the total process on the server that needs to be logged and not stop were it passes to procmail!

[martinfst]

It appears procmail has the option to do logging, but the default in ISPConfig is to not log. I'm not procmail expert at all (I'm right now in the proces of starting to use it as a result of my ISPConfig usage).

I did a quick google for 'procmail logging' and got a lot of hits. It requires to modify the .procmailrc file, and thus it will deviate you from the ISPC standards. But it looks doable to customize.

If you want that for all customers by default, you have to edit the file

/root/ispconfig/isp/conf/procmailrc.master

Sorry, I'm not able to give you more advise/examples here. Anyway, this route may get you into trouble with the next release of ISPConfig. Coming to think of it, I would like to suggest an enhancement to ISPC: create a custom directory, where you can have your own modified templates/masters, which will not be overwritten with an upgrade. So in the /root/ispconfig/isp/conf/ there should be a 'custom' directory. If in this sub-directory a customized file exists, ISPC should use the custom file and not the orginal. Upgrades of ISPC should not touch the 'custom' directory.

[Morons]

I agree on the Customization-ability is not catered for but I'd like my customers to see my logos marketing etc, and each time I have to re-do the logos etc when I upgradce! If we consider this we do need the DB then to have Custom table that keep the links of were to find the custom files etc.

On the Logging - It is extreemly nessesary to log the whole process to faultfind stuff!

[till]

I agree on the Customization-ability is not catered for but I'd like my customers to see my logos marketing etc, and each time I have to re-do the logos etc when I upgradce! If we consider this we do need the DB then to have Custom table that keep the links of were to find the custom files etc.

The problem is as follows. If the installer can not overwrite files, we can not add any new functionality in future releases that change any of the templates and we can not make sure that an update works.

If you modify a template you will yust have to campare your template with the newly installed version.

[martinfst]

The problem is as follows. If the installer can not overwrite files, we can not add any new functionality in future releases that change any of the templates and we can not make sure that an update works.

If you modify a template you will yust have to campare your template with the newly installed version.

Couldn't we leave that to the user? As soon as the installer finds a updated template in the 'custom' subdirectory, just give a warning to check the difference between the new version and the custom one. Perhaps even showing a diff? That's how the debian and rpm based installers work also.

I agree ISPConfig shouldn't be bothered to be responsible for customizations, but as it is now, people like me will do the customizations anyway, and whenever an update comes along, we have to remember we did a change to a standard template. With a custom directory at least we have a verification. By the way, DirectAdmin uses the 'custom' subdir trick. I'd be very tempted to implement this, but of course you are the lead developer so you decide. I'm just a humble, but happy user for now.

[falko]

Originally Posted by martinfst

uses the 'custom' subdir trick.

We can keep this solution in mind.

[Morons]

In the gaming world of World of warcraft they allow "addons" witch is disabled but not removed and the custome can switch them on by means of an config screen and test / modify. Surely if you change any of the customizable items there will / can be an release note informing the user that those changes were made and how its changed so they can re-do or adopt another fix?