Atomicorp

I upgraded my Plesk Install awhile back to Plesk 7.5.4, and promptly broke my email. The error at the time was an incorrect xinetd configuration for the smtp service. However, as far back as I can remember, I've had problems with my email boxes breaking.

I've searched the Plesk Forums, been googling solutions and trying things for weeks, and nothing yet has fixed my problem. On the plesk forums, the closest I could find was a post about spammers sending messages with corrupt headers. (see Terminal junkies post at http://forum.swsoft.com/showthread.php? ... en+headers
).

I've installed spamassassin, and qscan via yum, but the problem continues. I feel like I'm at the end of my rope, but I don't want to have to switch back to an old exchange server just to get emails.

The actual breaking is a character code like [9 or [7 or [20 in various portions of the header (usually Recieved: from[9 or Message-ID: <G[20). It prevents the email clients from downloading the message, requiring me to login and manually deleting the offending message.

Is there anyone who has experienced this same problem that might offer guidance?

Thanks for your time,
Xaeridus

Theres nothing I have in my archive that would address that really, since I dont run windows. You might want to talk to either the spamassassin or qmail-scanner folks about tests that would detect that kind of breakage on a server-wide scale, or perhaps procmail or mailfilter rules to remove that from each mailbox. Barring that you can also send me a big wad of cash to come up with a solution

Yea, I was afraid of that. Its entirely possible that this is just a config error on the compiliation of Fedora Core I have installed. The error has been around so long its just frustrating. I was hoping there might've been a yum patch for qmail I was missing or some sort of weird config I forgot about.

I appreciate the response, it shows that its not a common bug thats well known about. I'll probably just change hosting companies and uninstall qmail on this server, so that it doesn't continue to drive me nuts.

Thanks again - Cheers,
Mike

Its really a problem in Outlook, your "workaround" for your users when this comes up is to go in through webmail to read/delete that specific message, or use another MUA, like thunderbird, evolution, etc.

Unfortunately its not just outlook. I vaguely mentioned it in my posts as "email clients", I've tried using OS X's Mail program, as well as thunderbird and the problems still occur.

The nice part is that I recently discovered that Mail allows you to view whats on the server and delete the specific message, but the email is primarily accessed on a Mac OS 9 machine. I think the problem will just have to wait until we finish upgrading our equipment to OS X.

My biggest surprise is that qmail even bothers delivering the message. The messages have incomplete headers and no bodies, I'd assume the best thing to do would be drop the message. I guess qmail functions as a sheer pass-thru, no matter how deformed stuff is .

Your responses have been fantastic though, and I appreciate your time.
Thanks again,
Mike

First off, part of your problem is you're using OSX, which is for dirty heathens. You need to upgrade that to linux post-haste. Not sure what you can do about that one button mouse though. Just try and pretend it isnt there or something... or work from the shell.

All joking aside, If Thunderbird on OSX cant delete them, then that might be a bug or a flaw in their implementation. I've personally used thunderbird on several OS's (windows, linux, solaris, freebsd, etc) to delete those kinds of messages. The MTA itself is pretty liberal with the kinds of messages it will process, if it has a rcpt to and a mail from, it will deliver the message, its not going to do a whole lot of validation on the content. If however you've got qmail-scanner in the mix (or procmail, mailfilter, etc) you can do some basic validation on the message, by either quarantining/deleting messages without a Subject line, or looking for messages that dont have the correct newline sequence.

Again your fallback here is webmail, don't rely on the vendors since obviously you're having issues even with the clients known to work. Your users will likely run into the same problem, and it's an even bigger headache to manage multiple MUA's that are inconsistantly working across operating systems.