Nobody saw this before? May be somebody not read logs to see that. This problem lead to lose messages that, by the origin of error may be are spam or bad mails, DNS errors seeking for SPF error, but I don't want to lose a valid mail. My short experience tell me that this exist in a lot of servers with similar configuration.

Only need to seek "Unable" at /usr/local/var/log/maillog. Or as I user excellent rpm of ossec-hids to report at Atomic repo... thanks Scott again.

Regards...

Gines

Scott, you explained that psa handler failed to report to qmail-scanner-queue the error, in this case "DNS Lookup fail". The illegal seek was fired on problem to close pipe, but in previous line of log qmail-scanner can't even open the pipe. May be this is a qmail-scanner problem not handling well an exception.

Sorry if I so wrong, but this error cause problems with some mails and I want to know if exist a solution. This problem can't be only mine.

Regards...

Gines

I post here other portion of logs (of another mail) where spf resolves REJECT, not as previous when not obtain DNS information. qmail-scanner fires an Illegal seek too, but in this case there is no problem to open or close the pipe. If I think well for reject the mail qmail-scanner must use the mail-queue again too.

Jul 27 07:46:40 serverX qmail-queue-handlers[22242]: call_handlers: call exe
cutable = '/usr/local/psa/handlers/info/10-spf-m7If50/executable'
Jul 27 07:46:40 serverX spf filter[22243]: Starting spf filter...
Jul 27 07:46:40 serverX qmail-queue-handlers[22242]: handlers_stderr: REJECT
Jul 27 07:46:40 serverX qmail-queue-handlers[22242]: call_handlers: REJECT d
uring call '/usr/local/psa/handlers/info/10-spf-m7If50/executable' handler
Jul 27 07:46:40 serverX qmail-queue-handlers[22242]: call_handlers: stop cal
l handlers from dir '/usr/local/psa/handlers/before-queue/global'
Jul 27 07:46:40 serverX X-Qmail-Scanner-2.08st: [domainX.net13117
6359879822220] mail server permanently rejected message. (#5.3.0) -
Jul 27 07:46:40 serverX X-Qmail-Scanner-2.08st: [domainX.net131176359879822220] mail server permanently rejected message. (#5.3.0) - Illegal seek

Am I wrong?

Regards...

Gines

PS: Sorry for my english.

I probed manually the spf behaivoir with one of the problematic domains that triggers the DNS Lookup error and obtained that:

/usr/bin/spfquery_static -ip 66.102.13.18 -sender from@m-bgtb.maxmailing.com.ar -rcpt-to to@gmail.com
StartError
Context: Failed to query MAIL-FROM
ErrorCode: (26) DNS lookup failure
Error: Temporary DNS failure for 'm-bgtb.maxmailing.com.ar'.
EndError
(invalid)neutral
Please see http://www.openspf.org/Why?id=from%40m- ... r=spfquery : Reason: default
spfquery: 66.102.13.18 is neither permitted nor denied by domain of m-bgtb.maxmailing.com.ar
Received-SPF: neutral (spfquery: 66.102.13.18 is neither permitted nor denied by domain of m-bgtb.maxmailing.com.ar) client-ip=66.102.13.18; envelope-from=from@m-bgtb.maxmailing.com.ar;

I reproduced here manually, this is the answer that triggers the pipe problem to qmail-scanner, and obtained a delay of 18 seconds at execution time because the problem is with faulty DNS. May be it's a problem with a timeout generating this? Can I manage timeouts on qmail-scanner or qmail-queue?

Regards...

Gines

Getting hourly emails with a log like the one below:


OSSEC HIDS Notification.
2011 Jul 29 11:38:00

Received From: plesk3->/var/log/psa/maillog
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Jul 29 11:38:00 plesk3 X-Qmail-Scanner-2.08st: [x] Unable to close pipe to /var/qmail/bin/qmail-queue.orig [61] (#4.3.0) - Illegal seek

Been searching the forums and I think this is the closest I could find. Any idea about how to go about fixing this?

Managed to get mine working. Just had to create the following directory:

/var/qmail/bin/mailnames/.spamassassin with the permissions drwxrwx---

=D No more unable to close pipe errors.

So you created directory mailnames and on this dir the file .spamassassin under the /var/qmail/bin ?

Can you send us an ls -la ?

Thanks !

This only kept it at bay for a while... we are still getting them

So if we disable the spf protection these errors will stop ?