• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Logging from qmail-spp plugins

G

greyman56

Guest
Has anyone managed to get qmail-spp plugins to send their stderr log messages to the mail log?

When adding a plugin to be called by qmail-spp, the plugin sends log output to stderr and it should appear in the log. Instead it goes back to the smtp socket and disrupts the smtp conversation. This is an xinetd issue.

When qmail-spp runs in the normal qmail environment, under tcpserver, stderr is usually directed to a log file via splogger or multilog. In the plesk environment we are using xinetd and it grabs stderr and sends it back to the tcp socket. Not good.

I know it is probably possible to write a wrapper script that redirects strderr to splogger, but that would mean a new copy of splogger for every incoming smtp connection. Also not desirable.

Any thoughts about this?

BTW, I am trying to perfect our own implementation of greylisting that works as a plugin. Trials so far are very encouraging but the lack of logging is a bit of a problem.

Cheers
Graham
 
Graham - Have you made any progress on the logging portion. I am troubleshooting an issue pertaining to 500 series errors and would like to see them occure live in log files that I can then make some adjustments on a system in front of my plesk server.
 
Graham - Have you made any progress on the logging portion.
I have not found any definitive answers yet. From my enquiries on the qmail mailing list, the best answer to date centres around writing syslog calls into my plugin so as to avoid the problem caused by running under xinetd.

The conversation I started at the qmail list is here if you're interested. (You will note I did not mention Plesk as that is a dirty word on that list.)

I am troubleshooting an issue pertaining to 500 series errors and would like to see them occure live in log files that I can then make some adjustments on a system in front of my plesk server.
Is this with a home grown qmail-spp plugin, or someone else's?
 
I have not found any definitive answers yet. From my enquiries on the qmail mailing list, the best answer to date centres around writing syslog calls into my plugin so as to avoid the problem caused by running under xinetd.

The conversation I started at the qmail list is here if you're interested. (You will note I did not mention Plesk as that is a dirty word on that list.)

Is this with a home grown qmail-spp plugin, or someone else's?

The issue I am troubleshooting has to do with the interaction of my plesk node and Postini. When I look at postini I am seeing ten times the number of 500 series errors on the server coming from postini vs legit mail. Now that may very well be accurate, but I am suppose to be receiving protection against such differences in numbers. On the other 50+ smtp servers I have sitting behind Postini, I am not seeing this behavior. That is to say the number of 500 errors that are hitting the SMTP port are less then the number of legit messages. This is a direct result of something they call Directory Harvest Attack. A fancy term for blocking an IP if it attempts more than X number of invalid rctp in some number of seconds.

Since the plesk qmail install lacks the logging in this section of the SMTP conversation I am essentally blind. I am unaware if the issue lyes on the answer my SMTP server is giving Postini, or is the problem that the invalid rcpt are coming from multiple remote addresses and staying below the radar so to speak.

I am bascicly looking for something I can add to the server args line of the /etc/xinetd.d/smtp_psa config that will write connection information "date, host, from, rcpt, (good, bad)" On my standard qmail install that arg is
qmail-chkuser, but I believe that it does more than just logging.

I did receive an email from the ticket I have open with parallels, they referance a KB article that you may or may not be aware of. http://kb.odin.com/article_22_1161_en.html That areticle explains the process of compiling your own patches into their qmail. I am still not sure if I want to do that.
 
Back
Top