Atomicorp

Scratch that, horrible solution. That simply gets postfix running alongside the shut down qmail. Not effective with qmail-scanner of course. Switching MTA's back results in the same issue.

Wow, got it to work based on some post over at the Swsoft forums. The following perms seem to do the trick, although their security implications are yet to be analyzed.

-r-sr-xr-x 1 root root 34128 Jan 27 07:08 smtp_auth
-r-xr-xr-x 1 root root 6704 Jan 27 07:08 relaylock
-r-xr-xr-x 1 root qmail 2892 Jan 27 07:12 true
-rwsr-xr-x 1 qmailq qmail 42844 Jan 27 07:19 qmail-queue.orig
-r-x--s--x 1 mhandlers-user popuser 42248 Jan 27 07:19 qmail-remote
-r-xr-xr-x 1 root qmail 42676 Jan 27 07:20 qmail-local
-r-x--s--x 1 mhandlers-user popuser 4627 Feb 11 12:18 qmail-queue
-rwsr-xr-x 1 qscand qscand 157163 Feb 11 12:18 qmail-scanner-queue.pl

Anwar.

Forgot to mention, that I also had to do this to get everything working after the Plesk 8.6 to 9.0 upgrade.

mkdir /var/qmail/mailnames/.spamassassin/
chown popuser.popuser /var/qmail/mailnames/.spamassassin/
chmod 770 /var/qmail/mailnames/.spamassassin/

Anwar.

Have been experiencing the same problems with Plesk 9.0.1 and Atomic Scanner and seem to have fixed it by setting the permissions of qmail-queue to

-r-x--s--x 1 mhandlers-user popuser 4627 Feb 11 12:18 qmail-queue

As suggested above by anwarpp

Cheers anwarpp!

I have been seeing these messages in maillog files on quite a number of Plesk/qmail-scanner servers for quite a while now (and lots of them!):
Mail appears to work fine, but still this just doesn't feel right. Did anyone ever really solve this puzzle?

I'm having these entries too.
54 indicates:
case 54: message = "Unable to read the message or envelope.";

Does the error on your servers also only show up in comnbination with this one:
qmail-queue-handlers[579]: Unable to get 'From:' string from SMTP session

Yes, they seem to appear after that message every time. I guess spammers are sending messages without From headers or something?

interesting.
parallels has a workaround for the error "qmail-queue-handlers[579]: Unable to get 'From:' string from SMTP session"
under this post: http://forum.parallels.com/showpost.php ... stcount=51

but I'm not sure if thats the best solution. After my investigation this error only shows up when the rDNS of the sender is empty or the from sender is empty.
Till now this is only showing up on spammers. No sender is OK. According to RFC 821, it is legal to deliver messages with no sender address.
But no rDNS is typical for spammers. So to me, the spam is causing most of the "unable to get from" errors which are causing the "pipe" errors.

first I will block all connections from servers that have no rDNS entry via spamdyke.
I think this will downsize the errors. I only have a few but I'm interested of how few will be left.
Note that it might be different on other servers. I'm using qmail (of course),qmail-scasnner,spamdyke and have submissions port enabled.
It could be different with other combinations.

Interested what you guys think about it.

BruceLee wrote:interesting.
parallels has a workaround for the error "qmail-queue-handlers[579]: Unable to get 'From:' string from SMTP session"
under this post: http://forum.parallels.com/showpost.php ... stcount=51

but I'm not sure if thats the best solution.

Why wouldn't this be a good solution? Have you tried it?

sorry, forgot to write it. No I have not tested it.
I thought that it's not the best because of this thread indicating that it replaces one error line with another.
http://forum.parallels.com/showthread.p ... 074&page=2 post 38.
Of ocurse this could still fix the pipe error.

I tested that patch on CentOS 4 i386 and it seems to fix both the missing From header and Illegal seek messages.

If you're using qmail-scanner make sure you replace /var/qmail/bin/qmail-queue.orig with the patched version (and match that file's ownership and permissions) instead of /var/qmail/bin/qmail-queue.